No matter how hard you try to test your PHP applications before putting them in production, you will always ship code to your server that has bugs. Some of those bugs will be very serious and need to be fixed before they cause greater damages to your application data that may be too hard to recover. Read this article to learn about a several good practices that you can apply to track bugs in production code, so you can fix them before it is too late.

Suggestions included in his list are things like:

• Test as Much as Possible Before in your Development Environment
• Separate your Code from Environment Configuration files
• Track PHP Errors with Assertion Condition Tests
• Send PHP Errors to an Error Log File
• Monitor the PHP Error Log File to Quickly Fix Serious Bugs
• Fix Your Bugs but Never Edit Code on the Production Server

He also includes a brief look at some things to think about when considering "defensive coding practices" and links to other articles with more information.

I recently had a problem with a ZF2 based website where users were reporting seeing the error page displayed, but I couldn't reproduce in testing. To find this problem I decided to log every exception to a file so I could then go back and work out what was happening. In a standard ZF2 application, the easiest way to do this is to add a listener to the 'dispatch.error' event and log using ZendLog.

He uses an event listener to attach a service that contains a "logException" method. This method uses the ZendLog component to write out the error message to a local log file including a backtrace of where the issue occurred.

Logging is one of the most ubiquitous tasks encountered in PHP. We use logs to track error messages, record important events, and debug problems with our code. In any PHP project, the code is likely to be full of calls to a logging library which handles these actions for us. [...] To promote compatibility between logging libraries, the PHP-FIG group recently released PRS-3, a common interface for logger objects. In this article, I'll discuss how the logger interface defined by PSR-3 allows us to write reusable code that isn't dependent on any particular logging implementation.

He includes a quick introduction to the PSR-3 format, how to get the files you'll need to use it (via Composer). He includes some sample code showing how to make the basic email class with a logger injected for use. Since the Monolog logging project follows the PSR-3 format, it's an easy drop-in option. He also talks about using PSR-3 to avoid having logger dependencies with the "LoggerInterface". There's also a bit at the end of the tutorial showing you how to use the Adapter design pattern to "proxy" the logging calls to the class via a PSR-3 interface.

The main goal is to allow libraries to receive a PsrLogLoggerInterface object and write logs to it in a simple and universal way. Frameworks and CMSs that have custom needs MAY extend the interface for their own purpose, but SHOULD remain compatible with this document. This ensures that the third-party libraries an application uses can write to the centralized application logs.

The implementation of this structure into your application makes it easier should you decide to swap out logging tools or want to create your own that can be used across several different frameworks. This is the third PSR to be accepted by the group, following PSR-1 and PSR-2 more related to coding standards.

Graylog stores them in a database and allows you to perform custom searches on them. You can also see in real time how many log messages are being received and processed. The real killer feature in Graylog is streams. A stream in Graylog is a predefined custom search. The server will display to you log messages that only match the stream criteria selected, graphing the results for you.

He mentions other features of the Graylog2 system including customized alerts, messaging via UDP/AMQP and how it uses MongoDb and ElasticSearch. He also introduces Monolog, a PHP tool that lets you log in multiple formats directly to the Graylog2 server. He includes an example of how it works with a sample "LoggingHelper" added as custom exception and error handlers.

Communication is the only way you can tell if an application is feeling well or is about to fall apart. If your application can't talk to you, you have no way of helping it to feel better. The L in LUCID is for logging. Logs are how applications speak. They capture information that allows us to pick up on those little signs and act early enough to make sure the application doesn't come down with the flu. If you don't have good logging throughout your system, the best you can do is react to your application falling over. A silent application is an application destined to cause midnight surprises for you and your operations team.

He talks about the difference between "just logging" and "correct logging" as well as a recommendation for the different levels: trace, debug, info, warn and error.

Letting you know that something went wrong is really only half of a log messages job. The other responsibilities of a log message are to allow you to accurately reproduce the conditions under which the event occurred, and to allow you to fix any data inconsistencies.

Once I realized what he was doing, I realized that the Strategy pattern was applicable in this case…but his chosen example was dumb and one that I wouldn't have used to demonstrate things. As expected, he told me to supply a sample of a better way. I did, telling him that the sample would be better if he didn't mash the logging level together with the message.

Included in the post is sample code, first showing the initial version of the logging class, complete with accompanying tests. Following that, he shows how to refactor it into something using the Strategy pattern, replacing the logging type switch statement with protected methods for each logging message type (critical, notice, etc).

MongoDB is an excellent fit for logging (and of course other things as well) for many reasons. For one, it is very VERY fast for writing data. It can perform writes asynchronously; your application wont hang because your logging routines are blocked. This allows you to centralize your logs which makes it easier to querying against them to find issues. Also, its query interface is easy to work with and is very flexible. You can query against any of the field names or perform aggregate functions either with map/reduce or MongoDB 2.2's upcoming aggregation framework.

This article will show how you can use existing code to add a logging library to your code and log errors to MongoDB. You'll also see how to query MongoDB from the command line and how to filter those queries to find the information you are interested in.

Analog makes it simple to log information in an easy to use, self-contained, extensible kind of way, offering writers for multiple output formats including: files, the FirePHP plugin output, email, POSTing to another machine and sending to a syslog daemon. She also mentions the different logging levels the tool makes available and how to filter down your logging results based on them (searched by "equal to", "greater than" and grouped by level).

The ability for a class to inherit from multiple parents is maligned by many, but can be a good thing in some situations. For those working in PHP, multiple inheritance has never been an option; classes are limited to one parent, though they can implement many other datatypes through the use of interfaces. Interfaces can lead to code duplication in improperly-factored inheritance hierarchies. Even in well-architected hierarchies, multiple classes that implement similar methods can contain a lot of overlap.

He starts with a definition of what traits are and where their real usefulness is (as well as what should be the difference between a class and a trait). He gives an example of a typical hierarchy where two classes extend a parent but then they both need the same functionality. Code duplication's not a possibility and inheritance make run into exposure issues. Traits come to the rescue by dropping in just the feature you need when you need it. His example code shows adding some logging to a simple class via a "Logging" trait and a "Singleton trait" example.

One of the 'traits' I find myself constantly adding to library files is optional logging of it's behaviour. The library class has it's own log method, that checks to see if the instance has had a logger injected and if so, logs the message. I see this as a perfect candidate for becoming a reusable trait, as I tend to have the same code copy/pasted throughout my library classes. The problem is, according to the rfc, traits aren't supposed to have state/properties, which makes it difficult to have a DI setter method in a trait.

He includes the code for his trait example (noting that it may or may not end up working correctly in the 5.4 final release) that sets a logger on a sample class and logs a few values out to the console. It's a simple example, but it shows you one of the most useful things about traits - the "drop in resuability" nature they allow in your libraries and classes.