Bronson Quick spoke at the WordCamp Sunshine Coast today on debugging for WordPress. He covered techniques for fixing a white-screen of death as well as getting detailed information to sort out squirrelly bugs and performance issues.
Firstly WordPress has a few rad constants you can switch on to get better information about where things are breaking.
define( 'WP_DEBUG', true ); //I was blind, now I can see (my PHP errors) define( 'WP_DEBUG_LOG', true ); //for production, write logs to wp-content define( 'SCRIPT_DEBUG', true ); //use non-minified versions of core CSS/JS define( 'SAVEQUERIES', true ); //log queries, look for suspicious ones. Not for production
Local Development
Develop in an environment close to the production hosting environment your site will be deployed to. The best way to do this is with virtual machines and tools like Vagrant.
Chassis is a WordPress focused VM for Vagrant. It’s configured with Nginx, MySQL, PHP 5.4 – 5.6 and has a bunch of handy extensions available to set up things like Xdebug, Debug Bar and Query Monitor quickly. The disposable nature of VMs means you can create one for each project.
Creating a Chassis VM
git clone git@github.com:Chassis/Chassis.git myproject cd myproject vagrant up
Chassis Extensions
Debug Bar gives you a lot of insight into what WordPress is doing to generate a page.
cd myproject/extensions git clone https://github.com/Chassis/Debugging.git vagrant provision
This will install a collection of Debug Bar plugins into WordPress en mass. What a time saver.
Query Monitor is an alternative tool for monitoring database activity in WordPress. It does more than monitoring SQL and can even show script dependencies, en queued styles and highlight errors.
So…
- Develop in an environment similar to where you’ll deploy. Let Chassis set that up for you.
- Use Xdebug, Debug Bar and Query Monitor as necessary to get insight into what your code is doing