[Resolved] Incorrect structure for icl_strings table
This thread is resolved. Here is a description of the problem and solution.
Problem: The client encountered an issue with the 'There is a problem with the String Translation table in your site.' error message and discovered that the uc_domain_name_context_md5 index was missing from the icl_strings table. Additionally, there were many duplicate entries in the icl_strings table, which prevented the creation of the index. Solution: We resolved the issue on the staging site and requested access to the live site or a database dump to apply the fix. Our 2nd tier support team planned to log in to the dashboard, install a database admin plugin such as Adminer, patch the table, and ensure everything was functioning correctly. We emphasized the importance of not making changes during this process and the necessity of having a database backup.
If you're experiencing a similar issue, we recommend you ensure that you have a recent backup of your database before proceeding. If the solution provided here seems outdated or not applicable to your case, please check the related known issues, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. If the problem persists, we highly encourage you to 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.
While debugging the dreadful 'There is a problem with the String Translation table in your site.' message, I noticed that the uc_domain_name_context_md5 index is missing from the icl_strings table definition.
Trying to create this index fails because there are a lot of duplicate entries in the icl_strings table (ie. with the same _md5 value).
Would you have a pre-made query that would enable me to get rid of these duplicate entries without also deleting their translation? This site has been in operation for several years and I cannot lose any of the translations in the database.
Thanks for contacting WPML forums support. I'll be glad to help you today.
1) Please let me know if you have a staging site where we can debug the issue. If yes, I would need to request temporary access (WP-Admin and FTP)
Your answer will be private, meaning only you and I can access it.
❌ Please backup your database and website ❌
✙ I need your permission to deactivate and reactivate the plugins and themes and change site configurations. This is also why the backup is critical.
✙ I also need your permission to take a local copy of your site to debug the issue without affecting your live site.
2) Could you please share your Debug information with me?
You can read a detailed explanation about it here. (http://wpml.org/faq/provide-debug-information-faster-support)
The debug info will give me a lot of information about how your site is configured.
Thanks much, everything seems to be working after a 'wp cache flush': the message is no longer here, the table has the missing index in place, and all string translations are there.
Can you please tell me how to replicate this fix on the production site?
It's great to hear that the issue is fixed on the staging site. Please share the live site's access details or a database dump of your live site, so our 2nd tier support tier can patch it with the fix.
Our 2nd tier support team will log in to your dashboard, install a database admin plugin, like Adminer, patch the table, and check if everything works as it should.
It's not recommended to make changes while we work, and it's necessary to have a database backup.
I understand, but this would not be possible on our production environment for a number of reasons, including both technical ones (read-only code) and organizational (users working all the time on translations).
Since the development site was an exact replica of the production site, would it be possible for your second line support to list the queries/operations they did so I can replicate on the production site?
Note this was my original question. I am an experienced SQL database administrator and PHP developer, so will not have any issues understanding the steps needed to fix.
If this is the only option then we need to synchronize so this happens when the users are not working and entering new translations. The users are located in Canada.
I will send the backups tomorrow morning European time, and would need to receive the corrected tables by early afternoon in order to install these before the users start working.
Can you please synchronize this with the second level support? What time do you start working in GMT timezone?
