[Resolved] AJAX cart is returning the wrong language
This thread is resolved. Here is a description of the problem and solution.
Problem: The client was experiencing an issue where AJAX fragments in a mini-cart were returning in the wrong language when the page was cached. This problem persisted despite the 'Store a language cookie to support language filtering for AJAX' setting being enabled. The issue seemed related to the timing of the cookie change during page load, which was suspected to be too late, affecting AJAX actions.
Solution: We recommended the client to deactivate all unrelated plugins and test with only WPML, LiteSpeed Cache, WPML String Translation, WooCommerce, BricksUltimate, and WPML Multilingual & Multicurrency for WooCommerce active. This setup did not reproduce the issue, suggesting an interaction between LiteSpeed and another plugin was causing the problem. We advised the client to identify the problematic plugin by reactivating them one by one and checking the mini-cart's behavior. Additionally, we provided a workaround involving a custom plugin designed to handle the specific caching and language switching scenario. The client was instructed to install and activate this plugin, then monitor the mini-cart's behavior.
If this solution does not resolve the issue or seems outdated, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If problems persist, please open a new support ticket at WPML support forum.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Please add this code to the functions.php file located in the active theme's folder:
/**
* Add a url parameter lsed=1 to language switcher URLs to be able to detect
* when a page loads after switching language.
*/
add_filter( 'icl_ls_languages', function( $w_active_languages ){
foreach ($w_active_languages as $lang => $w_active_language) {
$w_active_languages[ $lang ]['url'] = add_query_arg( 'lsed', 1, $w_active_language['url'] );
}
return $w_active_languages;
}, 1000, 1 );
All this does is add a parameter into the URL when using the language switcher. And on the test website this parameter (lsed) has been added into "Do Not Cache Query Strings".
So, of course when adding this code into the test website, the pages are no-cache if the parameter is present in the URL...
Page set to no-cache = no problem with language.
Page set to cache = problem with language <- we are trying to fix there.
Very weird solution to provide considering all the info I previously gave. The language issue is not only when using the language switcher, it's sometimes even there for new users, first time on the website.
In the specific scenario where a site visitor uses the language switcher, only the subsequent page load is not from the cache. Any other page load is unaffected, and is still delivered from the cache. The solution offered specifically targets what happens if clients use the language switcher, which would be a small minority of page visits, something that most clients would do only once, if at all.
I understand the thought of the 2nd-tier specialist now. While this does not fix the root of the issue, this might be a acceptable band-aid fix. Since this way there is almost no (logical) way to 'bring' the wrong/previous mini cart language into the other language page' cache.
The only way to still 'bring' the wrong/previous language cart would be to change URL in the current browser like from /fr/ to /en/. But after two months I am kind of done with this problem, so let's ignore this one.
I will add this fix into the main website and test a couple days to see how thing go.
I thought this would be it, but no... the thinking of the specialist was right, but unfortunately this problem goes deeper.
I added it to the main website, did some tests which seemed to go good at first. I had to change one small thing due to some of my pages having parameters I cannot change: now when using the language switcher you always go to the new language homepage with the ?lsed parameter - but that's fine, same no-cache effect.
Then I triggered /de/?wc-ajax=get_refreshed_fragments while being on /de/?lsed=1 (no-cache page). And boom, the cart refreshed into the Dutch language, while we are on a German page + set to no-cache...
Then on the German page I changed quantity of something in the cart, and the cart language changed to English... (trigger: /wp-admin/admin-ajax.php?lang=de&action=buwoo_update_cart_item_quantity&cart_key=dcd2..[..]..)
If you want you can see it happen on the main website mr - ezy .com. It's just how this BricksUltimate plugin handles the caching/language within his modules/elements. I asked him again to help but he still couldn't find the issue...
The issue appears to be specific to the Bricks Unlimited mini-cart. When using the default Bricks mini-cart, everything functions correctly with WPML and no custom solution is necessary.
Please note that Bricks Unlimited is not listed among our officially compatible plugins: https://wpml.org/plugin/
. While we aim to assist with such cases, support for non-compatible or minor third-party plugins is limited. We've already done some investigation on our side, and based on our findings, we recommend one of the following approaches:
- Use the default Bricks mini-cart, which works as expected with WPML.
- Contact the Bricks Unlimited plugin author to encourage them to join our Go Global program
and make their plugin officially compatible with WPML.
We’re happy to continue helping as much as possible, but for long-term compatibility, direct action from the plugin developer is essential.
