FirePHP: Firebug for PHP

Firebug is da bomb for debugging your web front end. Instead of just being able to look at the page source as it was delivered from the server, it lets you see the modified page after Javascript has run it through the ringer, it breaks things down heirarchically to help you focus, and it even lets you edit a page locally.

Now you can do the same to serverside PHP with FirePHP, a Firefox/Firebug add on. Note: You have to have Firebug to use FirePHP. I’m guessing FirePHP piggybacks onto some of its presentation structure.

Let’s see how I make out with this: Well installing the FirePHP extension was the same snap extensions usually are. You merely go to firebug.org and click the buttons and restart Firefox. As for using it? In addition to the extension you have to have a serverside library. And it seems that many frameworks have wrappers for this library, but I’ll just use the basic one. I installed mine using PEAR and poof there it is in the pear directory. uh… yeah… the OTHER PEAR directory. Damn Leopard and it’s sloppy lack of tying together loose ends!!! Is that other PEAR directory (the one Leopard defaults to) on the include path that PHP actually uses? Of course not. OK…. it is now. That’s a Leopard thing, not a FirePHP thing.

I proceeded according to the Firebug Learn page. In every piece of documentation, there’s something they fail to tell you and I think in this case is that you need to enable each domain on which you use FirePHP. I assume most would be localhost bogus domains or staging servers. You’re hardly going to want this in production. Other than not seeing the blue bug beside the normal orange firebug, once I enabled everything the example worked as shown.

On to the serious documentation. Yea, only one page long, but a fairly meaty page. I see how the land lays.

The make or break is how seamless this is. It looks like you can either remove all the logging statements before deploying on a production server, (bletch!) or just disable FB logging. You could do it in a config variable but you have still crufted up your code with all these logging statements.

FirePHP has a lot of nice features such as grouping, but honestly my code isn’t usually buggy enough to spend all that time setting it up to fail with such panache.

Bottom line: FirePHP has overhead, is not transparent for deployment, and requires me to remember one more thing. My first choice is the dynamic Zend Debugger that I have installed in Eclipse. All I do to use that is set up the situation I want to debug, put breakpoints in strategic places, and let it rip. My frameworks also allow lots of logging, so my second choice is to look at the runtime logs. My third choice would be just the old fashioned tossing a var_dump into the code to see what’s going on, fix it, and take the var_dump out. I can do that faster than I can look up the options I need to set in yet another add-on.

Anyway, that’s my take after playing with it for 30 minutes. I’m happy to be convinced I’m wrong. Perhaps Ajax is where FirePHP will really blow the other tools out of the water. Var_dumping kinda breaks Ajax so it is out, and we’ll have to slug it out between logs, FB, and ZDbg. Given that logs can sometimes be dicey for asynchronous stuff I’ll let you know if I find that FirePHP has any advantages over the IDE Zend_Debugger method for Ajax.