Many plugin and theme authors don’t take full advantage of some really helpful debugging tools in WordPress. Here’s a quick run-down of five cool tools for debugging:
1. WP_DEBUG
define( 'WP_DEBUG', true );
It’s no secret I love this constant and everything it stands for. Define it in wp-config.php and you’ll start seeing PHP notices and also WordPress-generated debug messages, particularly deprecated function usage.
(Added June 27, 2010: You may wish to check out my Log Deprecated Notices plugin.)
There’s also WP_DEBUG_DISPLAY and WP_DEBUG_LOG, which enable you to log these to a wp-content/debug.log file. I’ve added some inline documentation that describes these both well. Some use WP_DEBUG on a live site and just make sure it gets logged.
WP_DEBUG will often reveal potential problems in your code, such as unchecked indexes (empty() and isset() are your friend) and undefined variables. (You may even find problems in WordPress itself, in which case you should file a bug report.)
2. SCRIPT_DEBUG
In the admin, WordPress minimizes and concatenates JavaScript and CSS. But WP also comes with the “development” scripts, in the form of dev.js and dev.css. To use these instead:
define( 'SCRIPT_DEBUG', true );
3. SAVEQUERIES
The WordPress database class can be told to store query history:
define( 'SAVEQUERIES', true );
When this is defined, $wpdb->queries stores an array of queries that were executed, along with the time it takes to execute them.
The database class has additional error and debugging tools, which are documented on the Codex (though when in doubt, check the source).
4. The ‘all’ and ‘shutdown’ hooks
There’s an ‘all’ hook that fires for all actions and filters. Example usage:
add_action( 'all', create_function( '', 'var_dump( current_filter() );' ) );
You’ll be surprised how many hooks get executed on every page load. Good for troubleshooting and identifying the right hook.
There’s also a ‘shutdown’ hook you can use in combination with, say, SAVEQUERIES, and write the query information to the database. It’s the last hook to run.
5. Core Control
There are plenty of great developer-oriented plugins out there, but I’m not sure any list would be complete without Dion Hulse’s Core Control plugin. It is comprised of five modules covering Filesystem methods, HTTP methods, HTTP logging, Cron tasks, and upgrades. A must-have.
This list is by no means exhaustive, just some quick hits to get you started. What tools do you use?
Pingback: 5 Ways to Debug WordPress | WPLover
I use Ryan’s Dump Environment plugin, which prints the main global variables’ values in the footer. It’s simple but helpful especially for debugging rewrite rules.
WP Developer Assistant is one of my favorites; it’s a snazzy little plugin with a few features that help make debugging easier, my favorite of which has to be the actions/filters list showing everything that’s currently hooked.
Thanks for the post Andrew, I knew about WP_DEBUG but I had no idea we had SCRIPT_DEBUG and SAVEQUERIES at our disposal. Great heads up.
It’s sad, but I know only the first method to debug WordPress. Others are very new to me, and useful, too.
There’s a plugin of Yoast.com, that can help us to debug, too. It displays useful information for developer.
Thanks for sharing.
@Austin: I forgot about that one, thanks! Looks like it could use an update for some of the other major WP globals, but obviously it gets the job done.
@Mark: WP Developer Assistant looks pretty cool, I’ll have to check it out.
@DBT: At least you knew WP_DEBUG.
Many plugin developers don’t.
Pingback: Best On WordPress From The Past Week N.3 | wpCanyon
Pingback: Notable Tech Posts – 2010.04.25 | The Life of Lew Ayotte
This is really helpful for when I add new functions to the functions.php and tweak my php files around a bit. Thanks for sharing this.
I didn’t know WP_DEBUG until Nacin showed me the light.
Pure Gold
dont forget AskApache Rewrite Viewer and Jan Fabry’s rewrite analyzer which you can get here: http://wordpress.stackexchange.com/questions/3606/a-tool-to-analyze-rewrite-rules/3608#3608 for all your rewriting needs.
Pingback: Ladíme WordPress a odstraňujeme chyby « WordPress.sk
The all hook var_dump is immense. Extremely helpful — thanks!
Despite it being an information overload, I do use it from time to time. I usually write it to avoid printing filters with ‘gettext’ in the name, though.
Pingback: mois-Blog - WordPress-Debug-Instrumente
Pingback: Zajímavé články o WordPressu (v angličtině) « Fórum podpory WordPressu
Pingback: Around the web | alexking.org
Pingback: Workshop: Advanced WordPress with NYU’s Studio20, 5/8/11 | Daniel Bachhuber's weblog
Thanks, great article. I just finished setting up Netbeans as a PHP debugger and figured out how to get it to step through our plugin code. I wrote up a how-to on it here: http://sidneyharrell.com/?p=28
Any tips for Multisite installations . . . .
Pingback: Plugin Strategy | beAutomated
Pingback: Yet Another WordPress Development Environment and Debugging Post | | Gabriel's BlogGabriel's Blog
There is another way to deal with wordpress debugging. WordPress FirePHP Debugger plugin shares an elegant, simple, and more maintainable way of debugging wordpress via the web browser.
Main features:
Automatic detection of FirePHP server library inside php include path or separated directory
Early loading of the debugger (before WordPress engine starts)
No modifications to WordPress core or configuration files
Automatic enabling of WordPress debug mode
Handles all php fatal errors (no more blank pages and logs parsing)
Logs WordPress deprecated functions and arguments
Safe debugging on live site
SQL queries log
PHP superglobals and constants
System information (WordPress and server environment)