At this point, we'd need to take a closer look at your website to understand what's causing the issue.
If you're comfortable sharing access, please provide us with temporary WordPress administrator credentials (and FTP access as well, if possible). This will allow us to investigate the problem directly on your site and determine the cause.
Once we have access, we'll continue our investigation and get back to you with our findings.
I think it's the 3 time I repeat you have everything you need to replicate the issue on the website I provided you with, and that I CAN'T provide you with an environment that's CloudFront limited.
This ticket has now been open for almost four months.
Four.
Months.
During that time, I've run countless tests, updated/activated/deactivated plugins, switched themes, and tried all the fix you suggested. None of them resolved the issue.
The only way I've been able to add a language without problems is by disabling every plugin except WPML Multilingual CMS. I'm sure you'll agree that this is not a satisfactory solution.
I've reproduced this issue on multiple environments, including one that was recently set up after a thorough database cleanup.
Another user has also joined this ticket because they're experiencing the exact same issue, and the proposed fix didn't work for them either.
I've already provided you with our website and database.
Yet you keep requesting access to our test environment, even though I've explained 3 times that:
- It's not easy for me to set this up.
- It would prevent me from working on the environment while you're testing.
- It wouldn't be useful, since I won't be providing server access.
- This environment isn't behind CloudFront anyway
- You can reproduce the issue and delays without CloudFront limitations
From my perspective, it seems the issue still hasn't been properly investigated. I also haven't received an explanation as to why access to the test environment is still required (I think made it clear it's pointless), while you have my database and file system to do the same tests.
Do you neeed guidance to setup the website locally?
Finally, you persist saying I'm the only one facing the issue, as if Lukas Leitner didn't leave his message in this very same ticket.
Can you please clarify what's going on? Don't you think it's important to be able to add language on a website? Is someone going to take a proper look at this issue and investigate it thoroughly?
First of all, I'd like to apologize for how long this issue has been taking. I completely understand your frustration, especially considering all the time and effort you've already invested in troubleshooting this.
I've escalated your latest feedback to our Second Tier team and shared all the points you've raised, including your concerns about the staging environment and the fact that you've already provided the website files and database.
I'm currently waiting for their feedback on the next steps and on why they still require staging access in this case. As soon as I receive an update, I'll get back to you with more information.
Thank you for your patience, and I appreciate you taking the time to explain your concerns so clearly.
Thank you very much for your patience while our developers continued investigating this issue.
They have prepared an alternative workaround that we'd like you to test while the permanent fix is being finalized (it is currently planned for WPML 5.0).
Please remove the previous custom code I shared with you and instead create the following file:
<?php
/**
* Plugin Name: Custom WPML Support
* Description: Workaround for slow add languages
* Version: 0.1
* Author: OTGS Support
*/
/**
* Workaround for slow "save active languages" in WPML (wpmldev-6897).
*
* When WPML saves the active languages it re-downloads every plugin language
* pack for every language, even when they are already installed. This snippet
* skips the download for packs that are already present. Packs for a newly
* added language are still downloaded normally.
*
* Remove after updating to a WPML release that contains the fix.
*/
add_filter( 'upgrader_pre_download', function ( $reply, $package ) {
if ( ! isset( $_REQUEST['action'] ) || 'wpml_set_active_languages' !== $_REQUEST['action'] ) {
return $reply;
}
if ( ! is_string( $package )
|| ! preg_match( '#downloads\.wordpress\.org/translation/plugin/([^/]+)/[^/]+/([^/]+)\.zip#', $package, $m ) ) {
return $reply;
}
$installed = wp_get_installed_translations( 'plugins' );
if ( isset( $installed[ $m[1] ][ $m[2] ]['PO-Revision-Date'] ) ) {
return new WP_Error( 'wpml6897_pack_installed', 'Language pack already installed - download skipped.' );
}
return $reply;
}, 10, 2 );
This workaround prevents WordPress from downloading plugin language packs that are already installed when saving the active languages in WPML. Newly added language packs will still be downloaded normally, but existing ones will be skipped, which should significantly reduce the execution time.
Once you've added the file, could you please test adding or saving the active languages again and let me know whether you notice an improvement?
I look forward to hearing your results so I can report them back to our development team.
Yes, they tested it, including the first workaround, and it worked correctly on the environment you provided. They were able to add the language without any issues.
That is why our second-tier team is requesting access to your environment. They need to investigate why the workaround is not working properly on your site, even though it works as expected in the test environment.
Since the MU plugin did not resolve the issue on your site, could you please try adding the same code as a snippet (or, alternatively, to your child theme's functions.php file)?
In some environments, the loading order of MU plugins can differ, while running the code as a standard WordPress snippet may produce different results.
If it still doesn't work, please let me know, as that would indicate the workaround is not being applied in your environment and we'll continue investigating.
I did. No more luck.
Best way is you guys test it yourself locally, on the database/filesystem I provided, as I've been suggesting for weeks. So that you notice what's going wrong.
They already tested it using the local copy of the site you provided, and that's actually why we're in this situation.
On the local environment, everything worked correctly, including the first workaround that was provided by our developers. We were unable to reproduce the behavior you're experiencing on your server.
This is precisely why our second-tier team keeps requesting access to your environment. At the moment, they don't understand why the workaround works correctly on the local copy of your site but not on your actual server.
Since the issue cannot be reproduced locally, the only way to identify the root cause is to compare the behavior directly on your environment and determine what is different there.
So they did set the environment up?
I've been asking a confirmation for weeks, and never received it, so assumed it wasn't the case.
And your fix works?
- Which method did they use? Mu plugin, snippet, or added it in the functions.php file?
- Which plugin did they activate/deactivate?
- How long did it take to complete the language creation operation (from clicking Save, after ticking a new language?
Most of all: do they keep watching the "Downloading translations... Please don't close this page." message?
I tested your MU plugin on 2 environments:
- test server: here the operations completes, without error, but it took no less than 18 minutes.
- Locally: it failed exactly after 20 minutes (checked twice)
On both environment, the timeout is 1200s (=20 min).
When failiing, the "Downloading translations... Please don't close this page" message is replaced by the error message. And after a few seconds, the page reloads, with the new language listed as enabled.
If you miss the short error message, you're don't even know something went wrong.
