trying to update the site goes to timeout due to long execution

This thread is resolved. Here is a description of the problem and solution.

Problem:
The client was experiencing timeouts when trying to save products on their website. After disabling plugins one by one, they identified that WPML was causing the issue.

Solution:
First, we recommended disabling Cloudflare temporarily and enabling PHP error logging to share the error logs. We provided resources on how to enable error logs:

After analyzing the logs, we found database errors related to W3 Total Cache plugin interfering with database queries. We suggested disabling W3 Total Cache temporarily, clearing the DB cache, and adding "WP_ADMIN" in the "Reject constants" to prevent caching of admin requests.

Additionally, our second tier support identified a small database corruption. The client needed to remove the postmeta value with the key name "_icl_lang_duplicate_of" where the meta value was the post ID causing the issue. The SQL query provided was:

DELETE FROM `wp_postmeta` WHERE `meta_key` = '_icl_lang_duplicate_of' AND `meta_value` = '22037';

It was important to adjust the table prefix to match the client's site database prefix and to make a database backup before executing the query.

We also provided information on the tools and techniques used for debugging, including the use of a local server stack, Xdebug, and an IDE for step debugging.

If the solution provided here is not relevant due to being outdated or not applicable to your case, we highly recommend checking related known issues at WPML Known Issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If you still need assistance, please open a new support ticket in the 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.

Tagged: Bug, Compatibility

This topic contains 33 replies, has 3 voices.

Last updated by George Botsev 9 months, 2 weeks ago.

Assisted by: Waqas Bin Hasan.

