PHP normally only displays fatal errors in the browser, or doesn’t load any page content and gives you a “White Screen of Death (WSOD)” if it has a fatal error before the page can load. A fatal error is one in which something is so wrong in the PHP code that it cannot make sense of it to gracefully fail in the background. If I forget to add chocolate chips when making cookies, I still have a perfectly tasty dough. If I forget to add baking soda though, I end up with a flat, gooey mess.
WordPress has a few features built in to make it easier to see PHP errors while you are testing. You’d want to activate these while developing a new site, theme, or plugin to ensure that you are seeing any PHP errors that come up.
As mentioned in the last post on PHP Illegal Strings, there are a few failure types in PHP including warnings, notices, and errors. Turning on
WP_DEBUG will allow you to see those failure types so that you can fix them in your code.
If you have access to all of the files of your WordPress install, you’ll want to edit the
wp-config.php file, which is located in the root directory, meaning the same folder that has the
wp-includes folders. You’re going to go into that file and add the following line of code near the bottom of the file, but before the stop editing notice:
define( 'WP_DEBUG', true ); /* That's all, stop editing! Happy blogging. */
If that line already exists but says false, change that to true. There can be other lines of code above or below this, but as long as it’s above the comment to stop editing, it’s in the right spot.
What did we do?
We’ve now told WordPress that rather than hide PHP errors, we want them to display while viewing the site.
WP_DEBUG is a PHP constant, which by convention are written in all caps. We’ve used the PHP
define() function to set the value of that constant to a boolean
true. Note that we didn’t surround the word true in quotes, otherwise PHP would read it as a string.
WP_DEBUG also allows us to see any deprecated functions that are running on our site. Deprecated functions exist in WordPress but are no longer the standard way to perform a particular tas. As an example, long ago in WordPress history you would get the ID of a category in WordPress with the function
the_category_ID(), but now the function to do the same in a better way is
Using WP_DEBUG_LOG and WP_DEBUG_DISPLAY
There are some companions to
WP_DEBUG that can be used to make it even more helpful. You may not always be able to easily see errors if they are loading behind content, or you may want to keep track of them over time to review later. Two other constants that are built into WordPress that can help are
WP_DEBUG_LOG allows you to save all of the debug errors that are getting displayed to a file in your WordPress install. That file gets saved to
wp-content/debug.log by default. Whenever an error occurs that
WP_DEBUG would display, it will also get saved to that file with a timestamp of when the error occured.
To turn on
WP_DEBUG_LOG you’ll want to define the following constant:
You don’t have to worry about creating the
debug.log file if it doesn’t already exist. WordPress will do this for you automatically as soon as it has an error to log. So hopefully not right away!
By default, setting
WP_DEBUG to true will display all errors on the screen in your browser, on both the visitor-facing frontend, and the admin-facing backend of your site. This is ok while you’re editing a site that isn’t live with other people using it, but you don’t really want those errors displaying to other site visitors. It will make the site look more broken than it is, and can even be a security concern.
If you want to use
WP_DEBUG but don’t want to display errors to the screen, set the following constant:
Again, if you don’t set that as false, it will default to true when debug is turned on. If you are setting it to false, you’re probably also setting
WP_DEBUG_LOG to true, since otherwise you won’t see the errors on the screen or in a debug log.
If you want to passively log errors for review later on a live site, just in case any come up, you can combine the three definitions above to turn on debug mode, log errors, and stop them from displaying on the site. I recommend doing this if you don’t have anything else handling these error logs for you, which you’d probably know if you did.
// Enable WP_DEBUG mode define('WP_DEBUG', true); // Enable Debug logging to the /wp-content/debug.log file define('WP_DEBUG_LOG', true); // Disable display of errors and warnings define('WP_DEBUG_DISPLAY', false);
Continuing to Debug Your Site
The settings above display PHP errors, but they don’t actually do anything to fix them. You’ll need to handle that yourself. Still, they provide an invaluable source of information to determine why something is broken on your site. This won’t show all types of errors that could occur, since not all broken page or feature problems are PHP related.
What it does do is give you a good footing to begin the fun part of debugging: digging into code and squashing bugs as you find them. In this case the old proverb is true: Knowledge is Power.