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.
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
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.
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.
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.
// 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