While debuggers exists, there isn’t much of a tradition for using them in PHP. People have largely come to rely on injecting debugging code directly into the program, for inspecting program scope. The infamous var_dump have served for this purpose and version 4.3.0 of PHP brought us another equally useful function — debug_backtrace.

Tracers and error handlers

Both of these functions produce a rather crude output though, so naturally people have written wrappers around them to remedy this. I think Harry’s pretty bluescreen was one of the first dedicated libraries I’ve seen. Xdebug spouts a similar output on error, although arguably not as pretty. Or blue.

What bluescreen is for debug_backtrace, krumo is for var_dump. Recently, FirePHP — building on Firebug — does a similar thing. FirePHP uses HTTP-headers to send data from server to client, which turns out to be very handy when dealing with non-HTML output (Eg. Ajax stuff). Because it builds on Firebug, it only works on Firefox, and in particular only on Firefox 2 (Another reason for Ubuntu-users to downgrade from Firefox 3).

Frameworks

Apart for these general general tracing tools, a couple of frameworks have their own, more or less specific, tools. Symfony’s Debug Toolbar is probably the most impressive (And in contrast, Zend Framework the least), even providing information about database-queries, which is very helpful for profiling.

Another framework-specific tool, which I’m quite impressed by, is the Drupal Theme developer module. It’s advertised as “Firebug for Drupal theming”, which is fairly descriptive. In case you haven’t used Drupal, it has a complex theming system for rendering pages and this tool makes it a lot easier to figure out which part is doing what. Even if you don’t intend on using Drupal, it’s fascinating to see how well polished it looks.

I think that most frameworks with an integrated presentation layer, could benefit hugely from something similar, although the specifics would obviously vary. One of my own projects, Konstrukt, has a tool for displaying debug-information about which controllers renders in which order. This can be helpful, because a given page will often have several controllers working in concert to produce the final response.

Another take on this, is Cake PHP’s debug messages. This extension adds very specific and descriptive error messages in various places, which almost works out like a tutorial for new users; Seems like a good idea.

Webgrind

I already mentioned Xdebug, which is indispensable for profiling PHP applications. Last week, Webgrind had its first released. It’s a HTML-based frontend for displaying profiling output, generated by Xdebug. There are already tools for the purpose; If you’re on Windows, WinCacheGrind and for Linux-based systems, kCacheGrind. However, I can see a few good cases for Webgrind;

First of all, a zero-install client is a bit easier to reach out for. For Mac users, it’s also the only option. The featureset is quite limited, but this turns out to be somewhat a benefit. kCacheGrind can be quite intimidating and for the purpose of profiling, Webgrind’s features seems fairly adequate.
The most important though, is that the logfile generated by Xdebug (Which is the data-format for the various grind’s) tend to get rather huge. Naturally, this makes it awkward to have server and client on separate machines — This is not a problem for Webgrind, since it runs at the server side.

Troels has been crafting web applications, as a freelancer and while employed by companies of various sizes, since around the time of the IT-bubble burst. Nowadays, he's working on backend systems for a Danish ISP. In his spare time, he develops and maintains Konstrukt, a web application framework for PHP, and is the organizer of a monthly PHP-meetup in Copenhagen.

Get your free chapter of Level Up Your Web Apps with Go

Get a free chapter of Level Up Your Web Apps with Go, plus updates and exclusive offers from SitePoint.


  • dylanmcd

    This entry coincided with me searching for a good debug exception handler (which led to me finding PrettyBlueScreen).

    In the past for pretty debugging I’ve used DBug from http://dbug.ospinto.com, and before that the PEAR Var_Dump package with custom styles. I’m looking forward to trying out Krumo, although I’m a bit put off by the ini configuration and external css files (debug packages should be as self contained as possible).

    Thanks for posting, Troels.

  • JM

    I’m running KCachegrind on Mac OS X 10.5 without any problems. Where did you get the information that it somehow depends on the Linux kernel?

    Yet another Tool is PHP_Debug (PEAR).

  • Insomn3ak

    It looks like the developer of FirePHP released the updated version on Monday that works with FF3.

  • kyberfabrikken

    @JM
    I don’t use a Mac, so I’m afraid I just took someone else’s word for it. Makes sense that you can run kCacheGrind though, since there are plenty of other KDE apps, that works just fine. That doesn’t change the thing that kCacheGrind is a tad bit verbose for the casual user. I always preferred WinCacheGrind over kCacheGrind, for that.

    Thanks for the pointer to PHP_Debug.

    @dylanmcd
    I hadn’t seen dbug before; I really like the visual rendering of data. Definitely some inspiration there.

    @Insomn3ak
    Which version of Firebug are you using it with? If I install FirePHP, Firebug stops working.

Related books & courses
Available now on SitePoint Premium

Preview for $1