Skip Navigation

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.

Our wait time is higher than usual, please make sure you are meeting the minimum requirement - https://wpml.org/home/minimum-requirements before you report issues, and if you can take a look at current Known Issues - https://wpml.org/known-issues/. Thank you.
Sun Mon Tue Wed Thu Fri Sat
- 8:00 – 13:00 9:00 – 13:00 9:00 – 13:00 8:00 – 12:00 8:00 – 12:00 -
- 14:00 – 17:00 14:00 – 18:00 14:00 – 18:00 13:00 – 17:00 13:00 – 17:00 -

Supporter timezone: Europe/Zagreb (GMT+02:00)

Tagged: 

This topic contains 0 replies, has 0 voices.

Last updated by Bruno Kos 5 minutes ago.

Assisted by: Bruno Kos.

Author Posts
April 4, 2025 at 11:11 am

Gerardo Bramati

Background of the issue:
I am trying to address a slow website issue, particularly on the Dashboard side, where loading times can reach 15 seconds. Site Health indicates a large number of records in wp_option autoload. We've changed web hosting several times and even tried a local environment, but the website still times out with error 504. Using Query Monitor, I noticed a slow HTTP call linked to WPML: GET hidden link cURL error 28: Operation timed out after 5000 milliseconds with 1702220 out of -1 bytes received. The issue can be seen at hidden link.

Symptoms:
The website is experiencing very long loading times, especially on the Dashboard. There is a cURL error 28 indicating a timeout after 5000 milliseconds. The site also goes into timeout with error 504.

Questions:
How can I reduce the loading time on the Dashboard?
What can be done about the large wp_option autoload records?
How do I resolve the cURL error 28 linked to WPML?
What steps should I take to prevent the website from timing out with error 504?

April 4, 2025 at 12:30 pm
April 7, 2025 at 8:25 am #16902822

Bruno Kos
WPML Supporter since 12/2018

Languages: English (English ) German (Deutsch ) French (Français )

Timezone: Europe/Zagreb (GMT+02:00)

It looks like the REST API might be disabled on your site. To check this, we ping the REST endpoint and store the result as a transient. If that transient isn’t being set, the system keeps trying to ping repeatedly. This could be a sign there's an issue with the wp_options table in your database that's preventing transients from being saved correctly.

Can you please try the following:

1. Manually set a transient named `_transient_wp-rest-enabled-ping` with the value `enabled`. You can do this by temporarily adding the following code to your theme’s `functions.php` file or via a plugin like Code Snippets:

   add_action('init', function() {
       set_transient('wp-rest-enabled-ping', 'enabled', 12 * HOUR_IN_SECONDS);
   });

After adding it, visit your site in a browser to trigger the code, then you can safely remove it.

Alternatively, if you're using WP-CLI, run:

 wp transient set wp-rest-enabled-ping enabled 43200

2. Confirm that the transient was successfully set:
- Via database: Check your `wp_options` table and run the following SQL query:

SELECT * FROM wp_options WHERE option_name = '_transient_wp-rest-enabled-ping';

If you see a row with the value `enabled`, it’s confirmed.

- Via plugin: Install a plugin like https://wordpress.org/plugins/transients-manager, search for `wp-rest-enabled-ping`, and check if the value is set to `enabled`.

Let me know about the results!

April 9, 2025 at 9:30 am #16912210

Gerardo Bramati

I've enabled the transient but it seems that nothing has changed.

April 9, 2025 at 12:43 pm #16913593

Bruno Kos
WPML Supporter since 12/2018

Languages: English (English ) German (Deutsch ) French (Français )

Timezone: Europe/Zagreb (GMT+02:00)

To confirm, the transient was successfully set?

This code:

SELECT * FROM wp_options WHERE option_name = '_transient_wp-rest-enabled-ping';

returned something?

April 9, 2025 at 3:08 pm #16914829

Gerardo Bramati

I have used the plugin "Transients manager" but when I test the SQL return option_value "off", so I have added the code snippet in functions.php and the SQL returns:
5508142 _transient_wp-rest-enabled-ping enabled off