Author	Posts
March 28, 2024 at 9:47 am #15459629
germaneK	I can not make duplicator package because lack of server resources 🙁
March 28, 2024 at 4:28 pm #15461710
Waqas Bin Hasan Supporter Languages: English (English ) Timezone: Asia/Karachi (GMT+05:00)	Thank you for the updates. Meanwhile our team suggests to disable Cloudflare for a while and enable PHP error logging then share the error logs. See following resources about enabling error logs: - https://wpml.org/documentation/support/debugging-wpml/ - hidden link - hidden link
March 29, 2024 at 7:14 am #15463205
germaneK	Hello, allow me to upload file, I can't attach txt files. Thanks.
March 29, 2024 at 7:17 pm #15465626
Waqas Bin Hasan Supporter Languages: English (English ) Timezone: Asia/Karachi (GMT+05:00)	You can upload the file to any external service like Google Drive, Dropbox, PasteBin or WeTransfer and then share the link accordingly.
March 30, 2024 at 6:38 pm #15466724
germaneK	Hello, I've uploaded both communication log and debug. You can view both on link i've provided before
April 1, 2024 at 4:24 pm #15470172
Waqas Bin Hasan Supporter Languages: English (English ) Timezone: Asia/Karachi (GMT+05:00)	Thank you for the logs, I've shared that link with our 2nd tier team for a review and 'll get back to you as soon as I've more information.
April 2, 2024 at 6:58 am #15471141
germaneK	Thanks! Looking forward to hearing from you.
April 2, 2024 at 3:32 pm #15473950
Waqas Bin Hasan Supporter Languages: English (English ) Timezone: Asia/Karachi (GMT+05:00)	Thank you for your patience and cooperation. Our team analyzed the logs and found following error repeating several times: WordPress database error Commands out of sync; you can't run this command now for query SELECT autoload FROM nm_options WHERE option_name = '_transient_wc_layered_nav_counts_pa_zoma' made by shutdown_action_hook, do_action('shutdown'), WP_Hook->do_action, WP_Hook->apply_filters, WC_Cache_Helper::delete_transients_on_shutdown, delete_transient, delete_option, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection->query, W3TC\DbCache_WpdbNew->default_query WordPress database error Commands out of sync; you can't run this command now for query UPDATE nm_term_taxonomy SET count = 0 WHERE term_taxonomy_id = 3 made by shutdown_action_hook, do_action('shutdown'), WP_Hook->do_action, WP_Hook->apply_filters, WPML_Post_Translation->shutdown_action, wp_defer_term_counting, wp_update_term_count, wp_update_term_count_now, _update_post_term_count, W3TC\DbCache_WpdbNew->update, W3TC\DbCache_WpdbInjection->update, W3TC\DbCache_WpdbNew->default_update, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection->query, W3TC\DbCache_WpdbNew->default_query` [29-Mar-2024 07:50:38 UTC] WordPress database error Commands out of sync; you can't run this command now for query SELECT term_id, taxonomy FROM nm_term_taxonomy WHERE term_taxonomy_id IN (3) made by shutdown_action_hook, do_action('shutdown'), WP_Hook->do_action, WP_Hook->apply_filters, WPML_Post_Translation->shutdown_action, wp_defer_term_counting, wp_update_term_count, wp_update_term_count_now, clean_term_cache, W3TC\DbCache_WpdbNew->query, W3TC\DbCache_WpdbInjection->query, W3TC\DbCache_WpdbNew->default_query All of them have one thing common "W3TC\DbCache_WpdbInjection->query", W3 Total cache seems to messing up with the query. They suggest to disable it for a while and then check. If this helps then clear the DB cache and add "WP_ADMIN" in "Reject constants:" to prevent W3TC to cache admin requests. Please take your time and let me know your findings.
April 3, 2024 at 9:36 am #15477078
germaneK	Hello, Thanks for a Troubleshooting. What should I disable? w3 TOTAL Cache is already disabled on the site, and this query, what you mentioned, should not run, I think. Have you tried with all plugin disabled except WPML or what?
April 3, 2024 at 9:54 am #15477224
germaneK	I fully delete w3 total cache plugin, but the issue still remains.
April 3, 2024 at 3:47 pm #15479487
Waqas Bin Hasan Supporter Languages: English (English ) Timezone: Asia/Karachi (GMT+05:00)	Thank you for the updates. Yes we checked in the CW site with every possible scenario. However I've asked for more information from the team. They may also need to check again in your site. I'll update you as soon as I hear back.
April 3, 2024 at 7:48 pm #15480335
Waqas Bin Hasan Supporter Languages: English (English ) Timezone: Asia/Karachi (GMT+05:00)	Team check again and W3TC seems to be enabled - see attached. I also see a lot of outdated plugins in your site, including the W3TC. We advise to try/improve/fix the following and check again: IMPORTANT: Take full backup of your website and database beforehand. - Disable W3TC as prescribed earlier (https://wpml.org/forums/topic/trying-to-update-the-site-goes-to-timeout-due-to-long-execution/page/2/#post-15473950). - Update all plugins to the latest versions. - Update WordPress to the latest version.
April 4, 2024 at 8:15 am #15481455
germaneK	Thank you for providing the updates. I would like to inform you that I have re-enabled the w3 cache after previously disabling it without seeing any improvements. Furthermore, I have updated both WordPress and the plugins to their latest versions. Even after testing without the w3 total cache plugin, I still encountered the same issue with product IDs 22161 and 21979. It seems that WPML is the underlying cause of the problem. I suggest conducting tests on a development site or instructing your team to do so. Is it possible that disabling w3 total cache on your end could resolve the issue? Please provide details on the location of your development site so that I can verify if w3 total cache is indeed the primary concern. Alternatively, you can investigate the live website to determine if WPML is the root cause by disabling the plugin and resaving the products. I look forward to hearing from you soon.
April 4, 2024 at 5:45 pm
April 5, 2024 at 9:28 am #15487110
germaneK	Hello, I am requesting access to the database or activation of the plugin that has been uploaded to the demo website PRIME MOVER. I am interested in migrating the main site here for thorough debugging purposes. It would be preferable if we could avoid using third-party plugins for the migration. In the event that my request is denied, debugging can be conducted on the main website (a full backup will be made) as the issue lies with WPML there and not here. It is important to address this issue proactively. Disabling WPML shows that the main website is functioning correctly, unlike here. Thank you for your attention to this matter.