Yes, that is what I was trying to explain.
I talked with our developers this morning and they were concerned, as the users table is outside in another table and potentially re-writing the query could cause performance penalties - as it is another request that will run.
I have provided to them the full error message that you provided and I hope that they can help.
I will keep you posted about their decision.
As I suspected, that information was not enough for our developers to diagnose the issue and to suggest a proper resolution.
As HyperDB modifies the query, it is hard to tell with such limited data, if there is a problem with our code, or something else is running not the appropriate time or filtering incorrectly.
They are asking if it will be possible to have a staging machine where the issue is reproduced - for testing, or if it is fine to test on that machine where you have already provided access?
They need full access - even best if SSH access is included.
Please let me know if you can provide a staging environment (I am enabling the private reply) or if you agree for us to use the current environment for tests.
Please do note that using the current environment for tests is a dangerous operation and may lead to corruption or loss of data..
Hello!
I wanted to share something that I got from our developers.
They think that they found the issue in your custom code that you have used for fragmenting the subsites in a separate prefix.
They suggest two changes:
- Ignoring the users table in your code
- Adding prefix for the database in our code.
So let me here provide you the exact changes that you can test.
Your code change in db-config.php:
From
And code change in our plugin code (might not be necessary):
Change from:
LEFT JOIN {$wpdb->users} u
to
LEFT JOIN {$wpdb->prefix}users u
I see 3 instances in the WPML Translation Management plugin in the files:
2 in \wpml-translation-management\classes\class-wpml-translation-job-factory.php
1 in \wpml-translation-management\inc\translation-jobs\jobs\wpml-string-translation-job.class.php
Please let me know how it goes.
Please remember to create backups before you do anything.
Hello,
I tested this now. When I submit the translation to the user, I don't see any db errors, but when I come to the "Translations" screen, I see following error (again, trying to read users table from wrong db ):
SELECT DISTINCT SUBSTRING_INDEX(ito.element_type, '_', 1) AS element_type_prefix, ito.element_type AS original_post_type
FROM mw_625_icl_translate_job j JOIN mw_625_icl_translation_status s
ON j.rid = s.rid JOIN mw_625_icl_translations t
ON s.translation_id = t.translation_id JOIN mw_625_icl_translate iclt
ON iclt.job_id = j.job_id JOIN mw_625_icl_translations ito
ON ito.element_id = iclt.field_data
AND ito.trid = t.trid JOIN (SELECT rid, MAX(job_id) job_id
FROM mw_625_icl_translate_job
GROUP BY rid ) jobmax
ON ( j.revision IS NULL
AND j.rid = jobmax.rid)
OR ( j.job_id = jobmax.job_id
AND j.translated = 1)
LEFT JOIN mw_625_posts p
ON t.element_id = p.ID
LEFT JOIN mw_625_users u
ON s.translator_id = u.ID
WHERE s.status > 0
AND s.status <> 9
AND (j.translator_id = 1
OR j.translator_id = 0
OR j.translator_id IS NULL )
AND s.translation_service='local'
AND ( (t.source_language_code = 'cs'
AND t.language_code IN ('en')) )
AND iclt.field_type = 'original_id'
I checked this. Yes you are correct - there is still error.
I did an adjustment, replaced "prefix" with "base_prefix" as this should be the multi-site variant for handling similar cases.
However, this still does not work, as your multisite setup is split in two databases and the users database is in the "yotix" database, but all other sites are in the "yotix_" database.
At this time, I can only suggest that you hardcode this wherever necessary.
changing the line
Hello,
thanks. I think I resolved this. Diving deeper into wpdb class, I found out that the users table can be easily overriden globally. I reverted the changes back to
{$wpdb->users}
and defined in wp-config.php
define('CUSTOM_USER_TABLE','yotlix.mw_users');
DB errors are gone, I can see the waiting translations in the dashboard. Any possible issues with this solution?
That is strange.
Do you have any custom functions that are hooking onto the user creation perhaps?
Yes - this would require a very serious debugging, and it could be coming from WordPress core itself.
