Tag: WP_DEBUG

5 Ways to Debug WordPress

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?

Deprecated functions and WP_DEBUG

(Updated June 27, 2010: You may wish to check out my Log Deprecated Notices plugin.)

In every major version, the WordPress developers send functions to the graveyard. Many developers continue to use deprecated functions in their pluigns, or may even begin to use a function after it was already deprecated.

Deprecated functions cannot be relied upon to work efficiently or correctly and may be disabled by default or entirely removed in future versions of WordPress. But really, I would think about it like this: By using them, you’re likely missing out on new features afforded by the new function.

There are various reasons we deprecate functions:

  • We may decide to change or improve how it the function works, but doing so might break backwards compatibility. So we deprecate the old function and come up with a new one.
  • We may rename a function to standardize its name with other functions or to clarify its usage. Developers tend to like APIs standardized as much as possible, as it means we can work faster.
  • We may consolidate functions — for example, the_author_meta($meta) and get_the_author_meta($meta) replaced 25 functions.[1] Yes, 25. And it can return any usermeta field. current_user_can(), likewise, replaced a bunch of functions along the lines of user_can_create_draft() and user_can_edit_post_date(). In another example, we’re consolidating category and tag operations under term/taxonomy operations.
  • We may remove functions that no longer do anything. (Why do we keep a function that doesn’t do anything? If a plugin tries calling a function that no longer exists, you’ll get a fatal error. Also, if a plugin uses the same function name in a later version, the plugin would be incompatible on an old version that has the function.)
  • When merging in WordPress MU in 3.0, we removed dozens of functions, in many cases to merge them with their non-MU counterparts.

We normally don’t deprecate functions when we change front-end terminology, as we trust developers to make the connection, and we’re not nuts enough to rename functions just for the sake of renaming them.

What else do we deprecate?

We also don’t have just deprecated functions. We have deprecated files and, as of 3.0, deprecated function arguments.

Deprecated files: MagpieRSS (wp-includes/rss.php) has not been developed for years, and is deprecated in favor of Simplepie (wp-includes/class-simplepie.php). Most others were files that have been renamed, but we had to keep the old one because they were ones often included directly by plugins. In these cases, the old file includes the new files, so you don’t lose functionality. Deprecated files include:

  • wp-includes/rss-functions.php, now wp-includes/rss.php (also deprecated; use Simplepie)
  • wp-includes/registration-functions.php, now wp-includes/registration.php
  • wp-admin/upgrade-functions.php, now wp-admin/includes/upgrade.php (contains wp_install(), dbDelta(), etc.)
  • wp-admin/admin-functions.php, now wp-admin/includes/admin.php
  • WordPress does not support the legacy my-hacks.php file

Deprecated arguments: (new in 3.0) In nearly all cases, deprecated function arguments no longer have any functionality tied to them and often don’t have alternatives available. If we later add an argument to that function, though, we don’t want to take the spot of an argument that used to be there, in case a plugin developer still tried using the original argument.

Where we keep them

Deprecated files and arguments are scattered throughout core, but we consolidate deprecated functions so developers can reference those files. In 2.9, the file was wp-includes/deprecated.php. In 3.0, we now have five files:

  • wp-includes/deprecated.php — Regular WordPress functions available everywhere.
  • wp-admin/includes/deprecated.php — For WordPress functions only usable in the administration area.
  • wp-includes/ms-deprecated.php — Functions from WordPress MU, loaded only when running multisite.
  • wp-admin/includes/ms-deprecated.php — Functions from WordPress MU only usable in the administration area.
  • wp-includes/pluggable-deprecated.php — Pluggable functions. Because pluggable functions are defined later (so a plugin can override them), we can’t put these in the normal deprecated.php file. Moving them into its own file allows us to lower their profile.

Keeping track of deprecated usage

As of right now in 3.0, we have 131 deprecated functions and 39 deprecated arguments. How should you, a plugin developer, keep up with them all?

define( 'WP_DEBUG', true );

If you’re a plugin or theme developer and you don’t know what the WP_DEBUG is, you’re missing out. (If you do know what it is and you don’t use it during development, you’re crazy.)

The WP_DEBUG constant, which you would define as true in wp-config.php, does two things. First, it tells PHP to report more errors, specifically “notices.” (WordPress normally instructs PHP to only report warnings and fatal errors.)

This means you will see 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.)

Second, WP_DEBUG exposes debug messages generated by WordPress, such as:

  • When a deprecated function or function argument is used, or a deprecated file is included.
  • When user levels are used instead of the roles and capabilities system.
  • When old APIs are utilized instead of new ones, such as the Settings API (register your settings!).

In a nutshell, there’s an entire API devoted to informing you of the best practices and the latest APIs. Here’s two example notices:

Notice: options.php was called with an argument that is deprecated since version 2.7! The “your_option_name” setting is unregistered. Unregistered settings are deprecated. See http://codex.wordpress.org/Settings_API

Notice: get_category_rss_link is deprecated since version 2.5! Use get_category_feed_link() instead.

You can suppress notices if you prefer, by using the WP_DEBUG_LOG and WP_DEBUG_DISPLAY constants (see the inline documentation I wrote here). You can also use hooks and filters in the Deprecated API (view the functions). (To know where functions are being run, you could run a backtrace on one of those hooks, for example.)

Many even run WP_DEBUG on their production websites. Generally, they log it (using either WP_DEBUG_LOG or a server PHP error log) and force the hiding of errors, using:

define( 'WP_DEBUG', true ); // turn on debug mode
define( 'WP_DEBUG_LOG', true ); // log to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // don't force display_errors to on
ini_set( 'display_errors', 0 ); // hide errors

“But I need to support old versions”

Honestly, I wished you didn’t ask that. But if you must support a legacy version, conditionally check for the new functions and use those if available.

// esc_url() introduced 2.8
$cleaned_url = ( function_exists( 'esc_url' ) )
	? esc_url( $url )
	: clean_url( $url );

 // introduced 2.8
if ( function_exists( 'wp_register_sidebar_widget' ) )
	wp_register_sidebar_widget( 'widget-id', 'My Widget', 'my_widget_callback' );
// introduced 2.2, if you must check
elseif ( function_exists( 'register_sidebar_widget' ) )
	register_sidebar_widget('My Widget', 'my_widget_callback' );

Just remember: friends don’t let friends develop plugins without WP_DEBUG.

[1] These functions were deprecated in favor of get_the_author_meta(): get_author_name(), get_the_author_ID(), get_the_author_aim(), get_the_author_description(), get_the_author_email(), get_the_author_firstname(), get_the_author_icq(), get_the_author_lastname(), get_the_author_login(), get_the_author_msn(), get_the_author_nickname(), get_the_author_url(), get_the_author_yim(). In favor of the_author_meta(): the_author_ID(), the_author_aim(), the_author_description(), the_author_email(), the_author_firstname(), the_author_icq(), the_author_lastname(), the_author_login(), the_author_msn(), the_author_nickname(), the_author_url(), the_author_yim().