On this page
utf8mb4 is the MySQL and MariaDB character set that stores full Unicode, including emoji and four-byte characters. Older utf8 only handled three bytes per character, so many symbols failed or turned into question marks. New WordPress installs already expect utf8mb4, and you should use it for any site that needs real Unicode support.
Keep charset and collation consistent
Table charset, column charset, and the connection charset should all match. In wp-config.php, set DB_CHARSET to utf8mb4. Leave DB_COLLATE empty, or set it to one utf8mb4 collation you chose on purpose. Mixed collations often cause “illegal mix of collations” errors on JOINs that used to work. That usually appears after someone imports a table from a different dump.
Convert on a copy, not on live data
Always convert on a copy first. Dump the schema, restore it onto a throwaway database, and run the conversion there. Load a few posts and users, then cut over only after you are satisfied. Do not search-and-replace charset names inside a large SQL dump. That can rewrite the word “utf8” inside post content or break import comments. Change table and column metadata with ALTER, or with a conversion process you have already rehearsed.
Choose one collation and stick with it
Collation is not a theme setting. Options such as utf8mb4_unicode_ci and utf8mb4_unicode_520_ci sort and compare some characters differently. Pick one per schema and keep every table on it. Do not paper over JOIN errors with CAST in every query; fix the columns instead. phpMyAdmin shows table collation under Operations. If half your tables still use utf8_general_ci, that mix is the problem.
Back up first. A charset change rewrites metadata and, depending on the path, may rewrite data too. See back up and restore a database before you ALTER production.
Tagged
Was this article helpful?
Be the first to rate this article.