April 9, 2025 at 3:11 pm #16914848

Gerardo Bramati

Anyway the dashboard is still really slow and in Query Monitor I see 2 slow query:
UPDATE `NXrOmV8_options`
SET `option_value` = '1744254572'
WHERE `option_name` = '_transient_timeout_wp-rest-enabled-ping'

update_option()

Plugin: litespeed-cache

UPDATE `NXrOmV8_options`
SET `option_value` = '1744254573', `autoload` = 'off'
WHERE `option_name` = '_site_transient_timeout_rollback_themes'

update_option()

Plugin: litespeed-cache

Do you want to try to disable litespeed-cache?

April 10, 2025 at 5:13 am #16916488

Bruno Kos
WPML Supporter since 12/2018

Languages: English (English ) German (Deutsch ) French (Français )

Timezone: Europe/Zagreb (GMT+02:00)

Yes, please try disabling it.

Also, could you check if the performance issue persists under the following conditions?

- Only WPML plugins are activated — this will help determine if there's a conflict with another plugin.
- The theme is switched to a default WordPress theme like Twenty Twenty — this will help identify any conflict with your current theme.

If the issue still occurs after these checks, I’ll proceed by installing the Duplicator plugin to create a package for further debugging. I’ll make sure to exclude all media files to keep the package size minimal.

You can find more details about this process here:
https://wpml.org/faq/checklist-before-opening-a-ticket-in-wpml-support/#get-help-from-support

Please let me know if you're okay with this approach!

April 10, 2025 at 12:11 pm #16918377

Gerardo Bramati

I've disabled litespeed cache and nothing has changed.
Disabling other plugins doesn't change a thing.
Switch to default theme just speed up a little but website is still really slow.

Please go on with the Duplicator.

Thank you.

April 11, 2025 at 4:57 am #16920922

Bruno Kos
WPML Supporter since 12/2018

Languages: English (English ) German (Deutsch ) French (Français )

Timezone: Europe/Zagreb (GMT+02:00)

This has been escalated to our 2nd tier team team and may take some debugging time, I'll get back to you as soon as I have any news or questions for you.

April 14, 2025 at 5:26 am #16927203

Bruno Kos
WPML Supporter since 12/2018

Languages: English (English ) German (Deutsch ) French (Français )

Timezone: Europe/Zagreb (GMT+02:00)

We've been investigating the 503 errors you reported. At this time, our second-tier team has been unable to reproduce the issue—neither in their local environment nor directly on your site. Even when monitoring the site with debugging tools, no HTTP API calls are being blocked or showing abnormal behavior.

To proceed with more thorough testing and debugging, would it be possible for you to provide us with access to a staging environment where we can safely run extended tests and monitor logs without impacting your live site?

April 22, 2025 at 1:07 pm #16955366

Gerardo Bramati

We're setting up stage env for you. Best regards.

April 22, 2025 at 3:27 pm #16956285

Gerardo Bramati

Ok, I've just set up a new stage environment on hidden link. Credential are the same as per production env (same WPML user). Let us know. Thanks in advance.

April 23, 2025 at 7:30 am #16958149

Bruno Kos
WPML Supporter since 12/2018

Languages: English (English ) German (Deutsch ) French (Français )

Timezone: Europe/Zagreb (GMT+02:00)

It looks like Query Monitor is encountering a fatal error on the site — could you confirm if it’s currently functioning on your end?

In the meantime, I’ve been using this Chrome extension to monitor performance:
hidden link

I just tested reloading this URL:
hidden link
Previously, this was triggering a 503 error, but I’m not seeing that now — with or without WPML enabled.

To help us better understand the issue and assist our second-tier support team, could you possibly use a screen recording tool like Loom to show the problem in action? If you could narrate what’s happening, that would be extremely helpful for troubleshooting and replicating the behavior on our end.

April 24, 2025 at 8:32 am #16963193

Gerardo Bramati

Sorry... the hosting is the same, so main production site consumes all resources even if WPML is disabled on stage website it is really slow... We're working on moving stage website on another hosting and then come back to you.