Background of the issue:
I am using WPML 4.8 with String Translation in a WordPress Multisite hosted on SiteGround. Several subsites, such as Damascus, As-Suwayda, and Tartus, are experiencing 502 errors. The php_errorlog files have grown significantly due to repeated entries like WPMLUtilitiesLock->create. SiteGround confirmed that the main multisite database exceeded 1 GB, causing temporary blocking of INSERT/UPDATE queries. They have lifted this restriction until Nov 3, 2025. The largest tables are WPML related, such as wpn7_4_icl_translate at 72 MB. I have run all cleanup and repair tools under WPML → Support → Troubleshooting, enabled string auto-registration, cleaned and optimized string tables, and recreated ST tables where available, but the 'Database is limited' warning persists and lock errors continue.
Symptoms:
502 errors on multisite subsites, large php_errorlog files with repeated WPMLUtilitiesLock->create entries, and 'Database is limited' warnings.
Questions:
Confirm which specific WPML tables should exist per subsite (prefix wpn7_x_) so we can check for missing ones?
Advise how to rebuild the String-Translation tables safely in a multisite without reinstalling the entire WPML suite?
Clarify if the WPML Lock errors are related to the corrupted translation tables and how to stop the loop.
Thank you for your reply and for the optimization guide.
We’ve already completed the steps described there across all subsites (see tables wpn7_13_icl_*, wpn7_15_icl_*, wpn7_16_icl_*, etc.), including:
Deleted obsolete strings and orphaned translations.
Optimized all WPML tables with OPTIMIZE TABLE.
Cleared caches and ran the Troubleshooting actions from WPML → Support → Troubleshooting.
After cleanup, admin performance improved and error logs stopped flooding.
However, we’re still monitoring for a recurring lock pattern from:
WPML\Utilities\Lock->create
If that loop starts again or if you recommend an additional integrity check (beyond what’s in the optimization doc), please let us know which specific action or query you’d like us to run.
Please keep and eye on it and if the issue persists or comes back the next step would be for our team to take a copy of the site and database and further investigate.
Typically these steps tend to do the trick and very rarely the above is required.
The warning “We have detected a problem with some tables in the database. Database is limited.” still appears on the Tartus sub-site, even after running all troubleshooting actions (clear cache, remove ghost entries, fix element_type collation, repair WPML tables, set language information).
Could you please proceed with taking a copy of the site and database for further inspection as you mentioned earlier?
I would like to request temporary access (wp-admin and FTP) to your site to test the issue.
(preferably to a test site where the problem has been replicated if possible)
**Before we proceed It is necessary to take FULL BACKUP of your database and your website. Providing us with access, you agree that a backup has been taken **
I often use the Duplicator plugin for this purpose: http://wordpress.org/plugins/duplicator/
You will find the needed fields for this below the comment area when you log in to leave your next reply.
The information you enter is private which means only you and I have access to it.
NOTE: If access to the live site is not possible and the staging site does not exist please provide me with a duplicator package created with the duplicator plugin.
Thanks for the update! The notice hasn’t returned on our end either.
I’ve now installed phpMyAdminer on the Tartus sub-site so you can proceed with the next inspection.
Please confirm once you’ve finished so we can deactivate the plugin afterward for security reasons.
I am not able to see it at the moment, however, if you are comfortable taking a look at the database, what I need is a screenshot of all the _icl_ tables.
This will allow me to review and ensure they are all present.
