I can't add a new language because the request takes more than 60 seconds.
I tested it with new WPML and WordPress versions and I face the same issue.
This is our 15th WPML language, I already provide 512 mb PHP 8.3.30 memory_limit, WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT, and 1200 execution time.
Provide a longer max_execution time and set a timeout works locally, but won't do it on this environment nor production since we can't go beyond 60 seconds when behind CloudFront. So is there a way to create new languages from command line? Or a way to bypass this limitation?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Madrid (GMT+02:00)
To find out the details of the error you are getting, could you do the following?
- Access the wp-config.php file (located in the WordPress root).
- Insert these lines just before /* That's all, stop editing! Happy blogging. */
The code you provided is intended to verify whether the new language has been created and is active.
As I mentioned earlier, in our environment the language does exist and is active: it is visible both in the admin panel and in the language switcher.
However, the request that initiated its creation ended with a timeout (503 error).
In other words, something did not complete properly. At least one of the steps involved in the language creation process must have failed or been interrupted. Otherwise, the process would not have terminated with a timeout.
Additionally, there are no error logs. Only a server timeout, with no further details available.
Our server is quite powerful, yet 60 seconds is not sufficient to complete the language creation. That is already a reasonable execution time for a script. I’m not sure what the full process involves, but if adding a new language in WPML cannot complete within that timeframe on a robust server, we need an alternative method.
Specifically, we would need a way to trigger the language creation via the command line rather than through the admin interface, which is limited to a 60-second timeout due to CloudFront.
Could you please advise if such a solution is available?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Madrid (GMT+02:00)
At the moment, there isn’t a WP-CLI workaround available to add a new language in this case. However, we’ve identified that a large part of the delay is caused by downloading the language translations during the process.
As a possible workaround, you can try the following steps:
- Temporarily deactivate all WPML plugins (this will make the site non-multilingual for a short time).
- Go to Settings → General in WordPress.
- Change the Site Language to Portuguese (Brazil).
This will trigger WordPress to download the required language files.
- Once the download is complete, reactivate only WPML.
- Try adding Portuguese (Brazil) again from WPML → Languages.
After that, you can reactivate the rest of the WPML add-ons (OTGS plugins).
This approach may reduce the processing time and help avoid the timeout issue.
I’m afraid I don’t have the capacity at the moment to investigate another WPML-related issue, as I already have one ongoing in one of your sandbox environments.
Our WordPress setup is indeed quite heavy, but it performs reliably overall—most requests complete in under two seconds. However, this particular request consistently takes over 60 seconds. From what I’ve observed, this issue did not occur with the previously configured languages. It also appears that the more languages are added, the longer the creation request takes, which suggests a structural limitation rather than something that can be addressed on my end.
Given this, and considering that a fix is unlikely in the immediate term, I would appreciate a way to run this process via the command line. This would avoid browser or admin timeouts and seems like a practical workaround in the current situation.
Thank you for your understanding.
Best regards,
nb: when an issue is moved from chat to ticket, the user email notification are always off (or at least that's waht I noticed).
I can't think of a reason where users wouldn't want to be informed of their ticket updates.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Madrid (GMT+02:00)
Hi!
Would it be possible for you to create a staging site where we can investigate the issue directly? This would allow us to take a closer look and work towards providing you with a proper solution.
Hi,
First, sorry to say but it's a real pain: saving the setting so that I can get the notification fot this topic doesn't work, so that I just discover your answer, 5 days after.
I tried again right now: No email notifications > Change > Email notifications about ALL answers (spinning wheel > OK) > Reload >> No email notifications!
Thanks for fixing this.
Regarding the issue, I can provide access to a staging environment, with all plugins up to date, wand where I can disable plugins and move the theme to storefront..
You'll have to use an ovpn client with ovpn custom file that I'll provide you with.
Is that OK for you.
If so, thanks for opening a secure message so that I can provide you with the required information.
1. It finally worked, with the same browser without doing anything different...
2. Before sharing the access to the test environment, I extended the server timeout values to 600 seconds for apache and nginx, then I created of a new custom language.
Nothing happened during... 10 minutes (=600 seconds), then I got the same error:
(70007)The timeout specified has expired: [client ::1:34798] AH01075: Error dispatching request to : (polling)
So obviously the request won't resolve even after 10 minutes in this environment 🙁
Any idea how to investigate it further. Since we don't get much logs?
Not sure it's worth sharing the environment (anyway, I can't share the ovpn file from this form).
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Madrid (GMT+02:00)
Thank you for the detailed update, it’s really helpful!
At this point, I’d recommend trying to reproduce the issue in a minimal environment to rule out any conflict with plugins or the theme. You can do this by temporarily disabling all plugins except WPML and switching to a default theme (like Twenty Twenty-Four), and then testing the same action again.
If the issue disappears, it’s very likely caused by a conflict, and we can narrow it down from there.
If the problem still persists even in a minimal setup, it would be very helpful to get access to the environment so I can escalate this to our second-tier team for deeper investigation.
I understand the limitations with sharing access (like the ovpn file), but if there’s any way to provide temporary or alternative access, that would really help us move forward.
I created a minimal environment, with:
- WordPress 6.9.4
- Storefront standard theme,
- WooCommerce + WPML plugins active only.
I tested the new language creation process with both our current verisons of the plugins, and the lastest, all up to date.
Result is the same: after clicking add language, the request will not resume properly. The page is not reloaded, and the language is not created.
For this local test, I set:
php max_exectution_time to 1200.
apache2 Timeout/ProxyTimeout set 1200.
So we're not even chasing a 60 seconds issue.
I just get a timeout after 20 minutes, and the language is not created.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Madrid (GMT+02:00)
Yes, please! I have enabled the next reply as private so you can safely share the login credentials.
Additionally, could you confirm if you grant permission to download a copy of the site using Duplicator? This will allow me to escalate the issue to our second-tier support team for further investigation.
