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:
|
1 2 3 |
// DEBUG switches - activate them to enable backup and backup log (in /wp-content/debug.log) define( 'WP_DEBUG', false); // shows the error on browser's screen define( 'WP_DEBUG_LOG', false); // writes the error in /wp-content/debug.log |
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/ryadel.com\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):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
/** * Filters the URL base for taxonomies. * * To remove any manually prepended /index.php/. * * @access private * @since 2.6.0 * * @param string $base The taxonomy base that we're going to filter * @return string */ function _wp_filter_taxonomy_base( $base ) { if ( !empty( $base ) ) { $base = preg_replace( '|^/index\.php/|', '', $base ); $base = trim( $base, '/' ); } return $base; } |
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:
|
1 2 3 4 5 6 7 8 9 10 |
[10-Jun-2017 22:26:13 UTC] PHP Warning: mysqli_query(): (HY000/6): Error on delete of 'C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\#sql20c_985bf_0.MYI' (Errcode: 13 - Permission denied) in /var/www/ryadel.com\wp-includes\wp-db.php on line 1877 [10-Jun-2017 22:26:13 UTC] WordPress database error Error on delete of 'C:\Windows\SERVIC~2\NETWOR~1\AppData\Local\Temp\#sql20c_985bf_0.MYI' (Errcode: 13 - Permission denied) for query SHOW FULL COLUMNS FROM `wp_options` made by require(...) [10-Jun-2017 22:26:18 UTC] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in C:\<WP_PATH>wp-includes\rewrite.php on line 326 [10-Jun-2017 22:26:18 UTC] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in C:\<WP_PATH>wp-includes\rewrite.php on line 326 [10-Jun-2017 22:26:20 UTC] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in C:\<WP_PATH>wp-includes\rewrite.php on line 326 [10-Jun-2017 22:26:22 UTC] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in C:\<WP_PATH>wp-includes\rewrite.php on line 326 [10-Jun-2017 22:26:22 UTC] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in C:\<WP_PATH>wp-includes\rewrite.php on line 326 [10-Jun-2017 22:26:22 UTC] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in C:\<WP_PATH>wp-includes\rewrite.php on line 326 [10-Jun-2017 22:26:23 UTC] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in C:\<WP_PATH>\wp-includes\rewrite.php on line 326 [10-Jun-2017 22:26:24 UTC] PHP Catchable fatal error: Object of class WP_Error could not be converted to string in C:\<WP_PATH>\wp-includes\rewrite.php on line 326 |
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.
