Catchable fatal error: Object of class WP_Error could not be converted to string – How to Fix

On 11 June 2017 this website experienced a serious downtime that was caused by a very odd error occurred within the WordPress database. If you’ve stumbled upon this post, chances are you might be affected by the same issue.

The issue looked like a standard HTTP 500 – Application Error that blocked any non-cached page. As usual, the first thing I did to read the actual error was to enable the WP_DEBUG and WP_DEBUG_LOG switches within the wp-config.php file, which – as you most certainly know – is located inside the WordPress installation root folder:

As we can read in the above comments, the first of these switches shows the error within the HTTP response, while the latter writes it into a dedicated debug.log file.

Anyway, this is the actual error:

Catchable fatal error: Object of class WP_Error could not be converted to string in /var/www/\wp-includes\rewrite.php on line 326

Sadly, the given info were not enough to shred much light. I briefly took a look to the rewrite.php source code, finding the following function (line 326 is the highlighted one):

Nonetheless, that was enough to understand something about the underlying problem was about: the code looking for a category name and finding a WP_Error object instead.

The next thing i did was taking a look to the PHP error log. There i found a confirmation of the above error and also some interesting info that greatly helped me to understand what actually happened:

The picture was taking form: the root cause was most likely a I/O permission issue which resulted into a WP_Error object being wrote into a MySQL table instead of the expected category name. Although I couldn’t determine if this was a WordPress code issue or a MySQL issue, all the clues led to the former (Worpdress build was the 4.8, which was released only a couple days before the issue).

A quick filtered search using SQLyog (if you don’t know what it is, read here) helped me to find where the offending value actually was: the category_base option within the wp_options table.

Here’s how the key/value looked like:

Once the issue was figured out, the fix was really simple: deleting all the content within the category_base key and leaving it empty actually did the trick, bringing the website back up.

That’s about it. In case you happen to experience this issue, now you know how to overcome it for good.




About Ryan

IT Project Manager, Web Interface Architect and Lead Developer for many high-traffic web sites & services hosted in Italy and Europe. Since 2010 it’s also a lead designer for many App and games for Android, iOS and Windows Phone mobile devices for a number of italian companies.

View all posts by Ryan