#32308 closed defect (bug) (duplicate)
WP Multisite: Can't add new site.
Reported by: | thesun2012 | Owned by: | chriscct7 |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.2.2 |
Component: | Formatting | Keywords: | |
Focuses: | Cc: |
Description (last modified by )
I'm not sure if this is core's bugs, and sorry if I post in wrong place. I tried to install WPMS on hostgator, everything is ok except creating new site in wp-admin/network/sites.php.
Here is errors (the screen is dead at this page)
Warning: preg_match() expects parameter 2 to be string, object given in /home1/xxx/public_html/wp-includes/formatting.php on line 3435 Warning: preg_match() expects parameter 2 to be string, object given in /home1/xxx/public_html/wp-includes/formatting.php on line 3424 Warning: preg_match() expects parameter 2 to be string, object given in /home1/xxx/public_html/wp-includes/formatting.php on line 3435 Warning: strip_tags() expects parameter 1 to be string, object given in /home1/xxx/public_html/wp-includes/formatting.php on line 3407 Warning: strip_tags() expects parameter 1 to be string, object given in /home1/xxx/public_html/wp-includes/formatting.php on line 3407 Catchable fatal error: Object of class WP_Error could not be converted to string in /home1/xxx/public_html/wp-includes/kses.php on line 1038
I did the same installation in my localhost, it worked but not on my hosting.
I'm confusion and really don't know where is problem, is it in my hosting or in WP core.
I tried to contact my hosting's service support, they couldn't solve the problem, like me, they don't know how to solve it.
I also open a thread here, looks like this is a bug
https://wordpress.org/support/topic/can-not-add-new-site-wpmu?replies=8
Attachments (2)
Change History (42)
#1
@
10 years ago
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
#2
@
10 years ago
- Component changed from General to Formatting
- Description modified (diff)
- Milestone set to 4.2.3
- Resolution invalid deleted
- Status changed from closed to reopened
Looks like wpdb::strip_invalid_text_for_column()
returns a WP_Error object when siteurl
and home
options are sanitized: tags/4.2.2/src/wp-includes/formatting.php#L3422.
We need to check the returned value and handle accordingly.
#4
@
10 years ago
- Keywords needs-patch added
This would also appear to affect permalink_structure, category_base, tag_base, moderation_keys, blacklist_keys, blogdescription, blogname, date_format, time_format, mailserver_url, mailserver_login, mailserver_pass, and upload_path as well because of the way they use wpdb::strip_invalid_text_for_column()
I don't see how this is limited to MS only though. Theoretically the same sanitization is also used for single site isn't it?
#5
@
10 years ago
- Focuses multisite removed
- Keywords has-patch needs-testing 2nd-opinion added; needs-patch removed
- Owner set to chriscct7
- Status changed from reopened to accepted
That should do it. Handles a WP_Error object being returned, throwing a settings error and restoring the option back to the original value. Needs to be looked over by someone.
#6
@
10 years ago
- Keywords needs-unit-tests added; 2nd-opinion removed
I'm cool with this.
Could you please add some unit tests for it, as well?
#7
@
10 years ago
- Description modified (diff)
- Summary changed from WPMU: Can't add new site. to WP Multisite: Can't add new site.
#8
@
10 years ago
Yep definitely. Looks like we're gonna need to write unit tests for that whole function.
#9
@
10 years ago
Thinking about it some more, I don't think this is the correct fix for this bug.
The problem is that sanitize_option()
is calling $wpdb->strip_invalid_text_for_column()
, with $wpdb->options
as the table name. WP_Error
is being returned because the table can't be found.
So, why is it that $wpdb->options
can't be found? Is it set to the incorrect value, or can the table not be accessed?
The options are being inserted when install_blog()
calls populate_options()
, but the call in install_blog()
happens after the switch_to_blog()
in wpmu_create_blog()
, so $wpdb->options
should have the correct table name.
We need to be able to reproduce this bug to learn more.
#10
@
10 years ago
@pento so do you want to split off the sanitize_option enhancements then to a new ticket and link back to this one and then have this one just solve the underlying issue or do you want to keep both on this ticket?
#11
@
10 years ago
We can leave it here for the moment. We'll probably need to strip back the sanitize_option()
enhancements, anyway - if wp_options
can't be found, we're probably going to struggle to find the old version of the option to return. :)
#12
@
10 years ago
looks like the bug is utf8mb4, WP can't create new table for new site.
here is error logs in wp-admin/network:
[11-May-2015 01:36:16 UTC] WordPress database error COLLATION 'utf8_general_ci' is not valid for CHARACTER SET 'utf8mb4' for query CREATE TABLE wp_19_terms
#13
@
10 years ago
Well the bug isn't utf8mb4, it's that the collation isn't valid for the table that's being inserted or edited so the table either isn't inserted or there's a whitescreen (from a PHP fatal error) respectively when the database rejects. All of the confirmed cases, to our knowledge, are on EIG, specifically hostgator or bluehost, so its possibly a malfunctioning EIG server that coupled with the lack of error handling for the sanitize_option function as aftormentined, causing this, rather than simply being a core bug.
I think I'm getting close though, thanks to @thesun2012 for giving us access to a test install where we can replicate this.
#14
@
10 years ago
Chris,
So is the problem in Hostgator's server? I will report this to their staff for fixing.
Hope they can fix it, I believe another users may face this problem too.
Thank you a lot for your times.
#15
@
10 years ago
No, the more I look at it the more I think this is actually just #32127 in a different form. Still looking at this.
#16
@
10 years ago
- Keywords has-patch needs-testing needs-unit-tests removed
- Milestone 4.2.3 deleted
- Resolution set to duplicate
- Status changed from accepted to closed
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 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
#18
@
10 years ago
I had this with Hostwinds (www.hostwinds.com).
Would it help if I were to give you access to a Multisite install on my Hostwinds VPS?
#19
@
10 years ago
@horrorUK see comment:16
#20
follow-up:
↓ 21
@
10 years ago
@chriscct, thank you for the patch, however, it's returning another error (both on a fresh WP MS install and an upgrade of fresh install 4.2 to 4.2.2).
Fatal error: Call to a member function get_error_message() on a non-object in wp-includes/formatting.php on line 3457
There's an issue with that message on a clean 4.2 WP MS install, as well.
If anyone has any suggestions of any WP versions that is solid enough to allow me to have a "bug free" (haha!) WP MS installation, pass that along please.
Thanks!
#21
in reply to:
↑ 20
;
follow-up:
↓ 22
@
10 years ago
Replying to BearlyDoug:
@chriscct, thank you for the patch, however, it's returning another error (both on a fresh WP MS install and an upgrade of fresh install 4.2 to 4.2.2).
Fatal error: Call to a member function get_error_message() on a non-object in wp-includes/formatting.php on line 3457
There's an issue with that message on a clean 4.2 WP MS install, as well.
If anyone has any suggestions of any WP versions that is solid enough to allow me to have a "bug free" (haha!) WP MS installation, pass that along please.
Thanks!
The patch attached to this ticket does not fix the ability to add a new site in an multisite instance. That's a seperate, open ticket. And the patch on this ticket isn't up for merging, work on that has moved to a separate ticket
#22
in reply to:
↑ 21
;
follow-up:
↓ 23
@
10 years ago
Replying to chriscct7:
The patch attached to this ticket does not fix the ability to add a new site in an multisite instance. That's a seperate, open ticket. And the patch on this ticket isn't up for merging, work on that has moved to a separate ticket
My apologies, Chris. The GREAT news, through your documentation in reply 16 (Ticket #32127), the third patch there fixed my issue.
I truly appreciate the work/research you've done, your fixes for my first issue and the reference to the second issue.
#23
in reply to:
↑ 22
@
10 years ago
Replying to BearlyDoug:
Replying to chriscct7:
The patch attached to this ticket does not fix the ability to add a new site in an multisite instance. That's a seperate, open ticket. And the patch on this ticket isn't up for merging, work on that has moved to a separate ticket
My apologies, Chris. The GREAT news, through your documentation in reply 16 (Ticket #32127), the third patch there fixed my issue.
I truly appreciate the work/research you've done, your fixes for my first issue and the reference to the second issue.
Not a problem :)
#24
follow-up:
↓ 25
@
10 years ago
- Keywords needs-patch added
- Resolution duplicate deleted
- Status changed from closed to reopened
WP Multisite: Can't add a new site. Trying to add a sub-site on a sub-domain! It comes up with credentials' email, but the folder remains empty. I.e. - reports the creation of the site (installation), but does nothing. As far as I can see there are NO errors reported on the cPanel error log. Attempts to go to the dashboard of the new site fail - "file not found - wp-admin". The sub-domain folder remains empty!!! Same WP version 4.2.2. I'm quite sure this is a WP bug!
#25
in reply to:
↑ 24
@
10 years ago
Replying to skindfs:
WP Multisite: Can't add a new site. Trying to add a sub-site on a sub-domain! It comes up with credentials' email, but the folder remains empty. I.e. - reports the creation of the site (installation), but does nothing. As far as I can see there are NO errors reported on the cPanel error log. Attempts to go to the dashboard of the new site fail - "file not found - wp-admin". The sub-domain folder remains empty!!! Same WP version 4.2.2. I'm quite sure this is a WP bug!
skindfs, do the patch in this thread (32308.1.patch) and then the patch in #32127 (32127.3.diff to be specific). Since you're on Wordpress 4.2.2, you'll need to manually patch wp-admin/includes/upgrade.php. Both of these patches, combined, fixed my issue. Delete any of the new subdomains you added before doing the patches, patch it, then add the subdomains in again.
If you get into a pinch, hit me up on Twitter (preferred) or Facebook (my profile here has the links) and I'll just shoot you the three affected/patched files that'll fix your issue.
#26
follow-up:
↓ 27
@
10 years ago
I had the same errors yesterday. The solution is very easy. Always define DB_COLLATE in wp-config.php, that would correspond with DB_CHARSET. Do not leave it empty.
My working setttings are:
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_general_ci');
Before, when DB_COLLATE was empty and DB_CHARSET was uft8mb4 (set automatically by installation routine), I received the above mentioned error messages. It is caused by not being able to create new tables for the new site (site nr. 2 in this case):
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
And than the consequent SELECTs cannot get the desired values.
Problems are caused by function init_charset() in wp-db.php, line 725. I think the order of checking and setting charset and collate is not very logical. It should be refactored.
#27
in reply to:
↑ 26
@
10 years ago
Replying to tvape:
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_general_ci');
What is mb4? I have this:
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', );
Tried your fix but its not working - same result...
This ticket was mentioned in Slack in #core by helen. View the logs.
9 years ago
#31
@
9 years ago
tested on bluehost.com, instead of getting that error on hostgator. this issue on bluehost when add a new site. it just becomes a blank page and doesn't do anything.
#32
@
9 years ago
I have 1dollar-webhosting.com - put a ticket for them on 5/25/2015. The ticket is on hold! Just placed another request for expediting it. Despite Doug's terrific help I'm at point zero (nada)! The hosting company above is contacted in order to rule it out from the equation! This issue may be due to the specifics of the hosting co! Thank you everybody for the help! Looking forward to getting more help! -Paul
#33
@
9 years ago
For @skindfs' issue, I need to note that the bugs initially identified as part of this thread are resolved... the issue is specific to running Wordpress MultiSite on a cPanel system (shared hosting, which is never really a good idea, since you need to be able to control DNS and Apache configs).
#34
@
9 years ago
Ok! but I had it work with shared hosting when i was using Multi Site on 4.2 and 4.2.1
anyways, i fixed it!
#37
@
9 years ago
- Resolution set to duplicate
- Status changed from reopened to closed
Duplicate of #32127.
This ticket was properly closed at https://core.trac.wordpress.org/ticket/32308#comment:16
If you need help with version 4.2.2, please visit https://wordpress.org/support/forum/multisite
Do not reopen this ticket.
You'll unfortunately need to take this up with your host or support on WordPress.org at https://wordpress.org/support/