URGENT Base language content shown on non-base language pages

Wordpress LScache Plugin: URGENT Base language content shown on non-base language pages

I maintain a large WooCommerce webshop that runs on a Litespeed server in combination with the Litespeed Cache plugin. The base language of this shop is Dutch and is offered in various languages through the translation plugin Weglot (https://weglot.com/). Unfortunately, something goes terribly wrong with the caching, which means that the content of base language Dutch is shown on, for example, English pages. An example of this is https://duux.com/en/customer-service/ where you will see Dutch content instead of English. Once you add a URL parameter, this no longer happens. This indicates that it has to do with the Litespeed caching. Customer service is now overloaded with complaints, so I would like to ask if you can look into this as a priority. Useful environment info: ? WordPress 5.9.3 ? Litespeed Cache 5.1 ? Weglot Translate 3.6.1 ? Litespeed report number QVWMMHII If you need anything else from me please let me know! This topic was modified 2 weeks, 2 days ago by mvereijken. The page I need help with: https://duux.com/en/customer-service/ I have no good news for you? Weglot Translate plugin isnt ready to be used with any cache plugin, but LiteSpeed LScache (not the plugin) has a solution for it. However, this solution requires a modification to the language plugin. I wonder how could that text overlap to other page but please try disable object cache , purge all , see how it goes @CacheCrawler Thank you for your contribution! Could you tell me more about this solution and where I can set it up? Thanks in advance This cant be explained with a few words, because you must have extended knowledge about how LiteSpeed LScache works, but will try it. LScache uses so called Cache Vary . That means each URL can be cached with different cache copies depending on user related facts like cookie, device and many others. The problem in your case is that this language plugin uses PHP and detects language using PHP, but if a page is cached there is no more PHP interpretor, because a cached URL is pure plain text and plain text cant execute PHP. To make this plugin work with LScache a cookie must be set with different cookie value depending on the selected language. Then this cookie can be used for cache vary so each language gets its own cached copy. Read more about Cache Vary: https://docs.litespeedtech.com/lscache/devguide/advanced/#cache-varies @CacheCrawler Thanks for helping out! Another question regarding your comment: Is it possible to set this cookie within the theme (using something like https://developers.weglot.com/wordpress/helpers-functions#weglot_get_current_language) or does it need to be set within the translation plugin itself? As soon as I have this clear, I can choose to install it myself or contact Weglot. The plugin must set the (1) cookie with different value for the language depending on user selection. For the case this plugin has automatic language detection this detection must be disabled. Otherwise the same issue will happen. @CacheCrawler Thanks for clarifying! Given the urgency of this bug, I dont want to rely too much on cooperation from the translation plugin support. For that reason I have just tried to make the necessary adjustments myself. The code I added is based on the LiteSpeed guidelines and can be found below: functions.php add_action( init, weglot_set_language_cookie, 1 ) function weglot_set_language_cookie() if( function_exists( weglot_get_current_language ) ) $lang = weglot_get_current_language() ? weglot_get_current_language() : nl else $lang = nl setcookie( weglot_lang, $lang, time() + ( 30 DAY_IN_SECONDS ), / , ) .htaccess X-LiteSpeed-Vary: cookie=weglot_lang What strikes me is that setting the cookie seems to go well in all cases. Even when the base language content is shown. See screenshot: https://snipboard.io/sw5kX6.jpg The fact that base language content is still displayed can mean two things: a) The cache vary is not properly implemented yet b) The cache vary only takes effect after emptying the entire website cache (Id rather avoid this) It would mean a lot if you could support again! a) The cache vary is not properly implemented yet Cache vary works like variable and may not be fixed like in your code. RewriteRule . - [E=Cache-Vary:weglot_lang] b) The cache vary only takes effect after emptying the entire website cache (Id rather avoid this) This I already described. If a page is cached there is no more PHP, so thats why your code cant work. The cookie must either be set by $_POST, because $_POST requests are not cached or set by Javascript. FYI: Your cookie is wrong. SameSite attribute is missing. @CacheCrawler You are the WP expert. Could you support thread starter in the current case?