[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