Rob Allen has a new post to his site showing how you can customize the Whoops output in a Zend Expressive application. Whoops is a package that provides more well-structured and more attractive error output when an issue comes up.

I find the Whoops error handler page in Expressive quite hard to read and particularly dislike that the error message displayed in the top left is hidden if it's more than a few words long.

To fix this, I discovered that you can provide a custom CSS file to the PrettyPrintHandler and then override to your heart's content! One way to do this is to add a delegator factory to add the additional functionality, so let's do that.

He then includes the configuration changes you'll need to make in the Expressive setup to have it recognize the factory and be able to use it as a dependency. He then includes the code to create the factory itself, adding a path to the local CSS files and pushing the custom whoops.css file into the page handler. Example CSS is included showing an update to the display of the main message, removing the need for a mouseover to view it.

The Master Zend Framework site has posted a new tutorial for those out there looking for a bit more from their error handler than just some basic text. In this tutorial Matthew Setter introduces you to the Whoops error handler and how to use it in your Zend Expression application.

Ever experienced HTTP 500’s, but found that your error logs are empty. Ever had no clue why or how this could be happening? Perhaps you forgot to enable the Whoops error handler.

That’s right, perhaps, when you were setting up a Zend Expressive application, you made the mistake which I made recently when you used the Zend Expressive Skeleton Installer. [...] If you chose n, and used a templating engine, then TemplatedErrorHandler, would have been used as PHP's default exception handler.

As a result, no exceptions will be written in your logs. Sure, you’ll see that a 500 error has occurred somewhere in your application. But, the only information you’ll have is [a simple 500 error message].

He notes that the next step for most developers is the log files, trying to find a hint there of what might have broken. If you chose the default logger, nothing will be there as it captures those issues and pushes them to the basic error template (but doesn't output them). He points to where in the configuration you can check to see if you enabled the Whoops error handler and how to test it after you've made the switch. The reason the default is the basic message is that, in production, you don't want information exposed and log messages/code shown to just anyone - that's a big security risk.

On NetTuts.com there's a new post spotlighting an interesting tool you can use to help make debugging an easier (and prettier) experience in PHP, the Whoops library.

Whoops is a small library, available as a Composer package, that helps you handle errors and exceptions across your PHP projects. Out of the box, you get a sleek, intuitive and informative error page each time something goes pants-up in your application.

It provides you with detailed error messages, a "code view" of where the error was found, support for Ajax/JSON requests and providers for several popular frameworks. The system is made up of a set of handlers that execute in order to provide the resulting page of output. He goes through how to install the tool (via Composer) and what you'll need to know to put it to use. He shows how to change up some of the configuration options and add in some extra info to the output. There's also a section specifically about integrating it with the Laravel 4 framework.