Do you ever make mistakes? I do. The first step to fixing your errors is knowing what the mistake is. I can’t solve all your problems, but I can help improve those generated by PHP code on your WordPress site by helping you work with debug logs.
A few weeks ago, when I wrote about customizing your WordPress site’s wp-config.php file, I covered settings for debugging. I covered how to show errors and when you might not want to do that. At the same time, enabling WP_DEBUG, as described in that article. So, it is essential in development, you may have some non-fatal errors. You can’t avoid warnings that you don’t want to display to all of your visitors for whatever reason. Also, you may be unaware of errors and warnings. As you never triggered them, but your site’s visitors are seeing them.
For these reasons, on a live site, it’s a good idea to leave WP_DEBUG on. To prevent errors from appearing while using WordPress debug log. To see these errors and warnings. You will need to write them to a particular log file so that you can review them. This article will cover setting up error logging and various ways to view your logs. I will also cover how to write other information to that log and when you might want to do that.
Even when you’re displaying errors, logging errors is still functional, as having a record of your errors is often very useful in development. You might not be able to make much sense of a mistake when it occurs, but once you have more information from subsequent work, the record in your log may be very useful.
Setting Up
This is a brief review of what I discussed in my wp-config article. If you’ve never edited your site’s wp-config file or do not know what that is or what a constant is, I recommend reading that article and returning to this one.
To enable debugging, prevent errors and warnings from appearing, and log errors, you need these three lines in your wp-config:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG_LOG', true );
It’s important to note that you can do nothing to prevent a fatal error from causing a white screen of death besides enabling debug display, which will show you a white screen with the error in it.
Viewing Your WordPress Debug Log
The actual debug log is saved in a file called debug.log in your site’s content directory. Accessing that file directly is one way to view and clear your record. That’s not a good way of working, especially if your site is on a remote server. Some plugins make it easier to work with your debug log, which I will discuss shortly. That said, it’s essential to be familiar with this method, as if you can’t access the WordPress back-end due to a fatal error, your debug log might hold the clues to understand why.
There are multiple ways to view your debug log from the WordPress backend. My preferred method is using the Log Viewer plugin. This free plugin gives you two ways to view your debug log, as well as the ability to clear it. When this plugin is active, you can view your log from its admin page, which is accessible inside the Tools menu.
In addition, if you have the Debug Bar plugin active, one of the most useful development tools for WordPress, you can view your log from a panel of the Debug Bar. I do not recommend having Debug Bar active on a live site, so it is nice to have both options. Both plugins can be installed from the WordPress installer or the Developer plugin, which is full of valuable tools to help improve your development.
Here is what the WordPress debug log view looks like:
As you can see, every time WordPress encounters a warning or error or generates a notice, the error, warning, or notice is written to the log with a time stamp in UTC.
Writing Other Information To Use WordPress Debug Log
Sometimes, you might want to write information to the log, even if it’s not technically an error. PHP has a function called error_log that will print data to the error log for you. By default, it does not print and format appropriately. For this reason, I recommend adding an extra function to your site to handle the formatting. It is a wrapper for error_log that uses print_r() to format arrays and objects properly before logging them. Here is what the function looks like:
if ( ! function_exists('write_log')) {
function write_log ( $log ) {
if ( is_array( $log ) || is_object( $log ) ) {
error_log( print_r( $log, true ) );
} else {
error_log( $log );
}
}
}
I strongly advise against adding this to your theme’s functions.php to use WordPress debug log. As in that case, it will no longer work if you take the common debugging step of switching to the default theme. Instead, create a plugin for this function. Doing so simply requires creating a file in your plugin directory, adding a plugin header, and this function. The title can be as simple as this:
/* Plugin Name: Log Error */
Once this function is available to you, it has a variety of uses. Want to know if a specific line of code ever gets called? Use:
write_log( __LINE__ );
You can even use it to gather essential intelligence about your site. For example, want to log in when a specific post was viewed and if the user who viewed it was logged in? Here’s some simple code to do that:
add_action( 'wp_head', 'slug_log_post_view' );
function slug_log_post_view() {
//set the ID of the post you want to track here:
$post_to_track = 42;
//get the current post's ID & make sure it's a valid ID and it matches our ID
$id = get_queried_object_id();
if ( intval( $id ) > 0 && $post_to_track === $id ) {
//check if current user is logged in and if so get the user ID
if ( is_user_logged_in() ) {
$user_id = get_current_user_id();
$user_id = 'a user with the ID ' . $user_id;
}
else{
$user_id = 'a user that was not logged in.';
}
//log the information
write_log( "The post {$post_to_track} was accessed by {$user_id}" );
}
}
While this function is not Google Analytics, it does provide a quick and dirty way to gather intelligence on a specific post. Set the correct post ID in the variable, $post_to_track. You could even enable this for all positions by removing the check to see if $post_to_track equals $id. If so, change the last line to $id, instead of $post_to_track.
All Kids Love Log
I hope this introduction to error logging in WordPress has shown you how to use this often overlooked capability of WordPress to help you debug any issues on your site. Don’t forget that PHP errors are not the only type of errors that you can generate. There are also JavaScript errors, which will show up in your browser’s JavaScript console.
