php satellite_object_to_string,Object of class WP_Error could not be converted to string in /wp-incl...

2017年6月11日，该网站经历了严重的停机，原因是WordPress数据库中发生了非常奇怪的错误。如果您偶然发现了这篇文章，则可能会受到同一问题的影响。

该问题看起来像是标准的HTTP 500 –应用程序错误，该错误阻止了所有非缓存的页面。像往常一样，我要读取实际错误的第一件事是启用wp-config.php文件中的WP_DEBUG和WP_DEBUG_LOG开关，您可以肯定地知道该文件位于WordPress安装根文件夹中：

// 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

正如我们在上面的注释中可以看到的那样，这些开关中的第一个显示HTTP响应中的错误，而后者将其写入专用的debug.log文件中。

无论如何，这是实际的错误：

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

可捕获的致命错误：类别WP_Error的对象无法在第326行的/var/www/ryadel.com\wp-includes\rewrite.php中转换为字符串

可悲的是，给定的信息不足以粉碎很多信息。我简要地看了一下rewrite.php源代码，找到了以下功能(第326行是突出显示的功能)：

* 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;

}

尽管如此，这足以理解一些有关潜在问题的知识：寻找类别名称并找到WP_Error对象的代码。

我要做的下一件事是查看PHP错误日志。在那里，我发现了上述错误的确认，还有一些有趣的信息，这些信息极大地帮助我了解了实际发生的情况：

[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-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-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-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-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-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-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-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-includes\rewrite.php on line 326

图片的形式是：根本原因很可能是I / O权限问题，导致WP_Error对象被写入MySQL表而不是预期的类别名称。尽管我无法确定这是WordPress代码问题还是MySQL问题，但所有线索都导致了前者(Worpdress版本是4.8，仅在问题发布前两天发布)。

使用SQLyog进行的快速筛选搜索(如果您不知道它是什么，请阅读此处)，帮助我找到了实际存在的问题值：wp_options表中的category_base选项。

键/值的外观如下：

解决问题后，修复非常简单：删除category_base键中的所有内容并将其保留为空实际上可以解决问题，从而使网站恢复正常。

就是这样。如果您碰巧遇到此问题，现在您知道如何彻底解决它。

历史上的今天: