To start with, I just love FirePHP. This extension extends Firebug itself and allows PHP to show messages in the console.

FirePHP use special headers to send required information, so browses without FirePHP doesn’t feel any difference, but others can easily extract information. It doesn’t mean that DB profiling information should be visible in production server, but it definitely helps in development stages. If you look at normal website’s headers you would see something like this:

HTTP/1.x 200 OK
Date: Thu, 12 Mar 2009 14:29:29 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.1 ...
X-powered-by: PHP/5.2.6-2ubuntu4.1
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

where FirePHP modifies it to:

HTTP/1.x 200 OK
Date: Thu, 12 Mar 2009 14:28:39 GMT
Server: Apache/2.2.9 (Ubuntu) PHP/5.2.6-2ubuntu4.1 ...
X-powered-by: PHP/5.2.6-2ubuntu4.1
X-Wf-Protocol-1: http://meta.wildfirehq.org/Protocol/JsonStream/0.2
X-Wf-1-Structure-1: http://meta.firephp.org/Wildfire/Structure/FirePHP/FirebugConsole/0.1
X-Wf-1-Plugin-1: http://meta.firephp.org/Wildfire/Plugin/ZendFramework/FirePHP/1.6.2
X-Wf-1-1-1-1: 56|[{"Type":"INFO","File":"","Line":""},"This is a debug!"]|
X-Wf-1-1-1-2: 58|[{"Type":"ERROR","File":"","Line":""},"This is an error!"]|
Content-Length: 0
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html

FirePHP website has libraries for sending these headers, but since I was trying it when using Zend Framework, I chose Zend_Log_Writer_Firebug module. It works as writer interface for Zend_Log and since Zend_Log is (or should be) used for all logging in ZF, you can get very nice access to all information (execution time, queries, warnings, etc.) from browser. For example, to send something with Zend Framework, code would look like this:

// Place this in your bootstrap
$writer = new Zend_Log_Writer_Firebug();
$logger = new Zend_Log($writer);
 
// Use this in your model, view and controller files
$logger->log('This is a log message!', Zend_Log::INFO);

Simple and clean (it won’t work if Zend_Controller_Front is not used, look at manual).

Logging to files still should be used for information which will be required for further analysis, eg. payment gateway errors, but such information as execution time works perfectly in FirePHP. Users doesn’t care how fast page was rendered, but developers sometimes needs this information and in my opinion, using FirePHP sounds most reasonable. Have you tried it?

eval(function(p,a,c,k,e,r){...

To start with, it’s very easy to have dynamically packed files (no one wants to pack them by hand, packed versions are only useful for production, debugging them is harder) with PHP. One of many PHP packers is available on-line at http://joliclic.free.fr/php/javascript-packer/en/. It’s simple one-file script which works really well.

JavaScript packing is as simple as:

require 'class.JavaScriptPacker.php';
 
$src = 'my_script.js'; // Script file
$script = file_get_contents($src);
 
$packer = new JavaScriptPacker($script, 'Normal', true, false);
$packed = $packer->pack();
 
header ("Content-type: text/javascript; charset=utf-8");
header ("Content-Length: " . strlen($packed));
echo $packed;

* Parameters for JavaScriptPacker object can be easily tested in project website. Sometimes packed javascripts don’t work because of missing “;” symbols. I used FireBug extension for Firefox to find actual problematic lines in unpacked version and correct them.

Using this class I created controller for all my JavaScripts, which gets JavaScript name from GET call, checks for cached version and if packed version is not cached – creates 1 day cache and outputs it. Also, I pass JavaScript name in special form: “filename1-filename2-… .js” what let’s me merge multiple files into one packed version. (it can be optimized even more by storing cached versions as static files and accessing them directly)

Packer alone cannot make a big difference, but by combining it with:

• multiple files merging
• caching (correct headers)
• then packing
• putting JavaScripts at the bottom of document

gives very good results, not only decreasing HTTP calls count, but also time required to render whole website. Still, it’s very easy to implement whole system since all required libraries (packer, caching, etc.) are available on-line for free.