Closed icemansparks closed 2 years ago
Could you confirm me your module is in 2.4.2 ? I will inquire about open issues with multishop.
we updated the module to version 2.4.2 this morning - the error still persists when switching from one shop front to another (by using the shop-front selector in the upper right corner).
When selecting the "business" shop front while the error is shown and saving the settings, the error is not shown any more. Switching back to "shop" (default) shop-front, we now have the error the other way around :)
so yes, still happening with module version 2.4.2
I have to add, that i did not try to reinstall the module yet (because of business hours).
We reproduce a bug when the new shop has a language different than the default language in the context all shop during the setup of the module. We look for a workarround if we can fix it for you before the next release.
Here a workarround : Can you check if STRIPE_WEBHOOK_SIGNATURE on ps_configuration: if id_shop_group and id_shop are empty, you need to remove it and register the configurations on the backoffice of the module for each shop ? This configuration sould be configure for each shop with a specific configuration.
If the module is well configured, you can load this request SELECT * FROM ps_configuration WHERE name LIKE '%STRIPE%'; and check that none of configurations have null value for id_shop_group and id_shop.
@clotairer using the sql statement above i found that most of the values are actually NULL, only the ones where i changed the settings on this morning have values for id_shop_group and id_shop.
you need to remove it and register the configurations on the backoffice of the module for each shop ? Removing the lines in the database would be no problem, but how can i register the configurations again so that the values will be added?
Perhaps you can update these NULL configuration to the shop_id 1 (and group 1) and duplicate for shop_id 2. After that if you update the configuration in your backoffice in the context shop id 1, only configuration shop 1 are updated and same with shop id 2.
It's intresting case to us to understand. You installed Stripe on a monoshop and after you create a multishop and activate Stripe on the second shop ? Or you setup 2 shops and installed Stripe after on both shops ?
@clotairer got some more information coming up: We started with one shop (multi shop option deactivated). Everything was set up and we also configured stripe as well as other modules. After some months now, we decided to create a second shop front to sell to business customers as well instead of just end customers. We therefore activated the multi shop option - using the same shop group (thinking, that the configuration from shop 1 would be copied over to shop 2 as well). Afterwards we deactivated SOFORT (while selecting the option "all shops" in the shop selection button in the top right corner) because of a problem that has been fixed by now. after activating SOFORT again (while having only selected the shop with ID 1) we found out, that the values are not taken over to shop id 2 and activated sofort for shop id 2 as well.
So much for the background story :)
Back to the current problem: I duplicated the entries of the previously shared image in the ps_configuration table and set the duplicated ones to id_shop_group=1 and id_shop=2.
I set "VALUE" of STRIPE_WEBHOOK_ID and STRIPE_WEBHOOK_SIGNATURE to NULL for id_shop=2. After that, i reloaded the backoffice and opened up the stripe module settings page for id_shop=1 and clicked "save". I then switched to settings page for id_shop=2 (where i saw the error message again) and clicked "save" as well. Error is now gone on the id_shop=2 page, but again appears on the settings page of id_shop=1.
Now the error is gone - although i am not sure, if everything will work as expected.
We also created a 3rd shop-front in a separate shop_group today (for testing) and found out that the values for provate key and secret are not prefilled in this case. After manually adding them, and clicking "save" in the 3rd shop front strip settings, the following values where created in the database (and also no "webhook error" was shown).
Still, a lot of the other config values for stripe (like STRIPE_OS_SOFORT_WAITING) are still missing for the 3rd shop front. (i will now duplicate the missing entries for the 3rd shop front as well).
So, with this new shop on a new group you found new bugs, but we don't know if bugs come from the new shop or the new group or both... Configuration are not generated properly. You need to fix it manually. We can help you but we need:
We schedule to work on the « wizzard » to Check and fix configuration next week.
I’ll keep you aware.
Hi @icemansparks,
You'll found in attached file a zip module stripe_wizard.zip to manage check of configuration accros all available shops.
You can check 3 level of checks:
Verify if stripe keys are registered
Sorry for the delay of our response, I hope this module can help you to fix your issue.
@clotairer thanks for that, it helped me get a better understanding and i could now (hopefully) correctly update the assigned order status values - the module displays everything as "ok" now.
I will be able to activate the Payment method for SOFORT now again and will let you know if everything is working as soon as we get our first order with SOFORT payment.
Thank you for your feed back.
Hi @icemansparks Any updates ? is it works for now ?
@clotairer we have had multiple orders with SOFORT payment working after the changes while also using the newest version 2.4.4 of the module (on multiple shop-fronts as well). Thank you for all the effort!
2.4.4 is a pre-release. If you found any trouble or regression. Do not hesitate to inform me.
We created a second shop-front with the multi-shop functionality of prestashop. After receiving the first orders in the second store-front, we realised, that the order payment status is not updated for those orders, even though the payment was already finished in stripe.
When visiting the stripe module settings, and selecting the second shop ("business"), the module did show a webhook url error (because the webhook url is referring to the original shop-front ("shop"). Trying to save the settings (as mentioned in the message) fixes the problem for this shop front, but the same problem will then occur on the original one.
It seems as if the webhook url is not saved individually for each shop front but only once, leading to errors with multiple shop-fronts.