如何在没有堆栈跟踪的情况下查找PHP通知的原因?

时间:2018-03-08 作者:Robert Andrews

我的WordPress调试。日志中充满了这组七个PHP警告/通知,至少每半小时出现一次。。。

[08-Mar-2018 09:05:03 UTC] PHP Notice:  Trying to get property of non-object in /home/mysite/public_html/wp-includes/class-wp-query.php on line 3736
[08-Mar-2018 09:05:03 UTC] PHP Notice:  Trying to get property of non-object in /home/mysite/public_html/wp-includes/class-wp-query.php on line 3738
[08-Mar-2018 09:05:03 UTC] PHP Notice:  Trying to get property of non-object in /home/mysite/public_html/wp-includes/class-wp-query.php on line 3740
[08-Mar-2018 09:05:03 UTC] PHP Notice:  Trying to get property of non-object in /home/mysite/public_html/wp-includes/class-wp-query.php on line 3736
[08-Mar-2018 09:05:03 UTC] PHP Notice:  Trying to get property of non-object in /home/mysite/public_html/wp-includes/class-wp-query.php on line 3738
[08-Mar-2018 09:05:03 UTC] PHP Notice:  Trying to get property of non-object in /home/mysite/public_html/wp-includes/class-wp-query.php on line 3740
[08-Mar-2018 09:05:03 UTC] PHP Warning:  Cannot modify header information - headers already sent by (output started at /home/mysite/public_html/wp-includes/class-wp-query.php:3736) in /home/mysite/public_html/wp-includes/pluggable.php on line 1216
问题是,据我所知,没有提到是哪个插件或罪魁祸首导致了这种情况(我认为这个术语是,没有回溯/堆栈跟踪),所以我发现很难调试。

问题是:How can I find out more detail in order to trace the cause?

我已经有了WP_DEBUG, WP_DEBUGWP_DEBUG_DISPLAY 全部设置为true。

我已经了解了设置PHPdisplay_errorserror_reporting 但是,由于我已经收到通知和警告输出,我不确定这些设置是否会添加更多细节。

这些警告是否可能是由非WordPress插件生成的?我有一个在cron上运行的PHP脚本,它调用wpdb环境,但严格来说它不是一个插件。

2 个回复
SO网友:Ted Stresen-Reuter

您可以通过捕获E\\u通知消息来获取回溯。如果将以下代码段添加到wp config。php之前

/* That\'s all, stop editing! Happy blogging. */
您应该在错误日志中看到完整的回溯。

set_error_handler(function() {
    error_log(print_r(debug_backtrace(), true));
    return true;
}, E_USER_NOTICE);

define( \'WP_DEBUG\', true );
define( \'WP_DEBUG_LOG\', true );
define( \'WP_DEBUG_DISPLAY\', false );

/* That\'s all, stop editing! Happy blogging. */
PS:返回true 函数末尾告诉PHP停止处理E\\u通知,这可能是您现在想要的。

我只是在一个项目中使用了这种方法,这正是我所寻找的解决方案。事实上,我在寻找做同样事情的方法时发现了这篇文章。航行愉快!

SO网友:squarecandy

Ted的答案对我来说很有用,但非常冗长,如果你不小心打开了它,它既很难阅读,也很容易意外创建一个巨大的日志文件。

最后,我用它来创建更简洁的日志条目:

set_error_handler(function() {
    $log = "\\r\\n==========\\r\\nSTACK TRACE:";
    foreach ( debug_backtrace() as $i => $item ) {
        if ( 0 === $i ) {
            $log .= "\\r\\n" . $item[\'args\'][1];
        } else {
            $log .= "\\r\\n" . $item[\'file\'] . \' -- line \' . $item[\'line\'];
        }
    }
    $log .= "\\r\\n==========";
    error_log( $log );
    return true;
}, E_USER_NOTICE);

define( \'WP_DEBUG\', true );
define( \'WP_DEBUG_LOG\', true );
这将我所看到的特定错误从日志文件中的13000行减少到大约20行,并允许我快速确定哪个插件是罪魁祸首。

结束