[wp-trac] [WordPress Trac] #32308: WP Multisite: Can't add new site.

WordPress Trac noreply at wordpress.org
Tue May 12 03:51:24 UTC 2015

#32308: WP Multisite: Can't add new site.
 Reporter:  thesun2012    |       Owner:  chriscct7
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Formatting    |     Version:  4.2.2
 Severity:  normal        |  Resolution:  duplicate
 Keywords:                |     Focuses:
Changes (by chriscct7):

 * keywords:  has-patch needs-testing needs-unit-tests =>
 * status:  accepted => closed
 * resolution:   => duplicate
 * milestone:  4.2.3 =>


 When you attempt to add a new site on the test install provided, the
 WordPress throws the following error when it attempts to add the tables
 for the new subsite: `WordPress database error COLLATION 'utf8_general_ci'
 is not valid for CHARACTER SET 'utf8mb4' for query CREATE TABLE`.

 On a blog this [https://mathiasbynens.be/notes/mysql-utf8mb4#comment-5
 guy] has the same error when his MySQL variables are set as follows:

 | Variable_name              | Value                |
 | `character_set_client`     | `utf8`               |
 | `character_set_connection` | `utf8mb4`            |
 | `character_set_database`   | `utf8mb4`            |
 | `character_set_filesystem` | `binary`             |
 | `character_set_results`    | `utf8`               |
 | `character_set_server`     | `utf8mb4`            |
 | `character_set_system`     | `utf8`               |
 | `collation_connection`     | `utf8mb4_unicode_ci` |
 | `collation_database`       | `utf8mb4_unicode_ci` |
 | `collation_server`         | `utf8mb4_unicode_ci` |

 I'm not convinced changing the two variables  character_set_client and
 character_set_results to UTF8 will actually solve the problem.

 I think this is actually a duplicate of #32212 which itself is a
 duplicate/caused by #32127.

 As this bug affects a significant number of people trying to add a site in
 an existing multisite instance, I think the solution is to raise the
 priority of #32127.

 This ticket also exposed 3 more issues with WordPress core:

 First, even after the error, WordPress continued to try to run, spewing
 thousands of errors as it tried to load permission and user objects from
 tables that didn't exist. When WordPress encounters a severe database
 error, one that cannot be recovered from, like the lack of insertion of
 the users table, WordPress should stop execution at that point, and in a
 nice display explain the error it ran into and offer the ability to click
 a button and retry, and if it doesn't work provide data that would be
 useful to the hosting support to manually fix this problem.

 Second, the function sanitize_option needs to handle WP Error Objects. The
 patch above does that.

 Third, the function sanitize_option desperately needs unit tests. This is
 one of the more critical functions in WordPress. Why unit tests in the
 past weren't made doesn't matter now, we just need to add them as soon as

 Will split each of these 3 off as own tickets (with link back), close this
 as duplicate of #32212, and raise priority of #32127

Ticket URL: <https://core.trac.wordpress.org/ticket/32308#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

More information about the wp-trac mailing list