If you’re a web developer and you’ve never used Firebug then you really should give it a go – it can transform your work-flow. If you’re a PHP developer and you have used Firebug you should really give FirePHP a go too.
FirePHP is an extension to the Firebug Firefox plug-in. I won’t go into the details of Firebug here as there is plenty of other information around the internet and it doesn’t really need much discussion as to why you should use it. FirePHP on the other hand is a tool that I had never quite appreciated and did not understand its purpose over a debugger or simple echo or print_r statements. Once I started trying to debug Ajax applications it all became clear.
FirePHP allows you to log output to Firebug from PHP. This means that you can send a message from your server-side PHP script and have it appear alongside your JavaScript console messages. What’s the point I hear you say? Well, FirePHP does not receive data from the HTTP body (what you normally see in your browser) but instead uses custom HTTP headers to embed the information that is sent. What this means is that any data sent to FirePHP does not interfere at all with what is sent in the content of the page. This is particularly useful for debugging Ajax applications where any debug statements or extra output can completely corrupt a JSON or XML structure sent from the server. It is also useful for standard web page debugging as well where debug messages may affect the layout or behaviour of the page being loaded. Don’t take my word for it however, to really appreciate it you have to give it a go.
Since I do most of my development at the moment with the Zend Framework I will utilise the classes required to easily log messages to FirePHP using the framework’s logging classes. It is not really a problem if you don’t use Zend Framework for your application as the library’s loosely coupled design allows you to easily use the components that you need without worrying about the rest of the framework.
If you are using the front controller component from the Zend Framework then you need to set the following up before the front controller is dispatched, otherwise you just need to set it up before the headers are sent.
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);
Yes, that’s it! This is a very simple case and I normally provide some extra logic and utility functions to allow easy access:
// Check whether logging is enabled in the config
if($config->logging == 'true') {
$writer = new Zend_Log_Writer_Firebug();
}
else {
$writer = new Zend_Log_Writer_Null();
}
$logger = new Zend_Log($writer);
My_Debug::setLogger($logger);This checks a config file to see whether logging is enabled; if not it uses the null logger which writes to no output. This is useful when switching to a production environment as it disables all logging output in one go. I also give an instance of the logger to a debug component. This is a simple class with a single static function called log. All this means is that I can call My_Debug::log() anywhere in my code and get it logged to Firebug and it’s just as easy as echo or print_r. The debug class is shown below. The log method just acts as a proxy to the Zend_Log function by the same name.
class My_Debug extends Zend_Debug {
private static $_logger;
public static function setLogger(Zend_Log $logger) {
self::$_logger = $logger;
}
public static function log($message, $priority = Zend_Log::INFO) {
if(isset(self::$_logger)) {
self::$_logger->log($message, $priority);
}
}
}More information on this setup can be found in the relevant section of the Zend Framework User Guide.