No, its not resolved in WordPress core. It’s marked resolved because it’s being tracked on Trac. A point release will come out at some point whenever we resolve the underlying issue completely in WordPress core
I am also having this same situation. I do believe it is a wordpress update that happened in the last 4 weeks. Here is what is happening when I try:
Warning: preg_match() expects parameter 2 to be string, object given in /home/vigilant/public_html/231graphics.info/wp-includes/formatting.php on line 3435
Warning: preg_match() expects parameter 2 to be string, object given in /home/vigilant/public_html/231graphics.info/wp-includes/formatting.php on line 3424
Warning: preg_match() expects parameter 2 to be string, object given in /home/vigilant/public_html/231graphics.info/wp-includes/formatting.php on line 3435
Warning: strip_tags() expects parameter 1 to be string, object given in /home/vigilant/public_html/231graphics.info/wp-includes/formatting.php on line 3407
Warning: strip_tags() expects parameter 1 to be string, object given in /home/vigilant/public_html/231graphics.info/wp-includes/formatting.php on line 3407
Catchable fatal error: Object of class WP_Error could not be converted to string in /home/vigilant/public_html/231graphics.info/wp-includes/kses.php on line 1038
I managed to fix this on my installation by upgrading PHP to 5.5.x from 5.4.x. Tried a load of other stuff first to do with WordPress versions etc but the PHP upgrade sorted it for me.
Very interesting. I tried doing new multisites on two separate servers which are both running php 5.4.(x) – I have that problem. I am going to see if I can get either hosting company to upgrade it for me. I’ll update if anything changes.
Thread Starter
John
(@thesun2012)
Hi you, this problem is core bugs and we are discussing here.
Also I solved myself, not sure it’s properly:
not yet, actually I solved the problem by myself.
I used “WordPress Install” tool of Hostgator, but it installed the old version (4.0.1), then upgraded to 4.2.2 automatically.
Then I configured multisite and it’s working fine.
zonkeyweb is correct! Thank you! – I upgraded my version of PHP to 5.6.x and it works again now. I can now add new inside sites within the multisite without issues again. Thank you!!!!!
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
Replace this define(‘DB_CHARSET’, ‘utf8mb4’); with define(‘DB_CHARSET’, ‘utf8’); in wp-config.php
@cybersource, bang on.. you saved me..
tvape & cybersource Are you sure that these methods are safe?
I saw some warnings in WordPress codex.
Read this: https://codex.wordpress.org/Editing_wp-config.php#Database_collation
And to those who just followed cybersource’s advice realize you’re now fully vulnerable to a severe and (now) publically disclosed security vulnerability that this was designed to fix.
Thread Starter
John
(@thesun2012)
@cybersource, @rakesh Ranjan
I tried that before I solved myself but no luck, it didn’t work and I don’t think that’s right way.
@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.
@miladnasri can you specify how its unsafe and what’s your solution for it?
@tvape Dude you saved my entire night! Thanks a lot!
Say, it’s really the first time I saw wordpress throwing fatal errors on its own, for the past 9 years.
