If this solution does not resolve your issue, or if it seems outdated, we recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. Should you need further assistance, please open a new support ticket at 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.
Background of the issue:
Trying to re-open my ticket, as it has been closed when I was waiting for FTP and login details from my client.
I am trying to resolve an issue where my customer reported that they are unable to access translations in the backend. This issue occurs when accessing the Translation Management settings page, resulting in multiple 500 errors. Our table prefix is different from the standard 'wp_' prefix, but WPML seems to be looking for a table with the 'wp_' prefix. More details can be found here: https://wpml.org/forums/topic/translation-management-500-server-error-table-db_name-wp_icl_translations-doesnt-exist/. I can now provide FTP and login details for a staging version of the site.
Symptoms:
500 Server error - Table 'db_name.wp_icl_translations' doesn't exist. Console shows multiple 500 errors when accessing the Translation Management settings page.
Questions:
Is there any known issue with WPML regarding custom table prefixes?
Is there a quick fix for the behavior where WPML looks for a table with the 'wp_' prefix?
I need to request temporary access (wp-admin and FTP) to your site—preferably to a test site where the problem has been replicated if possible—in order to be of better help. When you log in to leave your next reply, you will find the needed fields below the comment area. The information you will enter is private, meaning only you and I can see and access it.
2. You also need to go to /wp-content/plugins/sitepress-multilingual-cms/vendor/wpml/wpml/src/Infrastructure/WordPress/Component/Item/Application/Query/SearchQuery/QueryBuilder/ManyLanguagesStrategy and open the file SearchPopulatedTypesQueryBuilder.php
3. Look for:
LEFT JOIN wp_icl_translations target_t
ON target_t.trid = source_t.trid
AND target_t.language_code IN ({$gluedEscapedLanguageCodes})
LEFT JOIN wp_icl_translation_status target_ts
ON target_ts.translation_id = target_t.translation_id
4. And change to:
LEFT JOIN {$this->queryPrepare->prefix()}icl_translations target_t
ON target_t.trid = source_t.trid
AND target_t.language_code IN ({$gluedEscapedLanguageCodes})
LEFT JOIN {$this->queryPrepare->prefix()}icl_translation_status target_ts
ON target_ts.translation_id = target_t.translation_id
Thanks, Andrey, that actually did the trick. This case is closed.
So we haven't messed anything up, it's just that ‘too many’ languages trigger different code from your plugin, and there were calls for database tables with hard-coded table prefixes in your code? I assume you're fixing this for the next release?
Yes, you are right. I have already reported this to our development team, and they will definitely fix it. Thank you for bringing this to our attention. Have a nice weekend ahead.
