Friday, April 10th, 2009

FirePHP: Tying together Firebug and PHP

Category: Debugging, Firefox, PHP

<p>

FirePHP solves the problem of AJAX debugging by sending debug information along with the response. To avoid breaking the response content, the debug information is placed into special HTTP response headers. This works for all types of requests, not just AJAX requests, which means you can even debug requests for images that are dynamically generated by a PHP script. You can use FirePHP in your development environment, or use it to track down bugs that only appear on your production site.

This is what Christoph Dorn has to say about FirePHP in his recent writeup.

He goes into detail on how you can setup the Firebug plugin, and how you use it from within PHP:

  1. // use an ini file to turn it on and off
  2. $settings = @parse_ini_file('settings.ini');
  3.  
  4. if ($settings['FirePHP'] == 'Enabled') {
  5.   FB::setEnabled(true);
  6. } else {
  7.   FB::setEnabled(false);
  8. }
  9.  
  10. // log away!
  11. FB::log('This is a log message');
  12.  
  13. // selectively log
  14. if (Debug::getOption('DisableCache')) {
  15.   // code to disable cache
  16.   FB::info('Cache has been disabled!');
  17. } else {
  18.   // default code
  19. }

Check out the article for more info.

In related news, Zend just stepped it up a notch with their new Zend Server that fits in nicely with the cloud.

Posted by Dion Almaer at 4:28 am
3 Comments

++++-
4.9 rating from 22 votes

3 Comments »

Comments feed TrackBack URI

There are also libraries for non-PHP languages, including server-side JS:

http://www.firephp.org/Wiki/
http://nlsmith.com/projects/console

It’s a great program. It would be nice to have Mozilla and other browser vendors adopt wildfire or a similar standard to allow this sort of thing everywhere.

Comment by smith — April 10, 2009

YOU’RE ONLY FINDING OUT ABOUT THIS NOW? :O

Its uses are limited though – any AJAX application without a proper error metadata system (which can be used for debugging) isn’t very well coded.

Comment by Darkimmortal — April 10, 2009

I can see it’s use for some developers, but seems to me like using a Claw Hammer to remove a screw, a bit OTT. Errors should *never* be output with a response, even in the development phase – if you forget to hide them when you release you run the very real risk of exposing your code secrets and vulnerabilities.

I say use http://php.net/set_error_handler to update logs in a protected area you can view online, and throw yourself an email to boot (for future errors)

Comment by oopstudios — April 13, 2009

Leave a comment

You must be logged in to post a comment.