This is just a quick post about a more streamlined method of catching PHP errors using WordPress’ built in debugger:
When developing with WordPress, most people know of these two definitions that should go in wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', true );
These definitions are essentially just an easier way to enable php.ini error logging, because I suppose that there are circumstances where you shouldn’t/wouldn’t want to start messing with your PHP config files.
Recently, I’ve grown irritated of WP_DEBUG_DISPLAY clogging up the front-end designs during build – turns out that there’s a third argument that I’ve found to be much cleaner:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );
By enabling WP_DEBUG_LOG, WordPress will create a debug.log file in the /wp-content/ directory that will automatically update with PHP errors as you come across them (which again, is WordPress’ own alternative to error_log).
However, the main fallback to this is that your error messages are no longer in plain sight, and instead, hidden away in another tab in your text editor. The other fallback, is that if you want to monitor changes, you’ll have to manually reload the file every time you want to catch an error.
This is where the the Terminal comes into play. If you open up Terminal, and enter:
tail -f /path/to/wp-content/debug.log
This will open up your log file and will automatically update so that you can monitor your PHP errors in real-time. I’ve found this to be indispensable for productivity, usually having the Terminal on one screen, and the code/front-end on the other.
I’m 100% sure that there are ways to extend this further (for example, with xDebug), but I thought I’d share this quick little tip.