@Arno2Mars

Arno2Mars → created an issue.

Arno2Mars → created an issue.

Hello,
Having multistep forms ajaxified would indeed be an awesome feature!

With #7 I confirm that the error is gone as well on my side.
However, the release note for the 2.0.0-rc11 says:

"- Add a contextual link to the extends (modules listing) , shows up as a gear icon, click it to find the configuration page".

Maybe I missed something, but where this gear icon is supposed to be found, as I do not find it in the module list in front of the shs module?

Thanks,

Same problem for me on drupal 10.2.4, php 8.3 when upgrading shs module to last version through composer update.

Same for me: installation through composer, then drush cr. That's where the problem happens.

Thanks a lot!

I have just tested it and I confirm it works like a charm.
I took time also to check everything is still working with Claro, Gin and Olivero themes, and I confirm it is the case.

Your help is much appreciated, thanks again!

Arno2Mars → created an issue.

Hi Dmezquia,

I don't think the issue is the same, as my problem is not occuring with Better Exposed Filters.

But you are right, I should have provided more info. Here it is:

Versions:
- drupal v10.2.4
- pcr v2.0.3
- Bootstrap theme v8.x-3.30

Steps to reproduce:
1- Create a content type (e.g Article)
2- In "manage fields", create a List field (e.g Test checkbox)
3- In "manage form display", select formatter "Pretty checkboxes/radios buttons" and save
4- Clear all caches
5- Go to the content add page and see the form

While on many themes the pretty buttons appear (see 3 first screenshots for Gin, Claro and Olivero), nothing appears for Bootstrap theme (see last screenshot).

Inspecting the page with the Chrome developper tools, it appears that the
for each select element are created but empty, thus not showing anything.

Let me know if this additional info helps.

Many thanks!

Arno2Mars → created an issue.

Same issue on my side.
However clearing the cache solved the issue.

I had the exact same problem and I confirm this patch works and removes the entire form validation issue.

Thanks a lot, the patch works like a charm and solves the issue.
May this help regarding your two points:
1. Indeed, Rules UI will not accept a price field (number) as it requires a decimal input. Two workarounds: Either to import a rule configuration with the node.field_amount.number in the YAML code (this will bypass the data type check and the rule will work perfectly) or convert the price field into a decimal value (rules offers data conversion actions).
For the currency, I do not have any trouble, I simply enter the currency code string (e.g "EUR") into the currency field and it works. Take care to enter it in "direct input mode", and not "data selection mode"

2. What you should do is:
a- Add an action "Create a transaction entity" and fill in the necessary fields: type, issuer, recipient, brut amount, currency, payment method, currency and status. In my case, I assign as well a hash (equal to my node uuid) and I leave net amount and fees fields blank (automatically calculated using the commerce_funds modules settings).
b- Add an action "Save entity", select commerce_funds_transaction_created (or the rules variable name you have assigned if you modified it at the step before), and put 1 in "Force saving immediately"
c- Add an action "Perform transaction" by selecting "commerce_funds_transaction_created" (or your rules variable name if you modified it at step a) in the data selector.
With this it should normally work (the transaction should be visible in the commerce_funds view showing all site transactions and user balances are updated accordingly.
If following these steps does not work for you, do not hesitate to share screenshots or additionnal info so that I can support you finding what goes wrong (I know that the Rules interface is a bit picky). Combining commerce_funds with Rules is really powerful and this interface should be kept in my opinion.

Regarding the transaction fields this is definitely a great feature covering most probably a large number of use cases, but unfortunately not mine. Indeed, Rules will not allow any action on this field, as at the time the Rule is triggered the entity referenced by the field is not created (I have spent my day testing it with all possible twists I know, but without success).

Hoping it helps you as well in return!
Thanks again

Thanks a lot Aporie for your extra fast reply.

I tried on a fresh D10.2 installation and had the exact same issue.

Trying to rebuild the rule also doesnt work. In Rules, the transaction action is done in two steps:
1- Add action "Create a new transaction entity" --> This works as before
2- Add action "Perform transaction" --> This is not possible anymore, when this action is selected in the available actions list (in Rules UI), there is an immediate WSOD.
If on your side you could not create the transaction, maybe it was because you missed step 2? Or didn't you experience this WSOD when selecting the "Perform transaction" action as I do?

To note that the only thing that has changed in my setup is the upgrade Drupal 9.5-->Drupal 10.2 (my Rules and CF modules were already at their latest version far before doing this upgrade and everything worked perfectly at that time). Also I did not have any issues appeared with my other rules. This leads me to think that the problem is probably linked to the RulesAction plugin of commerce_funds, which should somehow adapt something to work on D10?

I was not aware about the transaction fields that have been added, so thanks for the info. However and unless I missed something I could only find a field for doing transfers. My use case only uses escrow payments (which is a transaction offered by the commerce_funds module), as I need to have money exchanges between users retained between two workflow points: User A requests something to user B and initiates an escrow (the money is withdrawn from his account), then User B does what user A has requested, and only after User A confirms the User B achieved the requested task the money is credited on User B account (escrow finalzed). Is there a way using this transaction fields to retain a payment in the way described above (meaning to have a kind of escrow field)?

Thanks again

Arno2Mars → created an issue.

That's great!
By the way I have tested version 1.0.2 and it works perfectly well!
Thanks again

Thanks a lot!
Is it possible to do the same with the shipping address?

Hey Cyber555,

I have been testing beta19, and so far everything works now like a charm, private message windows is always opening whatever the thread exists or not.

Thanks a lot for your support!

Hi again,

Just to inform you that after a bit of research, I have found an incredibly easy way to achieve this by simply adding the two lines in bold in /src/PluginForm/CommerceStripeCheckoutCheckoutForm.php:

try {
      if (class_exists('\Stripe\Stripe')) {
      // Set your Stripe API keys
        \Stripe\Stripe::setApiKey($secret_key);

        $success_redirect_url = Url::fromRoute('commerce_stripe_checkout.payment_success', ['stsess' => $stsess], ['absolute' => true])->toString();
        $cancel_redirect_url = Url::fromRoute('commerce_stripe_checkout.payment_cancel', ['stsess' => $stsess], ['absolute' => true])->toString();
      <strong>  $email = $order->mail->value;</strong>

      // Create a new checkout session
        $session = \Stripe\Checkout\Session::create([
          <strong>'customer_email' => $email,</strong>
          'payment_method_types' => ['card'],
          'line_items' => $line_items_data,
          'mode' => 'payment',
          'success_url' => $success_redirect_url,
          'cancel_url' => $cancel_redirect_url,
        ]);

Hope it helps!

Arno2Mars → created an issue.

Hello,
I have exactly the same problem, and currently this issue prevents me to use this module.

Hello,
Same modifications needs as well to be done in src\Service\MenuLinkTreeMenuToken.php.

Arno2Mars → created an issue.