This is something we see from our development environments, with up-to-date plugins, with only WPML + WooCommerce + WooCommerce multlingual + Storefront + systemPay (our french payment platform, offered only to french buyers).
I am trying to:
Pay in french
Link to a page where the issue can be seen:
tiwal.com/fr/validation/
I expected to see:
The french SystemPay payment page
Instead, I got:
The /checkout/ page, which is the original language's checkout URL.
This occurs only since Woocommerce Multilingual's last update.
We get this issue by ONLY updating this specific plugins.
So that, with this update, the checkout now always redirects to the original language page, then transmits the order to the payment platform, in the WRONG currency hidden link
According to the debug information of your site, WPML CMS (our core plugin) and WooCommerce are not updated to their latest versions. Please update WPML and WooCommerce to their latest versions and check if the problem persists.
WPML 4.6.7
WooCommerce 8.3.1
This is the first essential debugging step. If the problem persists, we will need to replicate it on a test site, which I'll prepare for this case.
It already took us more than a day to narrow towards this issue.
I sent you debug information from one of our environment, at some point of testing, so that you have a rough idea of what the setup is. But it doesn't reflect all the tests we did.
WooCommerce 8.3.1 was released 2 days ago and fixes nothing related to this.
We already cross-tested versions before. But still, I just did it again with that very late version, as requested.
Since our last global update, the fact that we update ONLY WCML from 5.2. to 5.3 makes the issue occurs. In any of our tests, the problem occurs everytime WCML 5.3 is installed, never when WCML 5.2, or 5.2.1 (yes we took time to test this one as well) is installed instead, whatever the theme, other plugin activated, or WordPress version.
So yes, even if you don't see it from the debug log I provided, we already tested that this issue occurs on:
WordPress 6.4.1
WooCommerce 8.3.1
WPML 4.6.7
WCML 5.3 (and successfully cross-checked previous)
SystemPay 1.11.1
WCML 5.3 >> redirect to orginal language checkout page before rederecting to payment platform with wrong currency == Doesn't work
Exact same setup with WCML 5.2.1 > Redirectief to french checkout page > redirected to french payment platform, with correct currency == Works fine
Disable all other possible plugins cross checked : same results
Thanks for trying my suggestions and adding a detailed description. It helps!
It seems we are facing an issue specific to the Systempay for WooCommerce plugin. This plugin is unknown to us and not on our list of officially compatible plugins: https://wpml.org/plugin/
We need to replicate this issue on a fresh WordPress installation. Then, I'll be able to escalate it to our compatibility team. For this, I created a test website with a clean WordPress install. You can access it through this link:
hidden link
With this link, you'll be directly logged in.
Could you please install the Systempay for WooCommerce plugin and see if the issue is replicable on a clean WordPress installation?
Please configure WPML and WooCommerce as set on your site (just the basic configurations needed to replicate the issue are enough).
Please also ensure you install the latest version of the plugin.
Please let us know when everything is finished and you can replicate the problem.
I configured the environment as close as ours as I could.
- Added WooCommerce + WCML + SystemPay (Lastests)
- Configured them with the same settings
- Added a second language (FR), added a product
- Added SystemPay as a french only payment method
- Tried many payments
Unfortunately, I couldn't reproduce the issue.
In your test environment, after clicking the confirmation button, sends from /fr/paiement/ to /fr/paiement/order-pay/, then to the SystemPay external payment page, pricing in €
In ours, after clicking the confirmation button on the /fr/validation/ (same as paiement in your env) page, we got to ... /checkout/, then to the SystemPay external page.
Something prevents translating the /fr/validation/ section of the URL in /fr/validation/order-pay/, only ince WXML 5.3.
Do you have an idea of what can provoke this behavior.
Our WooCommerce store is 5 years old. Maybe some settings were introduced differently at that time, and are not interpreted correctly anymore?
Hi, and thanks for testing this on the sandbox site.
I suspect that there is a collision with the theme or another plugin that might cause this problem. If possible, get your site into a minimum environment. Minimum environment means switching to a default WordPress theme like TwentyTwenty-One and no plugins activated except WPML.
First, you will need to check if the problem persists when the theme is switched to TwentyTwenty-One (for example). If it persists, then deactivate all plugins except the WPML and its add-ons, WooCommerce itself (without its extensions), and the SystemPay plugin. Then please check if the problem persists. If it does not persist, start by activating the plugins one by one and check when the problem comes back, then report to me which was the culprit plugin.
**** Important! Please make a full site backup (files and DB) before you proceed with those steps****
*** If your site is live, you might want to try those procedures in a staging environment or a snapshot of your site on your local server or another server. ***
I ran my tests with the Storefront theme, instead of our custom theme, with only these plugins active:
Systempay for WooCommerce
WooCommerce
WooCommerce Multilingual & Multicurrency
WooCommerce Stripe Gateway
WPML Multilingual CMS
WPML String Translation
So tell me if I'm wrong, but I think there shouldn't be any custom logic involved in that setup.
When I order from the French version of the website, I'm redirected to /checkout/ with both SystemPay and Stripe, with WCML 5.3.
and to /fr/validation/, with both of these payment methods, when usind WCML 5.2.1.
I didn't know the WooCommerce Stripe Gateway plugin was also needed for this issue. But in general, I'd say that it sounds like you did the test correctly. On the other hand, we can see (as you tested) that it does work with the same setup on the test site. So, it is weird that it still happens on your site.
Please let me have access to your site. I will need to consult our second-tier supporters on this issue.
Alternatively, please contact the developers of Systempay for the WooCommerce plugin with this issue.
If you need further help with this, please share the access details to your site with me.
I'm enabling a private message for the following reply.
Privacy and Security Policy
We have strict policies regarding privacy and access to your information. Please see: https://wpml.org/purchase/support-policy/privacy-and-security-when-providing-debug-information-for-support/ **IMPORTANT**
- - Please backup the site files and database before providing us access. --
-- If you have a staging site where the problem can be reproduced, it is better to share access to the staging site.--
You wrote: "What I can do, though, is providing you with the database.
Try replicating the issue with that, then if needed, I can provide you with your code."
Can you please explain to which code you refer to?
Something is wrong with the Dropbox link you sent me. I get nothing with this link. In any case, it is better that you will migrate your site to our Cloudways server. In the next private message, I'll share with you all the details on migrating your site to our server.
Please replace the ftp:// part with https:// to get the proper DropBox link.
The code I'm refering to is basically our wordpress files. But again, since we use Storefront and no other plugins than the ones mentioned, it shouldn't be involved, thus needed.
I just applied this database to a fresh clean WordPress install, on which I only added the plugins mentioned earlier, and StoreFront theme. Same issue.
I want to remind you that Systempay for WooCommerce is not officially compatible with WPML and WooCommerce Multilingual & Multicurrency. According to our records, only a few of our clients use this plugin. I checked with my colleagues and searched our forum, and could find a similar report. That ,said we want to try and help further. You were not able to replicate the issue on our sandbox site. And you cannot give us access to your site (it is a local site, as you say). To check if we can help further, we need a copy of your site migrated to our Cloudways server. I think you might have missed my previous private message with the details on migrating your site to our Cloudways server. So I'm adding it again in the following private message.
I didn't want to send the website because it has huge content.
Moreover, by experience, I never got to transfer the website to you guys, there's always something going wrong.
Anyway, I cleaned it to make it smaller for you.
I removed the uploads folder content, and plugins not in used, from the system file.
Then I tested, again, the site works, and the issue is definitely still there.
Now, I filled all the required information.
Unfortunately, the transfer didn't work:
"Sorry! We do not support migrations of local sites which are unreachable over the Internet."
I can't drop content from a working environment to allow you to make a copy.
I can do it on a local env, but your tool won't handle it.
So I guess the best only option is to let me send you a DB + WordPress SystemFile, so that you can install it yourself.
