WP_Error wrote instead of category name in wp_options table, category_base field

[Neilgaiman]

I just installed WordPress 4.8, yet I'm not sure it's a bug specific of this version or not.

The issue is documented in the following post:

​http://www.ryadel.com/en/catchable-fatal-error-object-of-class-wp_error-could-not-be-converted-to-string-wordpress-fix/

Long story short, it seems that sometimes (when some errors occurs, in my scenario was a I/O error) the category_base value of the wp_options table gets filled with a WP_Error json object instead of a category name. This raises an exception in the rewrite.php script (line 326) when the function tries to use that value against a regex, expecting a string.

Sadly enough, it doesn't seem easy to reproduce.

[Neilgaiman]

As explained in my post, the easiest workaround seems to set the category_base value empty (empty string): that way the category_base original value is lost but at least the website doesn't crash.

Other viable fixes could include the following:

• trap the rewrite.php method (using try/catch) so that it won't crash the web application (weak)

• throw/log/output the WP_Error to the user instead of silently writing it into the category_base value (probably the best approach)

[kirasong]

Hi, and thanks much for the very detailed report.

I'm sorry it has taken this long for a reply to your ticket.

It was brought up in triage today, and while we weren't able to reproduce it during triage, I'm moving it to the permalinks component so that it can be checked by the most appropriate folks.

Thanks again!

[SergeyBiryukov]

Hi there, welcome to WordPress Trac! Thanks for the report.

This is somewhat similar to #50850, specifically comment:2:ticket:50850.

Adding some protection against an invalid value sounds good in general, but this doesn't seem any different from accidentally setting an invalid value for any other option. I don't think we can realistically protect against that, so the warning seems appropriate here to notify the site owner that something is wrong. Hiding the warning or attempting to work around it would only make debugging harder.

If there is a path in core where accidentally setting a WP_Error value for category_base can be easily reproduced with a specific example, demonstrating that would probably be a good idea for the ticket to move forward.

The comments on the linked post point to a similar error message ("Recoverable fatal error: Object of class WP_Error could not be converted to string"), but in quite a different context: wp-includes/formatting.php or a theme's eventchamp/include/speaker-modules.php file. So far, this doesn't seem like a common issue.