You Better use WP_DEBUG_LOG in WordPress Development

In this short post, we’ll see what the correct way is to monitor PHP errors on WordPress sites using WP_DEBUG_LOG. Like most things related to WordPress development, it can be said that the best way to understand a specific function is simply to search for that function in WordPress core files and take a look at the code.

Here is the code for the wp_debug_mode function. The important and relevant part appears in wp-include/load.php:

function wp_debug_mode() {
    if ( WP_DEBUG ) {
        error_reporting( E_ALL );

        if ( WP_DEBUG_DISPLAY )
            ini_set( 'display_errors', 1 );
        elseif ( null !== WP_DEBUG_DISPLAY )
            ini_set( 'display_errors', 0 );

        if ( WP_DEBUG_LOG ) {
            ini_set( 'log_errors', 1 );
            ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );
        }
    } else {
        error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
    }
    if ( defined( 'XMLRPC_REQUEST' ) )
        ini_set( 'display_errors', 0 );
}	

Let’s skip the explanations for each line, but in essence, if you set WP_DEBUG_LOG to true, WP_DEBUG_DISPLAY to false, and WP_DEBUG is also true, the result will be that all PHP errors will be recorded in the debug.log file created in the wp-content directory but will not be displayed in the browser (on the frontend).

To configure this, use the following code:

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

But why do this? Here are three reasons why it’s preferable to use WP_DEBUG_LOG over WP_DEBUG:

Hidden Error Messages

You’re used to seeing PHP error messages in the browser, but are you sure you see all of them? What about elements hidden in CSS and AJAX calls?

Beyond the fact that many times errors are not conveniently displayed in the browser, the user interface is not a reliable place to catch all error messages. In contrast, the PHP log file shows all of them, and you won’t miss any…

Missing Error Messages

Maybe you like to use plugins like Debug Bar or Query Monitor to monitor and receive error messages, and you’re very satisfied with them.

I don’t blame you; they are great plugins. However, I’ve encountered situations where they miss errors. This may happen because these plugins are ultimately plugins and can be affected by other plugins loading before them.

You can change the order of plugin loading using other plugins like Plugin Organizer, but what about plugins in the MU plugins directory or errors in WordPress core files themselves?

As convenient as these plugins are, relying on them alone to detect all PHP errors on your WordPress site is a mistake. PHP itself is the most reliable source for error reporting, and you’ll receive it through the debug.log file.

Third-Party Plugins

In case your code is problematic and throws errors, you can fix that. But what if external plugins you installed throw errors and comments on your entire interface? When WP_DEBUG is active, it displays all errors without exception.

It can be very difficult to work when error messages and comments flood your entire screen, making it impossible to work, especially when certain plugins are active.

At this point, I’m sure I have your attention. You’ve already added those lines to wp-config.php, and you’re monitoring errors through the debug.log file. Here’s an example of how errors look in this
file:

[18-Dec-2017 09:18:08 UTC] PHP Fatal error:  Call to undefined function get_slocale() in /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/includes/home.php on line 9
[18-Dec-2017 09:18:08 UTC] PHP Stack trace:
[18-Dec-2017 09:18:08 UTC] PHP   1. {main}() /Users/roeeyossef/Sites/startapp/index.php:0
[18-Dec-2017 09:18:08 UTC] PHP   2. require() /Users/roeeyossef/Sites/startapp/index.php:17
[18-Dec-2017 09:18:08 UTC] PHP   3. require_once() /Users/roeeyossef/Sites/startapp/wp-blog-header.php:19
[18-Dec-2017 09:18:08 UTC] PHP   4. apply_filters() /Users/roeeyossef/Sites/startapp/wp-includes/template-loader.php:73
[18-Dec-2017 09:18:08 UTC] PHP   5. WP_Hook->apply_filters() /Users/roeeyossef/Sites/startapp/wp-includes/plugin.php:203
[18-Dec-2017 09:18:08 UTC] PHP   6. call_user_func_array:{/Users/roeeyossef/Sites/startapp/wp-includes/class-wp-hook.php:286}() /Users/roeeyossef/Sites/startapp/wp-includes/class-wp-hook.php:286
[18-Dec-2017 09:18:08 UTC] PHP   7. thesis_skin->_skin() /Users/roeeyossef/Sites/startapp/wp-includes/class-wp-hook.php:286
[18-Dec-2017 09:18:08 UTC] PHP   8. thesis_skin->_template() /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/skin.php:1003
[18-Dec-2017 09:18:08 UTC] PHP   9. thesis_html_body->html() /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/skin.php:1065
[18-Dec-2017 09:18:08 UTC] PHP  10. thesis_box->rotator() /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/skin/boxes.php:604
[18-Dec-2017 09:18:08 UTC] PHP  11. call_user_func_array:{/Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/box.php:389}() /Users/roeeyossef/Sites/startapp/wp-content/themes/thesis/lib/core/box.php:389

The strange file path is due to the use of a local WordPress environment.

This post was translated from a post on deliciousbrains.com