[wp-trac] [WordPress Trac] #37689: Issues with utf8mb4 collation and the 4.6 update

[WordPress Trac]

#37689: Issues with utf8mb4 collation and the 4.6 update
--------------------------+--------------------------
 Reporter:  Hristo Sg     |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  4.6.1
Component:  Database      |     Version:  4.6
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+--------------------------
Changes (by pento):

 * milestone:  Awaiting Review => 4.6.1


Comment:

 Thank you @danielkanchev for the use of your server. :-)

 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
 [https://simple.wikipedia.org/wiki/Mojibake 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37689#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform