This thread is resolved. Here is a description of the problem and solution.
Problem: The client reported an issue where their site was forced to run from the /fr/ directory due to .htaccess rules after updating WooCommerce. This was linked to WPML's handling of 'Different languages in directories' setting. Solution: We identified that the issue was caused by third-party plugins calling the
If this solution does not apply to your case, or if it seems outdated, we highly recommend opening a new support ticket. Also, please check related known issues at https://wpml.org/known-issues/, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. For further assistance, you can contact us directly at the 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.
Background of the issue:
I’m reaching out regarding a recent issue on my site that may be linked to WPML's handling of .htaccess rules. I use WPML with 'Different languages in directories' (Dutch as the default, French at /fr/). Upon further investigation, I discovered that my .htaccess contained a block that forced everything to run from /fr/. Here’s the relevant section: # BEGIN WordPress RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase /fr/ RewriteRule ^index.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /fr/index.php [L] # END WordPress. After removing the forced /fr/ lines and flushing permalinks, the site works correctly again.
Symptoms:
When updating WooCommerce from 9.5.1 to 9.5.2, I encountered a fatal error: 2025-01-09T08:00:23+00:00 Critical Uncaught Error: Class "WC_Notes_Refund_Returns" not found in /data/sites/web/mysite/www/wp-content/plugins/woocommerce/src/Internal/Admin/Events.php:132. I rolled back to 9.5.1, but the site still wouldn’t load correctly afterward. Hardcoding /fr/ in .htaccess breaks the Dutch default language.
Questions:
Could you please review how WPML is handling .htaccess to ensure it’s not introducing (or re-introducing) this rewrite block?
Is there a way to prevent WPML from overwriting the default WordPress/WPML rewrites?
Sometimes, third-party plugins call the flush_rewrite_rules(true) function too often. This leads to changes in the rewrite rules in your .htaccess file, which can cause issues on your WordPress site.
This becomes problematic when it occurs during every page request or while you browse your site in another language. When this happens, WPML goes ahead and adds the language folder to home_url as usual. However, this results in an incorrect RewriteBase in .htaccess, causing your website’s front-end to break.
In this case, WPML is acting correctly and the problem is entirely in the plugin calling this function too often.
Please check the next link for further info on the workaround (make sure to resave permalinks) and how to diagnose the plugin that is causing the issue:
WP-Rocket would like to learn on how they could help counter this issue in the future. Could you help me with it? It is one of the most used caching plugins so this is useful. This is the reply I got from WP-Rocket.
---------------------------------------
So, based on the WP Rocket rules not being currently present (after reset by host company) in the htaccess file and the conclusion reached here:
Once the .htaccess was fixed (removing /fr/ from the WordPress block) and WooCommerce was properly reinstalled/rolled back, the class error typically goes away. So while the rewrite issue is not the only factor (incomplete or corrupt update files are the real cause of the missing class), it very likely exacerbated or triggered the conditions under which the "Class not found" error arose.
It seems like it might be a good idea for you to work with the WPML team about how language redirects caused the issue to see if they might have suggestions about how to prevent that from happening again so there are no future issues with updates to your plugins.
I'm glad to know you were able to find the source of the issue, and thank you for letting me know!
--------------------------------------
as far as I know, WP Rocket is not causing this issue and it is an officially compatible plugin, our devs collaborate and they also have direct contact with our compatibility team and test our plugins for any issues.
If you or they think there is in conflict with WPML and WP rocket, you can confirm it and reproduce it with only those plugins, please let us know or they can contact us directly and our devs will be glad to collaborate further. As far I know this kind of issue are caused by less popular plugins and you can confirm it as shared in the related docs before.
I gave up trying to figure out what went wrong and gave updating Woocommerce another go. This time things seems to have worked out. Must have been a corrupted updated.
I wonder why WordPress doesn't validate updates for every plugin like apple does for its updates before it tries to activate the update.
I will monitor the htaccess for a while to see how the rules return.
