Oh, var_dump()... Poor, pathetic, little vardump()... There was a time when you were my favorite little go-to for debugging. Once upon a time, you were the end all be all of problem solving tools; this would be during my idiot phase of life. Not anymore though; thanks to some god (or whatever) someone smarter than me (and apparently with more time on their hands) went and invented the Debug Toolbar.

In case you didn’t know, a Debug Toolbar (I don’t know if that’s the universal name for it but it makes sense to me) is a nifty little widget that allows for easy access to all sorts of info on your web program. Since I work primarily in php that’s what I’m going focus on; I’m sure they’re available in other languages. Like most things; Google is your friend on this.

Usually, a Debug Toolbar contains information on included files, any sessions and cookies available, the database calls with timers and a breakdown of memory usage and performance.

Debug Toolbars usually work by encapsulating different code blocks or functions around “timer” functions to record the time it took for a block to run. All the Debug Toolbars I’ve used also included a memory component; really helps to see where the spikes are. There’s also the database integration; it’s just good sense to know where the bottlenecks are in a project.

As I said in the intro var_dump() is a handy little tool for debugging issues in php scripts. It works pretty well for small scripts but, the thing is, on larger projects it just becomes unpractical. Not only is it limited to arrays and objects but you have to manually place the call in the code and depending on the issue, you can get a HUGE amount of data back in a horrible tangle of strings. Makes XML look good.

Instead, using a Debug Toolbar, you get a nicely formatted unobtrusive way to keep an eye on how your code is performing while creating it. Needless to say, these are handy little tools.

PHP_Debug

A little disclosure: My first experience with a debug toolbar was with a really early, think pre alpha, version of PHP_Debug. PHP_Debug, at that time, worked by displaying the debug information at the bottom of a page in a table. This was definitely a step up from using var_dump(), to be sure, but it was still a little painful to decipher. Clients would complain.

Then PHP_Debug pretty much innovated the Microsoft way and copied a feature from another application; Symfony. (I kid, I kid.)

Seriously though, PHP_Debug does claim inspiration from the Symfony which I think is pretty classy of them; it seems too many times credit goes unsaid.

Keep in mind, this was the first time I saw anything like a debug toolbar. I don’t want to break down to hyperbole but to say the sky parted and angels sang would be a fucking understatement.

PHP_Debug is perfect for those stand alone projects that are started from scratch. It’s not impossible to integrate PHP_Debug into an existing program, I’ve done it a few times, but unless you’ve abstracted out a good deal of the logic it’s going to be a little painful. Put aside a few hours if you’re going to attempt it.

The script displays the output in 2 different ways; through a floating div at the top of a page or as an HTML table displayed at the bottom of the page. Installation is pretty easy and straightforward, either as a PEAR module or as a stand alone script.

ZFDebug

ZFDebug is a plugin for the Zend Framework that acts pretty much like PHP_Debug except with a simple and easy integration into the Zend Framework and it’s quite a bit slicker. Smooth animations, version details, sticky states and full of detail. If you use the Zend Framework I can’t recommend it highly enough.

There are some installation instructions which at the time of this writing are just broken though. Follow the linked instructions but use the below code in place of the code provided in the instructions:

protected function _initZFDebug()
{
    $autoloader = Zend_Loader_Autoloader::getInstance();
    $autoloader->registerNamespace('ZFDebug');
 
    $options = array(
        'plugins' => array('Variables',
                           'File' => array('base_path' => '/path/to/project/'),
                           'Memory',
                           'Time',
                           'Registry',
                           'Exception')
    );
 
    # Instantiate the database adapter and setup the plugin.
    # Alternatively just add the plugin like above and rely on the autodiscovery feature.
    if ($this->hasPluginResource('db')) {
        $this->bootstrap('db');
        $db = $this->getPluginResource('db')->getDbAdapter();
        $options = $db;
    }
 
    # Setup the cache plugin
    if ($this->hasPluginResource('cache')) {
        $this->bootstrap('cache');
        $cache = $this->getPluginResource('cache')->getDbAdapter();
        $options = $cache->getBackend();
    }
 
    $debug = new ZFDebug_Controller_Plugin_Debug($options);
 
    $this->bootstrap('frontController');
    $frontController = $this->getResource('frontController');
    $frontController->registerPlugin($debug);
}

Using ZFDebug is as simple as that. Once installed you’ll have a div laying at the bottom of the page with all the details you could want. Plus, it comes preinstalled with the hooks for database and cache profiling. It’s still possible to manually insert timing blocks but the hard part is already done for you.

Symfony

If you’re using Symfony you’re in luck (and none of this is probably news to you); Symfony comes with a Debug Toolbar (the original maybe?) preinstalled and read to use. All you have to do is either hit up frontend_dev.php in a browser or change:

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'prod', false);

to

$configuration = ProjectConfiguration::getApplicationConfiguration('frontend', 'dev', false);

in your bootstrap file.

It’s not as robust as PHP_Debug or ZFDebug out of the box (oddly, there’s no included file reference) but it does allow for customization so it has the potential to be very informative and useful.

One last thing about Web Debug Toolbars; they aren’t a replacement for good practices. You can’t rely on them too much and sometimes your instinct will contradict the output of the toolbar. In my experience you should trust that instinct. A Web Debug Toolbar should only be used to provide insight not replace common sense. 

One thing to keep in mind is to not focus too much on the