News & Info

Daily Updates and Tech Chatter

Intro To Debug Bar : Debugging WordPress With A Plugin

debug bar banner

One of the sessions I attended at WordCamp Atlanta had some very useful information for developing and debugging WordPress plugins.  Another had useful information on speeding up sites with transients.  And another touched on security issues.   Almost every session that went a little deeper into the tech side of WordPress mentioned a plugin that they all used… Debug Bar.

One of the sessions had a brief blurb on what Debug Bar does and what it looks like.  In short, it throws a small “Debug” link up on the admin menu bar.    Hidden under that little debug button is a treasure trove of useful site debugging information.   This is NOT something you want to have up and running at all times on a production site, but for a development site it is a God-send.    No longer will I be writing dozens of hooks in my code and cluttering up the UI with debug output expansion boxes… even though I spent some time building a jQuery based expandable div for that over the past few months.    Debug Bar is a much cleaner UI experience, and based on what I’m seeing in the plugin directory it is full of hooks and filters I can tap into with my plugins.

hello debug bar

hello debug bar

Getting and Prepping for Debug Bar

As with any plugin, getting and installing Debug Bar was simple.  Go to the admin panel / plugins page to get the add new process started.  Type in “debug bar” and there it is, right at the top of the listing.  Install and activate.

However, one thing I immediately noticed is the documentation is very sparse.  No links to an external site for more info.  No instructions on configuration.   I guess that is the built-in litmus test.  If you can’t figure out how to get debugging setup, how to use the plugin, or where to go next then you shouldn’t be playing with it.

In fact, I feel that is a good point.

If you don’t know what this plugin could be useful for, don’t understand what an SQL query, global variable, or memory dump is from PHP then DO NOT INSTALL THIS.    For one thing it could be used to exploit your site if you do not lock this down.   In fact I’d not put this on a live site unless I was having serious site problems I could not sort out on my staging/development server (you DO have a staging site for your mission critical business site, right?).

OK, so you’ve got the plugin.  but do NOT make that the only thing you do.  You need to feed that thing AND you should be using the built-in debugging resources you’ve got built into the core WordPress product…. setup your environment for debugging.  Again, only in a development or staging system.

Turning WordPress Debugging “Full On”

Go to this WordPress page on debugging.  Read it.   The do this:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY',false);
@ini_set('display_errors',0);
define('SCRIPT_DEBUG',true);

If you cannot figure out where to put these elements in the wp-config file then you should stop now. Do not play with this unless you know what you are doing. If you have a clue then you are going to make your WordPress debugging and research a LOT easier. I cannot believe I did not know about this sooner… but at least I know about it now.

Ok, Got It… Now What?

Now you can start using the Debug Bar and the micro-system of associated add-on packs to gain more insight into your WordPress installation.  By default the plugin shows you some basic site metrics that can be useful such as your server name, current PHP version, current MySQL version, and how much RAM is being used by the WordPress process for the page you are viewing at the time.   You can also get the Object Cache hits (and misses) on any page.   On a page that is processing request variables? It will show that plus any matching rewrite rules from your permalink structure.  Nice things to know.

Here is a default view on my dev box on a basic Store Locator Plus page.    I see that the initial page rendering “hit” adds about 2MB to the memory footprint.  I’ve been playing with reducing the memory footprint of the wpCSL framework I use to help render pages, so I’ll be very interested if the swap in the code logic reduces the memory.  This one piece of information saves me a lot of extra code debugging inserts and keeps my code lighter.  Already worth the 5 minute install and configuration of Debug Bar.

debug bar default output on page request

debug bar default output on page request

Tags: , , ,

Comments are closed.