[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 =>
Comment:
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
possible.
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