I’m writing this blog post on my new server. The old one will be shut down in about two hours. As it had quite a few WordPress sites and one Matomo instance hosted, migrating everything was quite a task.
Migrating the sites I’ve followed my “5 minute migration process” and it went all smoothly as expected. Only when opening my blog after the DNS changes, the sidebar was missing the first two text widgets. What happened here?
Emojis ?
For quite a while, WordPress natively supports emojis. You can just use them in a blog post and WordPress will show them. In the past, they were replaced with an SVG sprite. But since modern operating systems and browsers support them natively, that’s not necessary anymore.
But why was using emojis and issue after the migration? On the old server, I’ve used MySQL 8 and on the new one MariaDB 10. When exporting the database, I’ve just run the wp db export
command as always. But after the import, the UTF-8 multibyte characters were broken. Instead of an emoji, I only got some ??
signs.
This most probably broke the unserialize()
function WordPress is using, and the whole widget was broken. This caused the first two text widgets not being shown, even though they were in the database.
Exporting the database with utf8mb4
After finding this issue and some research, I’ve found a WP-CLI issue about this effect. I was able to get a working export, adding a flag for the default charset:
$ wp db export --default-character-set=utf8mb4
Importing this new SQL dump fixed the issue, and the widgets appeared again. And I also got emojis in the content of my blog posts.
Conclusion: Always update WP-CLI!
So I successfully managed to repair the database, but still wanted to know why this (still) happened. The issue states, that this was fixed in the db-command, and release with version 2.5.0 of WP-CLI. Now on that server, I was still using version 2.4.0 of the WP-CLI which didn’t include the fix.
After updating to the current version (2.7.1), I didn’t need to add the flag anymore and the export had emojis and other utf8mb4 characters encoded correctly.
So before you do important maintenance tasks, better always update the WP-CLI to the latest version, so you don’t run into issue, you might not find right away. If I had recognized this issue only in some days/week, fixing/synching the database would have become really challenging.