WordPress 4.2.x moves to utf8mb4, breaks some workflows

  • Hi,
    I want to raise awareness about an issue that might crop up for others.

    Last week WordPress released 4.2 (and soon after 4.2.1), which among other things adds support for Emojis. To support that they switched tables to “utf8mb4_unicode_ci”, rather than “utf8”.

    A problem may arise if the server you sync with has an older version of MySQL. In my case for example, my home installation uses MySQL 5.6.15 while my host (OVH on shared hosting) uses 5.1.73. That version doesn’t support utf8mb4, it was introduced in 5.5.3.

    The symptom is strange. I’m using PUSH direction. Database sync plug-in creates the SQL dump correctly and sends it to the remote. The remote seems to accept it and returns HTTP 200 OK. Local install moves to “Database synced successfully” and all seems well. In fact, the remote hasn’t been updated at all.

    I haven’t fixed my workflow yet. I can’t even dump and sync manually since the same issue arise, local dump exports in utf8mb4 which can’t be imported on the remote.

    If anyone has suggestions I’d be happy to test. Currently testing exporting SQL data in compatibility mode MYSQL40.

    https://www.ads-software.com/plugins/database-sync/

Viewing 1 replies (of 1 total)

  • Hello, you’re absolutely correct. Here is the discussion on the same issue.
    https://make.www.ads-software.com/core/2015/04/02/the-utf8mb4-upgrade/
    No compatibility modes helped in my case. Though it do helps escaping errors while importing DB on a remote server, it tottaly breaks encoding instead.

    In fact it seems like a mistake-move from WP dev team (prove me wrong pls).

    If anyone have the solution pls share, I’ve surfed everywhere and can’t find any better solution than updating mysql version on a remote server, which is in fact not always possible.

Viewing 1 replies (of 1 total)
  • The topic ‘WordPress 4.2.x moves to utf8mb4, breaks some workflows’ is closed to new replies.