Till Klampaeckel has a very quick post about a problem he was coming across when using PHP as a CGI on the nginx web server. It was throwing errors ("client prematurely closed connection...") with no evident cause.

The issue was a PHP parse error which I overlooked when I added a new file. The weird thing is, I had nothing in the logs (E_ALL, display_errors is off, but all logs are enabled and I tailed them using multitail) and nginx only displayed a blank page. The errors above were in nginx's own log file.

The multitail command lets you run the "tail" command on more than one file at a time and view them split out in your console for easier reference. The full error message reads:

client closed prematurely connection, so upstream connection is closed too while sending request to upstream, client: a.a.a.a, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/tmp/.fastcgi.till/socket:", host: "localhost"

If you've been using the Zend Framework on a Windows platform (running IIS as the web server) and have been getting some 500 errors and have been left lacking the detail you need on the problem, you should read this new post from Rob Allen about an IIS setting that can help you out.

One of the dangers of frameworks in general is that you forget that they do lots of handy things for you. [...] The error handler in ZF will catch any exceptions and route them to the error action in the error controller. This then sets the correct HTTP response code, logs the error and optionally displays it if a config setting is set.

IIS shows you some default error pages when something goes wrong, but sometimes you might need a bit more information. Rob points you to the "Edit Error Pages Settings" panel in the IIS setup and which setting to change it to for development versus production environments.

bOn the SitePoint PHP blog today there's a new post showing you how to debug applications with FirePHP (an extension of the popular Fireug extension for Firefox).

By combining this extension, which sits on top of Firebug, with a server-side library, your PHP scripts will be able to send debugging information to the browser, handily encoded in the HTTP response headers. Once you're set up, you can log warnings and errors in your PHP scripts to the Firebug console, just as if you were developing JavaScript.

Once you've installed the extension and grabbed the FirePHP library, you can follow along with their example showing the push of a simple message - in this case array values - out to your browser and into the Fireug panel.

On the WeblogTools Collection blog today there's a new post from Ronald Huereca with a tip about manually turning off and on your WordPress plugins if you get into a bind and need more than the web-based interface can do.

There may be times in WordPress where you would like to load the WordPress environment manually, and prevent plugins from loading. [...] To further give justification for this technique, I had a major plugin conflict with another plugin. My Ajax Edit Comments plugin had failed to work for one of my clients. After doing some troubleshooting, I determined it was a plugin conflict with "xyz" plugin.

He admits that the technique is a "hack" but can be quite useful in the right situations. The process involves changing your wp-settings file to define the "WP_INSTALLING" constant then the plugins can be manually loaded as needed instead of automatically. This can help narrow down where an issue is (sometimes) faster than enabling/disabling them and guessing.

Davey Shafik has a quick tip for anyone trying to use Xdebug from the command line and finding themselves having issues.

Thanks to some help from Derick and my co-worker Trevor, I now have a simple bash script that will let me and my team easily debug CLI scripts on our development server.

The script is two lines (really just one) that uses a combination of environment variables, PHP's command line binary and a few other standard unix commands to parse the output of the request. The script can be made executable and dropped into a place in your path to make it as simple as running "xdebug file.php" on the file.

On the Geekzguru.net site there's a guide posted (from June 13th) about how to get PDT and Flash Builder to let you debug both sides of your application (the Flex side and PHP side) at the same time.

This setup allows you to edit and debug you PHP files along with your flex application in the same instance of eclipse. All features of PDT like PHP code coloring, auto complete will be available in addition to the wonderful features that Flash Builder 4 provides.

They walk you through the installation of the Eclipse PDT software, the XDebug module for debugging your PHP and how to modify your Flex project's files to modify the .project file's XML with a new linked resource.

Paul Reinheimer came across a small bug in a recent PHP 5.2.x release of the language - a debugging message left in by mistake.

If you get an error when PHP launches along the lines of: "PHP Warning: PHP Startup: mm_create(0, /var/www/phpSessionStorage/session_mm_cli1000) failed, err mm:core: failed to open semaphore file (Permission denied) in Unknown on line 0" you're going to either need to upgrade to PHP 5.3.0 or wait for PHP 5.2.12.

It seems that some debugging code made it into the core code (but it's been corrected in the branches).

In his most recent post Stuart Herbert has a suggestion that can make your development life simpler and make debugging less of a headache down the road - isolation.

If you know the code well, perhaps you can make an intuitive leap to immediately jump to where the bug is. But how do you go about tracking down a bug when intuition doesn't help? The nature of all code is that larger systems are built from smaller underlying systems and components. [...] Apart from being a strategy that allows you to work on code you've never seen before, this approach also has the advantage that it is evidence-based.

He suggests the division of your application down into the base level of components, sets of "logical points" that make it both simpler to test and more modular for the future. He gives an example of tracking down a bug in a system like this and notes that, with a good set of tests, it can be much faster than some of the other, more traditional debugging methods.

On the Think Vitamin blog Kieran Masterson has put together an article about debugging PHP applications - everything from error levels out to a few useful tools that can help with some of the more complex issues.

Nobody enjoys the process of debugging their code. If you want to build killer web apps though, it's vital that you understand the process thoroughly. This article breaks down the fundamentals of debugging in PHP, helps you understand PHP's error messages and introduces you to some useful tools to help make the process a little less painful.

He looks at changing the display_errors setting, updating the error_reporting level, the types of errors (notice, warning, etc) and the Xdebug and FirePHP tools.

On the Symfony blog there's a new post following up on the previous article about the FireSymfony debugging plugin. Previously, they introduced the tool - this time they look at the actual installation and configuration.

In the previous post we went through the features provided by FireSymfony. In this post we are going to see how to install the Firefox Add On and the symfony plugin.

Installing the Symfony plugin is simple - a standard plugin:install command and a bit of tweaking on the factories.yml file to add it to the logging settings. The FireFox extension installs like normal - grab it from here and install like any other extension.