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 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.
<script src="http://www.sitepoint.com/adjs.php?region=136&did=adz&adtype=vertical" type="text/javascript">
![]()
![]()
