Hello, I am not 100% sure this is WPML related or a caching issue, but maybe you guys know something about this issue, I've been trying to solve this for days now...
I have a mini cart, that uses AJAX to be refreshed. For some reason the AJAX fragments return in the wrong language, but it seems to only happen if the page is cached. Is this something you can support me with?
Store a language cookie to support language filtering for AJAX is switch ON. But when switching language, the cookie changes pretty late during pageload from e.g. EN to NL. I was thinking maybe that has something to do with it, and the AJAX action happens before the cookie has changed?
So, I deactivated all unrelated plugins, and left only WPML, Litespeed Cache, WPML String Translation, WooCommerce, BricksUltimate and WPML Multilingual & Multicurrency for WooCommerce active.
In this scenario, the issue is not happening anymore. Please check here: hidden link
My recommendation is for you to check what specific plugin is causing this, then replace it, remove it, or try to fix that plugin. Per se, it's not a direct WPML issue, but an interaction between Litespeed and something else.
Thank you for looking in to this. However, this did not solve the issue - even in your video, the English cart is in Dutch. "Uw winkelmandje" and "Your shopping cart" are not part of the WC AJAX fragments.
For testing purposes you should look at "Aantal"(Quantity) and "Kleur"(Color). Sorry if I was unclear: it's not the entire mini cart element, it's only the part that gets AJAX refreshed.
I also have one more block under it which is inside a "Content updater" div (BricksUltimate element) (basically reloads everything inside that div on ?wc-ajax=get_refreshed_fragments). I made it visible now, since it was hidden due to a broken condition after switching off one of the plugins. Now it's easier to see if the cart is the right language or not.
Thanks for bringing that to my attention. I was able to properly reproduce and check this time around. I've escalated this to analysis, and will get back to you as soon as I have new information. This might take a day or two. Thank you for your patience.
Thank you for waiting. Second tier added "woocommerce_cart_hash" to the list of excluded cookies, and now it seems to be working. Check the image. Can you please test and confirm?
If it does, you can apply the same solution to your production website.
Unfortunately not. Adding that to excluded cookies "breaks" the caching, and the pages are set to no-cache. Please see the network headers of the pages now: x-litespeed-cache-control
no-cache.
While yes, the cart is now the right language, this "fix" is equivalent to switching LSCache caching completely off, and that's not a fix for me.
I completely understand. I've taken that to our devs. They might need new information or tests soon, I'll keep you up to date. Thanks for the prompt feedback.
We've made many tests, but couldn't reach the exact result you wanted, simply using the Litespeed and WPML options. It doesn't seem to be possible in your specific scenario.
"In short, without page-level caching, when you use the language switcher to go from, say, English to Spanish, we'll get a GET request for the Spanish URL, and the Response Headers for that request will include a set-cookie header which updates the wpml_current_language cookie to es.
Then when you get ajax requests (in this case a request to refresh cart fragments, but it could be anything), the correct es value is sent for the language cookie in the request headers.
Now imagine the same, but with page-level caching active.
Using the language switcher we get the same GET request, but this time the page will be served from the Litespeed cache, and that response does NOT include a set-cookie header.
So upon completion of the page load, we have a Spanish page, but the wpml_current_language cookie is wrong, it is still set to en, and that can mess with subsequent ajax requests like the refresh fragments request."
We've come up with a plugin that applies a workaround, but we need to test that on your staging website. Can you please confirm that you have a backup, and that we can proceed?
Thank you for investigating and providing the explanation. Yes please, you can go ahead and perform tests on the dev/staging website, it has backups every day 7:00 AM.
Thank you for waiting. The 2nd tier team came up with a workaround. It's a simple plugin that needs installation and activation. You can download it here:
hidden link
Here are the tests we made:
"I added the plugin to the staging site and activated it, as well as making sure LiteSpeed was active. I cleared the cache to reset any cached versions of the pages.
I visited the front end test product and toggled back and forth between the languages to make sure the cache was populated.
Then when I used the language switcher to change from Dutch to English and back again I saw that the cart contents were in the correct language, and when inspecting the Network requests I noted that the results were served by the cache.
So, the client should be good to continue with the provided workaround."
Thank you and the 2nd tier team for the workaround/plugin. This does unfortunately not work. Tested on both the dev/staging website and the live website.
hidden link
I also feel like the issue is not fully on the cookies side of things. Because I noticed on the live website, that sometimes just changing quantity or AJAX reloading the cart also shows a random other language. Not even needing to be on that language page at all. I now got website visitors having a french cart, while they are the first time on the website (Dutch).
In the meantime, is it possible to only show the Dutch language in the cart - without deleting the other translations/languages? Just to make sure the cart is always 100% dutch, most of the visitors are dutch anyways, so I don't care for now it the cart is in dutch for a french/german/... visitor.
I hope the 2nd tier team will still be able to help with this, but in the meantime I will also start a ticket at LSCache, since this is a pretty urgent thing for me.
I’ve reviewed the latest tests, and here’s where things stand:
The caching setup appears to be functioning correctly - 2nd tier support insists on this. When switching between English and Dutch, the correct language cookie is being set and used for the cart’s AJAX requests—this was not the case before. That confirms the original cache-related issue has been resolved.
However, we’re still seeing that some parts of the mini cart are returned in English, even though the request is made in Dutch. This issue seems to have started after all plugins were reactivated on the site. Based on the current behavior, we suspect the Bricks extension plugin—used to render the mini-cart—might be interfering, but we can’t confirm that yet.
To move forward, Nigel needs access to continue testing on the server. This includes disabling plugins temporarily to isolate the root cause.
Let us know if we have your approval to proceed with those tests.
As you can see in the video (all the broken styling), it was made before I switched some of the plugins back on.
I cloned the staging website, please perform any new tests on: hidden link
I switched all the other plugins off on this website. I need the other staging website to test some new elements/functions for the main website and I don't want to interfere with your tests.
