[wp-trac] [WordPress Trac] #38186: Database Collations Bypassed by determine_charset() in wp-db.php

WordPress Trac noreply at wordpress.org
Thu Sep 29 14:26:57 UTC 2016


#38186: Database Collations Bypassed by determine_charset() in wp-db.php
--------------------------+-----------------------------
 Reporter:  natecf        |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Charset       |    Version:  4.6.1
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 The function 'determine_charset' in wp-db.php, since 4.6.0 will try to set
 the database collation to the best option available,
 'utf8mb4_unicode_520_ci'. This makes sense when the collation is not
 explicitly defined in wp-config.php, and most likely beneficial to novice
 developers.

 However, this assumptive behavior occurs even when the DB collation ''is''
 explicitly defined in wp-config, effectively ignoring 'utf8_general_ci',
 'utf8mb4_unicode_ci', and collations starting with 'utf8_' in certain
 environments.

 There appears to be no way to force these collations when defined by the
 developer. If the developer has set the collation in the config file,
 shouldn't the software obey the word of the developer?

 In short, ''a valid database collation set in wp-config should not be
 bypassed by WP Core.'' There is no workaround that vindicates the logic in
 determine_charset().

 A possible solution would involve determine_charset() checking for a
 config setting such as 'FORCE_DB_COLLATE'. If true, use the collation
 defined in wp-config without assuming otherwise.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/38186>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list