How To Use The WordPress Debug Feature
Did you know that if you encounter a fatal error in your website, there is a WordPress debug feature built right into the product?
Many people don’t know about WordPress debug and/or don’t know how to use it. Many articles mention this feature but do not provide any instructions or examples of the feature in action. I often wondered how useful it was and how informative the error messages were. Most of all, was a developer required to understand the log messages? In this article we will answer all of these questions.
WORDPRESS DEBUG – HOW TO ENABLE IT
Using your favorite FTP application you will need to head over to the root folder of your website. In that folder open the wp-config.php file. This is the section you need to modify.
You need to set the WP_DEBUG setting to true because this enables debugging. If you are not actively debugging a site you should leave this turned off. Therefore your website will run faster and you won’t be using disk space storing logs you don’t need.
The WP_DEBUG_DISPLAY setting should typically be set to false. This determines whether or not the errors are displayed directly to the web page. When you are building a new site and you are clearing up errors it might be convenient to have this enabled. If this is instead a production site you might not want your customers to be greeted with a screen full of errors when they attempt to use your website.
The last setting WP_DEBUG_LOG when set to true will send all the errors out to a log file. This is typically what we want. It is especially relevant to note that the format of the messages sent to the screen and those sent to the file are almost identical.
WORDPRESS DEBUG – MY FIRST TEST
By the way, when I am in these files purposely breaking them I always add something like “888” into the middle of the text. As a result I can always find my addition even if I lose track of it in the file. For this first test I modified line 179 in the functions.php file located in the wp-content/themes/Divi folder. This produced the dreaded “WordPress white screen of death” (WSoD for short). Here I will show you how my modification appeared and how the message in the log file appeared. I was very impressed that it was so accurate in telling me exactly where to look!
WORDPRESS DEBUG – MY SECDND TEST
For this second test I wanted to see if the error messages in the logs could also help if the error on the sreeen was the 500 error. For this test I modified line 14 in the functions.php file located in the wp-content/themes/Divi folder. Here I will show you the error on the web page, how my modification appeared and how the message in the log file appeared. It seems like the error message in the log file was once again very informative (although the line number was a little off)!
WORDPRESS DEBUG – MY THIRD TEST
For my third test I wanted to try a different random file in the theme to see if the results were similar. I modified line 20 the header.php file in the child theme. Below you can see the error on the web page, how my modification appeared and how the message in the log file appeared.
WORDPRESS DEBUG – MY FOURTH TEST
Finally for my fourth test I wanted to dig into a plug-in and modify something there to see what would happen. Therefore, I picked the Yoast SEO plug-in. I modified line 8 in the wp-seo-main.php file located in the wp-content/plugins/worpress-seo folder. Before the file modification I went into a Yoast screen and after the modification I simply refreshed the web page. I will show you the error on the web page, how my modification appeared and how the message in the log file appeared.
WORDPRESS DEBUG – CONCLUSION
In conclusion, I was very impressed that in all my tests the messages in the log file indicated the exact file and approximate line in that file where the error occurred. Once you have discovered which module is causing your fatal error, refer to this companion article that contains steps to help you recover your website.