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.


This topic contains 4 replies, has 2 voices.

Last updated by emilM-2 1 year ago.

Assigned support staff: Bigul.

Author Posts
May 27, 2019 at 11:42 am #3896563


I'm a developer doing a custom theme for a client.

Everything was great during development, yet with the client's content there seem to be serious performance issues.

The following query takes 170 seconds to complete (there are about 160 terms in 2 languages):

tra.term_taxonomy_id AS translated_id,
IFNULL(corr.term_id, 0) AS correct_parent
wp_term_taxonomy org
JOIN wp_icl_translations iclo ON
org.term_taxonomy_id = iclo.element_id AND iclo.element_type = CONCAT('tax_', org.taxonomy)
JOIN wp_icl_translations iclt ON
iclt.trid = iclo.trid AND iclt.language_code != iclo.language_code
JOIN wp_term_taxonomy tra ON
tra.term_taxonomy_id = iclt.element_id
LEFT JOIN wp_term_taxonomy parents ON
parents.term_id = org.parent
LEFT JOIN wp_icl_translations parent_lang ON
parents.term_taxonomy_id = parent_lang.element_id AND parent_lang.element_type = CONCAT('tax_', parents.taxonomy)
LEFT JOIN wp_icl_translations iclc ON
iclc.language_code = iclt.language_code AND parent_lang.trid = iclc.trid
LEFT JOIN wp_term_taxonomy corr ON
corr.term_taxonomy_id = iclc.element_id
org.taxonomy IN('custom_taxonomy_name') AND IFNULL(corr.term_id, 0) != tra.parent AND iclo.language_code = 'en'

This gets executed when I try to update a custom post type entry and assign a new term to it. Unfortunately PHP's max execution time maxes out and the server returns a 5XX error.

I'm not even sure what this query tries to accomplish but it not allowing my clients to use their site with the content they have on a live environment.

May 27, 2019 at 6:07 pm #3900161


Languages: English (English )

Timezone: Asia/Kolkata (GMT+05:30)


Welcome to the WPML support forum. I will do my best to help you to resolve these issues. Please let me know the following details to track the issue.

a) Which type of hosting service you are using now, shared or VPS or Dedicated?

b) Are you using a child theme or a custom theme? Please share more details about your theme.

c) Please share with me the WordPress debug.log (not WPML debug information). Please check this page for instructions

To enable it, open your wp-config.php file and look for define(‘WP_DEBUG’, false);. Change it to:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );
// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );
// Disable display of errors and warnings 
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', true );

In this case, the errors will be saved to a debug.log log file inside the */wp-content/* directory. Please do the steps to reproduce the bug and check you are getting any errors or warning related to WPML in the log file.

If you can paste your debug.log to and provide me that link it would be great! (This is the cleanest way because sometimes the logs are long and create a complete mess of discussion).



May 28, 2019 at 6:17 am #3902983


Hello Bigul,

To your questions:

a) The issue occurs both on my local development computer as well as on a shared hosting by SiteGround (StartUp plan).

b) I'm using a custom theme. I am a developer who has developed this theme following custom designs by my client. There isn't a lot of back-end functionality in the theme. We're using the hidden link framework for the CMS.

c) Here's the part of the debug log (this is from the live server; not my local dev environment set-up) with the fatal errors:

Overall the main issue is the query from my first message. It's present twice in the debug log (for 2 separate taxonomies). Trying each query through phpMyAdmin (outside of WordPress) they take 170 seconds and 40 seconds to execute (each).


May 29, 2019 at 7:05 am #3912233


I've used the plugin to transfer all content and settings (leaving out the uploads) to your server.

Due to that the login credentials have changed. I've updated the password to still be the one mentioned in your message, yet the username is now


One step to reproduce the issue would be to try and edit the entry with a custom post type of "Project" with an ID of 3312.

Then try and assign the "Civic & Cultural" term from the "Type" custom taxonomy to it.

After you hit update the site stalls. Refreshing the page does appear to have the term applied on your server but it does not always do so on the client's live server plus it's frustrating having that kind of experience.

There's also a huge load on the server from processes running MySQL tasks.

If we disable WPML then there are no issues at all. We've tried disabling any other plugin but they do not have any affect.

May 29, 2019 at 12:59 pm #3915709


Doing further checks we've found out that the issue was content related.

Even though disabling WPML solved some of the problems we've noticed there are others as well, which are present even with no active plugins at all and switching to the TwentyNineteen default theme.

It had to do with corrupt database with duplicate IDs (despite those were Primary Key).

We've manually edited the DB and the site works as expected now.