Background of the issue:
I am trying to report a critical performance issue on our site linked to WPML. Our server frequently crashes with a 503 error due to database-level locks. Today, while using your support feature to remove 'ghost entries,' the site immediately crashed. Link to a page where the issue can be seen: hidden link
Symptoms:
The site becomes unreachable and returns a 503 error. PHP processes hang while waiting for a response from the database, exceeding the maximum execution time and are force-killed by the web server. Logs show Lock wait timeout exceeded errors, indicating a slow query is locking a database table.
Questions:
What causes the 503 error linked to WPML operations?
How can we prevent database-level locks caused by WPML?
Dear Paola,
We followed the steps in your video. Unfortunately, after a few hours, the site still had a 503 error. I can attach the log file generated by WP_DEBUG.
================================
Fatal error: Uncaught TypeError: WPML\UserInterface\Web\Infrastructure\CompositionRoot\Config\Config::__construct(): Argument #4 ($page) must be of type WPML\UserInterface\Web\Infrastructure\CompositionRoot\Config\PageInterface, WPML\UserInterface\Web\Infrastructure\WordPress\CompositionRoot\Config\AdminPage given, called in /var/www/webroot/ROOT/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/wpml/wpml.php on line 41 and defined in /var/www/webroot/ROOT/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/wpml/src/UserInterface/Web/Infrastructure/CompositionRoot/Config/Config.php:53 Stack trace: #0 /var/www/webroot/ROOT/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/wpml/wpml.php(41): WPML\UserInterface\Web\Infrastructure\CompositionRoot\Config\Config->__construct() #1 /var/www/webroot/ROOT/wp-content/plugins/sitepress-multilingual-cms/sitepress.php(77): require_once('...') #2 /var/www/webroot/ROOT/wp-includes/class-wp-hook.php(324): {closure}() #3 /var/www/webroot/ROOT/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters() #4 /var/www/webroot/ROOT/wp-includes/plugin.php(517): WP_Hook->do_action() #5 /var/www/webroot/ROOT/wp-settings.php(578): do_action() #6 /var/www/webroot/ROOT/wp-config.php(128): require_once('...') #7 /var/www/webroot/ROOT/wp-load.php(50): require_once('...') #8 /var/www/webroot/ROOT/wp-blog-header.php(13): require_once('...') #9 /var/www/webroot/ROOT/index.php(17): require('...') #10 {main} thrown in /var/www/webroot/ROOT/wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/wpml/src/UserInterface/Web/Infrastructure/CompositionRoot/Config/Config.php on line 53
Notice: La funzione is_page è stata richiamata in maniera scorretta. I tag condizionali di una query non funzionano prima che la query sia stata eseguita. Prima dell'esecuzione restituiscono sempre il valore False. Leggi Debugging in WordPress per maggiori informazioni. (Questo messaggio è stato aggiunto nella versione 3.1.0.) in /var/www/webroot/ROOT/wp-includes/functions.php on line 6121
Notice: La funzione is_page è stata richiamata in maniera scorretta. I tag condizionali di una query non funzionano prima che la query sia stata eseguita. Prima dell'esecuzione restituiscono sempre il valore False. Leggi Debugging in WordPress per maggiori informazioni. (Questo messaggio è stato aggiunto nella versione 3.1.0.) in /var/www/webroot/ROOT/wp-includes/functions.php on line 6121
Notice: La funzione is_page è stata richiamata in maniera scorretta. I tag condizionali di una query non funzionano prima che la query sia stata eseguita. Prima dell'esecuzione restituiscono sempre il valore False. Leggi Debugging in WordPress per maggiori informazioni. (Questo messaggio è stato aggiunto nella versione 3.1.0.) in /var/www/webroot/ROOT/wp-includes/functions.php on line 6121
Notice: La funzione is_search è stata richiamata in maniera scorretta. I tag condizionali di una query non funzionano prima che la query sia stata eseguita. Prima dell'esecuzione restituiscono sempre il valore False. Leggi Debugging in WordPress per maggiori informazioni. (Questo messaggio è stato aggiunto nella versione 3.1.0.) in /var/www/webroot/ROOT/wp-includes/functions.php on line 6121
Si è verificato un errore critico sul tuo sito web.
================================
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Madrid (GMT+02:00)
Thank you very much for the details.
Before proceeding, please make sure to create a full backup of your site. Then follow these steps:
1. Deactivate the WPML Multilingual CMS plugin.
2. Delete the plugin completely.
3. Clear any OPcache or server cache.
4. Download a fresh copy of WPML from your account here: https://wpml.org/account/downloads/ (click “Download WPML manually”).
5. Install the new copy on your WordPress site.
After doing this, please let me know if the issue is resolved.
This is a follow-up regarding my ticket about the frequent 503 errors and server crashes.
We've had another crash last night, and after a detailed analysis of our server's access.log, we have successfully identified the specific cause. We wanted to share this important finding with you.
The Root Cause:
The crash, which included a 100% RAM spike, was triggered by a massive and simultaneous crawl from multiple search engine bots (Googlebot, Bingbot, SemrushBot, Bytespider, Amazonbot, etc.) at approximately 2:00 AM.
Crucially, these bots were not hitting simple pages. They were aggressively crawling our multilingual WooCommerce shop archives using complex, multi-parameter filtered URLs (e.g., ...?filter_color=...&filter_product_brand=...).
We believe this combination of:
Heavy database queries from WooCommerce filtering.
The added complexity of WPML's language layer on each query.
The high volume of simultaneous requests from many different bots.
...created a "perfect storm" that overwhelmed our database, caused it to lock up, and led to the cascade failure resulting in the 503 errors. The issue was not a wp-cron job, as one might expect at that time of night.
Solution We Have Implemented:
As an immediate and critical solution, we have used our SEO plugin (SEOPress PRO) to deploy a virtual robots.txt file that explicitly disallows all bots from crawling these problematic URLs. We have added the following rules:
User-agent: *
Disallow: /*?filter_
Disallow: /*&filter_
Disallow: /*?per_page
Disallow: /*&per_page
Disallow: /wp-json/
We believe this will prevent the issue from happening again by stopping bots from generating these server-killing queries.
Our Questions for You:
First, we wanted to share this finding, as it might be helpful for other users with complex, multilingual WooCommerce sites.
Based on your experience, do you have any other best-practice recommendations for handling bot traffic on filtered archives in a multilingual setup?
Are there any specific WPML settings related to query optimization, filtering, or URL parameters that we should review to help mitigate this kind of server load?
Thank you for your time and any further insights you can provide.
