I reverted [37601] and the issue was not resolved - the site is still showing gibberish if the define('DB_CHARSET', 'utf8mb4') is not commented. Other than that the DB_COLLATE is indeed empty in the wp-config.php

Hi people,
I had this issue on a website, and the commenting of the DB_CHARSET didn't work, because some plugin stopped working. So I had a look at the database discovering that the issue was on the database (so I assume this depends on the utf8mb4 conversion script). Here is how to fix the database, but please test this on a staging environment, don't do that on a production website.

Then you have to edit this file in order to make a small correction, but if it's big the editing will require RAM or time:

nano dump-latin1.sql

Change

/*!40101 SET NAMES latin1 */;

to

/*!40101 SET NAMES utf8 */;

save by entering CTRL+X
enter Y

Now your dump is fixed and ready, so I suggest to restore it on another database name, in order to have a backup of the old one and possibly easly restore it, or at least to add a prefix to the existent tables.

The root cause of this problem in @danielkanchev's case was [37320], and PHP 5.3. While the site was on WordPress 4.5, it was using PHP 5.3, which doesn't support utf8mb4. Because DB_CHARSET was set to utf8mb4, wpdb::set_charset() was silently failing, and reverting back to the default server character set - latin1.

The upgrade to WordPress 4.6 included [37320], which sets the server side character set, but it assumes that the client side character set has been set correctly. This caused MySQL to be taking latin1 strings from the database, and converting them to utf8 before sending them to PHP. PHP was treating them as latin1, however, hence the ​mojibake.

I think we could reasonably check the result of the mysqli_set_charset() before running the SET NAMES query, as it's better to try and use the server default character sets for everything if part of the process fails.

Database: Don't force an unsupported character set that previously would've silently failed.

[37320] corrected some behaviour in how PHP and MySQL character sets are matched up. This was correct, but had the side effect of causing some incorrectly configured sites to start failing.

Prior to [37320], if DB_CHARSET was set to utf8mb4, but the PHP version didn't support utf8mb4, it would fall back to the default character set - usually latin1. After [37320], the SET NAMES query would force MySQL to treat the connection character set as utf8mb4, even if PHP wasn't able to understand it.

By checking if mysqli_set_charset() succeeded, we can simulate the old behaviour, while maintaining the fix in [37320].

Database: Don't force an unsupported character set that previously would've silently failed.

[37320] corrected some behaviour in how PHP and MySQL character sets are matched up. This was correct, but had the side effect of causing some incorrectly configured sites to start failing.

Prior to [37320], if DB_CHARSET was set to utf8mb4, but the PHP version didn't support utf8mb4, it would fall back to the default character set - usually latin1. After [37320], the SET NAMES query would force MySQL to treat the connection character set as utf8mb4, even if PHP wasn't able to understand it.

By checking if mysqli_set_charset() succeeded, we can simulate the old behaviour, while maintaining the fix in [37320].