Hi- we are facing an issue with wpml plugin. whenever we are updating any content in the backend, the site gets down. we have found some WPML queries creating issues. it is related to updating the options wpml_tp_com_log and wpml_notices.
Hi-We have updated the plugins on our staging site. Now we are getting fatal errors when we are editing any page/post. I checked the debug file and I found this error.
WordPress database error COLLATION 'utf8mb4_unicode_520_ci' is not valid for CHARACTER SET 'utf8mb 3' for query
CREATE TABLE IF NOT EXISTS `wp_3_icl_background_task` (
`task_id` BIGINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
`task_type` VARCHAR(500) NOT NULL,
`task_status` SMALLINT UNSIGNED NOT NULL DEFAULT 0,
`starting_date` DATETIME NULL,
`total_count` INT UNSIGNED NOT NULL DEFAULT 0,
`completed_count` INT UNSIGNED NOT NULL DEFAULT 0,
`completed_ids` TEXT NULL DEFAULT NULL,
`payload` TEXT NULL DEFAULT NULL,
`retry_count` SMALLINT UNSIGNED NOT NULL DEFAULT 0
) DEFAULT CHARACTER SET utf8 COLLATE utf8mb4_unicode_520_ci;
made by WPML\Upgrade\Commands\CreateBackgroundTaskTable::run
WordPress database error Table 'db.wp_3_icl_background_task' doesn't exist for query SELECT * FROM wp_3_icl_background_task WHERE task_status IN ('1','0','2') AND 1=1 made by WPML\Core\BackgroundTask\Repository\BackgroundTaskRepository::getAllByTaskStatus
The reason for this issue is that various database tables use a different collations.
To solve the issue a matching and similar collation for all DB tables.
You can run the following MySQL query to solve such an issue, but it will need to be adjusted with the matching table prefix and also in case a different collation is used than mentioned inside the query:
ALTER TABLE wp_posts CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;
Make sure you have a backup fo the database before doing the steps above.
Each time we open a page to edit this update query is running behind the scene causing a deadlock on the DB. How can we prevent that? (We are just opening the page in edit mode without making any updates)
UPDATE `wp_3_options` SET `option_value` = 'a:5:{s:26:\"taxonomy-term-help-notices\";a:2:{s:20:\"translation_priority\";O:11:\"WPML_Notice\":24:{s:30:\"\0WPML_Notice\0display_callbacks\";a:1:{i:0;a:2:{i:0;O:37:\"WPML_Taxonomy_Translation_Help_Notice\":2:{s:57:\"\0WPML_Taxonomy_Translation_Help_Notice\0wpml_admin_notices\";O:12:\"WPML_Notices\":6:{s:27:\"\0WPML_Notices\0notice_render\";O:18:\"WPML_Notice_Render\":3:{s:38:\"\0WPML_Notice_Render\0dismiss_html_added\";b:0;s:35:\"\0WPML_Notice_Render
Also, When we update any menu item on the website (menu has no connection with WPML), this query is running multiple times with different option_value. Any idea why?
UPDATE wp_3_options SET option_value = '1703214288.8785910606384277343750' WHERE option_name = '_transient_doing_cron'
The update query that you have mentioned needs to be checked by us. I wonder if we are allowed to copy the staging version of your website to our server?
If yes, please get back to us with the login information of the staging server by setting the next reply as private and we will follow up.
By the way the only report that I have found which was something similar to the update query you mentioned was this:
