Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • @miladnasri

    In my case I wasn’t upgrading. I was installing fresh WordPress 4.2.2. The installation routine added define(‘DB_CHARSET’, ‘utf8mb4’) to wp-config.php, however, the function init_charset() set wrong collation when trying to create above mentioned tables. This is a bug.

    @chriscct7

    I couldn’t find any info regarding serurity vulnerability due to setting BD_COLLATE. Could you give me some details?

    IMHO when you have a fresh installation and if the db has charset utf8mb4, collation utf8mb4_general_ci and you add the same values to wp-config.php, this cannot be any security vulnerability.

    The solution is surprisingly easy. It’s enough to set DB_COLLATE in the wp-config.php:

    define('DB_COLLATE', 'utf8mb4_general_ci'); // on condition that your DB_CHARSET is 'utf8mb4'

    That’s it!

    The bug is hidden in the file \wp-includes\wp-db.php on the line 731 in the function init_charset(). For multisite mode the ‘utf8_general_ci’ collation is used if DB_COLLATE is empty. And if your DB_CHARSET is ‘utf8mb4’ then the error occures.

    The actual error is raised when creating and consequently querying nonexistent tables for the new site (‘2’ changes with the number of sites):
    wp_2_terms
    wp_2_term_taxonomy
    wp_2_term_relationships
    wp_2_commentmeta
    wp_2_comments
    wp_2_links
    wp_2_options
    wp_2_postmeta
    wp_2_posts

Viewing 2 replies - 1 through 2 (of 2 total)