This thread is resolved. Here is a description of the problem and solution.
Problem: The client reported that WPML's string translation feature was causing server overload by repeatedly flushing the WP cache. This resulted in increased hosting costs due to auto-scaling and deteriorated user experience. The client asked if it was possible to limit update runs to only run on cron and requested a fix to minimize the use of
wp_cache_flush()
and instead delete only necessary data. Solution: We identified that the 'wpml' directory was missing from the '/languages/' folder, which is essential for WPML to load translations properly. We asked the client to confirm the presence of this directory and gather information about any recent changes to their theme, plugins, or hosting environment that might have affected this folder. Additionally, we recommended replacing the use of
If this solution does not resolve your issue, or if it seems outdated or irrelevant to your case, 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 further assistance is needed, 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.
Background of the issue:
Once a day wpml-string-translation/classes/upgrade/class-wpml-st-upgrade.php <code>public function mark_command_as_executed( $class ) {</code> calls wp_cache_flush() around 50 times in a single request - since it's usually not a single request that hits our site at once but on average it's 5 requests (around 10-15 non-page-cached requests/second on our page) it's 250 calls to flush the cache.
This puts enormous load on the cache backend, since flushing is extremely expensive, as it requires a full scan of the key table, but also causes the huge load spikes on all servers and deteriorated user experience, since the page and object caches get flushed, which means that all subequent page loads require being handled by PHP instead of being served directly from the page cache.
These load spikes then cause auto-scaling to prepare new instances, resulting in lots of extra hosting cost.
Symptoms:
The repeated flushing of the WP cache by WPML's string translation feature causes server overload, crashes, and increased hosting costs due to auto-scaling.
Questions:
1) is it possible to limit the update runs to only run on cron?
2) please fix your wp_cache_flush() use and only delete data you actually need to delete to prevent crashing our site
One of the server handles exclusively CLI (e.g. wp-cron) requests.
There's a bug in string translation that it won't create the WP_LANG_DIR/wpml directory (and files) on those CLI requests it seems, bc that direcetory does not exist on the server.
Subsequently
wpml-string-translation/classes/MO/File/FailureHooks.php
public function checkDirectories() {
will run
if ( $this->isDirectoryMissing( self::getSubdir() ) ) {
$this->resetRegenerateStatus();
which invalidates the WPML settings "_has_run" and cause the updates to run again (and therefore flush the cache)
This happens also/again every time we add a new server (since we do not create/copy the WPML_LANG_DIR/wpml directory as instructed by your guide, since that's what WPML_ST_SYNC_TRANSLATION_FILES is for)
Since the new server doesn't have the directory, it invalidates and then runs all updates again causing the cache to be flushed, leading to a negative feedback loop.
This is especially bad, because it will mark incomplete (via resetRegenerateStatus()) on server 1, but then the request in wpml-string-translation/classes/upgrade/class-wpml-st-upgrade.php will run on most likely any other server (e.g. 2), which means this happens repeatedly all the time, until through pure luck, a request is processed to regenerate on server 1.
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+01:00)
Hi,
Thanks for the detailed analysis and suggestions.
I've forwarded this to our developers for further review and investigation. We'll follow up here as soon as we have any updates or need additional input from your side.
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+01:00)
We’ve noticed that the `wpml` directory is missing from your `/languages/` folder, can you confirm this?
Normally, this folder is required for WPML to properly load translations (unless you are running in DB translation mode, which is only active temporarily during auto string registration).
To better understand the situation, could you please confirm:
1. Was the `wpml` directory ever present and possibly removed during an update, migration, or cleanup?
2. Have you made any recent changes to your theme, plugins, or hosting environment that might have affected the `/languages/` folder?
3. Do you recall if translations were working correctly before this issue started?
This information will help us determine whether the issue is related to missing files, a configuration change, or something else in your environment.
1) yes, it is present on some servers
It's missing only on new servers, since the directory won't be deployed to a new server since WPML will/should create it itself.
I didn't check the underlying code in your plugin, but possibly, DISALLOW_FILE_MODS constant (which is true in our case) might also play a role in why the directory isn't created, but just a guess
2) yes, updated all WPML plugins from old to latest version
3) yes, it worked correctly with a rather old WPML version, we only recently updated from the old version to the latest WPML, and since then we had this issue
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+01:00)
Since this issue may be related to the upgrade path from an older WPML version (possibly before the current .mo file logic was introduced), it’s important for us to reproduce the exact scenario.
Would it be possible for you to provide us with a package or a copy of the site/server where the problem occurs? That way, we can check if the update logic might have been skipped or stuck during the upgrade.
If preparing a full package isn’t feasible, even a minimal reproducible setup (for example, a fresh site where you upgrade from the older WPML version you were using to the latest one) would already help us confirm whether this is the cause.
