Debugging in WordPress
WordCamp San Francisco 2011 August 13, 2011
Andrew Nacin Core Developer of WordPress Tech Ninja at Audrey Capital [email protected] @nacin on Twitter
var_dump( $data ); die( ); // f in.
“I love suppressing error messages!” — no one, ever.
So let's start with WP_DEBUG define( 'WP_DEBUG', true );
What WP_DEBUG does:
— Sets the error reporting level to include PHP notices
— Bypasses some error suppression
— Triggers notices for deprecated usage (more on that later)
You can change its output:
// A default of true forces on display_errors. define( 'WP_DEBUG_DISPLAY', true ); // Setting it to false will let PHP (php.ini) decide. define( 'WP_DEBUG_DISPLAY', false ); // So, if your php.ini has display_errors on, you'll also need to turn it off: ini_set( 'display_errors', 0 );
Likely being simplified in 3.3:
// A default of true forces on display_errors. define( 'WP_DEBUG_DISPLAY', true ); // False forces off display_errors. define( 'WP_DEBUG_DISPLAY', false ); // Null will let PHP (php.ini) decide. define( 'WP_DEBUG_DISPLAY', null );
You can specify an error log:
// wp-content/debug.log define( 'WP_DEBUG_LOG', true ); // New in 3.3! (Likely.) define( 'WP_DEBUG_LOG', '/tmp/php-errors' ); // Follow ticket #18391, created last night.
Debug admin CSS & JS with SCRIPT_DEBUG define( 'SCRIPT_DEBUG', true );
SCRIPT_DEBUG prevents minification and concatenation of core scripts and styles. load-scripts.php?c=1&load=global,wp-admin,ms… versus global.dev.css, wp-admin.dev.css, ms.dev.css
SCRIPT_DEBUG is good for:
— Finding bugs in your admin screens
— Studying the admin theme
— Contributing to core
Debug queries with SAVEQUERIES define( 'SAVEQUERIES', true );
SAVEQUERIES stores query data in $wpdb->queries. (OMG BBQ: This is NOT for production.)
Query: SELECT * FROM wp_users WHERE user_login = 'nacin'
Backtrace: WP->init, wp_get_current_user, get_currentuserinfo, wp_validate_auth_cookie, get_user_by
Execution time: 0.4ms
On using these in production:
WP_DEBUG — Don't display errors — Don't log to wp-content/error.log
SCRIPT_DEBUG — Bad idea.
SAVEQUERIES — Barry will hunt you down.
Plugins
Your new best friend: The Debug Bar It’s like Firebug for your WordPress.
Debug Bar Console A Firebug-like console for PHP and MySQL (really)
What's stopping you from building your own Debug Bar extension? Nothing.
Log Deprecated Notices — Logs the usage of deprecated files, functions, and function arguments. — Pinpoints where the deprecated functionality is being used. — NEVER use in production.
Theme Check — Test your theme for the latest WordPress standards and practices. — Required for the theme directory.
Common functions when debugging — error_log and var_export / print_r — var_dump and sometimes die — debug_backtrace
Tracking it down
Step 1 Disable plugins Switch to default theme
What might be left behind? Cron, Rewrites, Roles/Capabilities
Drop-ins — advanced-cache.php — db.php — object-cache.php — mu-plugins
What's going on? Query vars set properly? Main query SQL look right? Rewrite rule matched?
Funny redirect? Confirm it's canonical.
remove_action( 'template_redirect', 'redirect_canonical' );
Testing multisite?
I leave this in my config: // define( 'MULTISITE', true );
Dig into the codebase. Your friends are phpxref, grep. Learn the stack. Learn what things call what.
Some common traps
Step 1 Is your code even running? (Spell the hook right?)
die( 'wtf' ); or error_log( )
White screen on the frontend, no errors? Appearance > Themes
User interface doesn't work? Check the browser's JS console for an error, usually a conflict.
Internal server errors? Infinite redirects. Check: — home and siteurl — then .htaccess — then canonical
Widgets got moved around? Do the sidebars have IDs? Otherwise, it's the order in which register_sidebar() is called.
Lots of pages? Slow site? My next Q: What's your permalink structure? No longer an issue in 3.3!
Weird Bug #1 Somewhere deep in style.css: “Template: home.php” Miscalculated as a multisite bug: activated on single site before style.css had the headers.
Weird Bug #2 The admin looked weird
Weird Bug #2 The admin looked weird
Trigger: Upgrade from 2.5 to 3.1
Weird Bug #2 The admin looked weird
Trigger: Upgrade from 2.5 to 3.1 Problem: No MySQL ALTER permissions
Weird Bug #3 Some bbPress rewrites failed after activation
Weird Bug #3 Some bbPress rewrites failed after activation Problem: Custom post type rewrites aren't registered on activation
// Say you have: add_action( 'generate_rewrite_rules',
function( $wp_rewrite ) { … } ); // And: register_activation_hook( __FILE__, function() { flush_rewrite_rules( ); } ); // But! This won't work for CPTs. Try this: add_action( 'init', 'my_register_post_types' ); register_activation_hook( __FILE__, function( ) { my_register_post_types( ); flush_rewrite_rules( ); } );
Local Development
/etc/hosts 127.0.0.1 andrewnacin.com Configure virtual hosts Install local WordPress
Replace links with an output buffer for development or staging environments
// Run this on development or staging. // A development wp-config.php or local-config.php is fine. ob_start( 'nacin_dev_urls' ); function nacin_dev_urls( $buffer ) { $live = 'http://andrewnacin.com'; $dev = 'http://dev.andrewnacin.com'; return str_replace( $live, $dev, $buffer ); }
URLs are more portable when they're absolute.
Really.* The serialized stuff is lame though.
Start of a conversation Xdebug (backtraces, profiling) KCacheGrind (visualization) Using an IDE Unit testing
And finally, remember: Friends don't let friends develop without WP_DEBUG.
Thanks! Questions?
@nacin
Recommended
