If you're new to PHP or are working to enhance your skills, chances are you've at least heard of the PHP-FIG and the several PSRs that it has released to help provide structure around common functionality. In this article from StarTutorial they walk you through some of the basics of the more widely adopted PSRs including PSR-0/PSR-4 and PSR-3/PSR-4.

Prior to PHP Standards Recommendation (PSR), there were no truly uniformed standards for writing PHP code. For instance, for coding style, some people preferred Zend Framework Coding Standard, and some liked PEAR Coding Standards, and still others chose to create their own naming conventions and coding style.

[...] At the time of this writing, there are six accepted PSRs: two of them are about autoloading, two of them are related to PHP coding style and the remaining are about interfaces. In this chapter, we will discuss each PSR briefly. The purpose of this chapter is to introduce you to the ideas of PSRs. For further details on each one, the respective link are provided.

The post then goes through each of the major PSRs, describing them and providing code examples where relevant:

• PSR-0 & PSR-4 for autoloading
• PSR-1 & PSR-2 for coding standards
• PSR-3 for logging interfaces
• PSR-7 for HTTP message stricture

The post finishes with links to each of the PSRs on the PHP-GIF site for more information.

In his latest post Stephan Hochdörfer shares a library he's created to hopefully make it easier for developers to integrate PSR-3 compatible logging libraries into their code, a "logging facade" based on an idea from the Java world.

Lately I have seen more and more libraries picking up PSR-3 when it comes to logging. What a lot of libaries do wrong is that they depend on a concrete implementation of PSR-3, e.g. Mongolog instead of relying on the PSR-3 interface. From what I have seen this is because loggers get instantiated directly within the class. This is not a bad thing but it couples your code to a concrete implementation of PSR-3 which in turn means that there`s no interoperability.

The Java community solved the problem by creating a Simple Logging Facade library (SLF4) which I "ported" to PHP last week.

The library makes provides a simple static interface to setting the PSR-3 logger of your choice and fetching it from anywhere in your application. He includes an example of what the code would look like for a basic Monolog instance. He ends the post talking about this method for getting/setting the logger instance and how it compares to using other options like a dependency injection container or even just a manual call to a setter.

The SitePoint PHP Blog has a new tutorial by Yones Rafie showing you how to log more effectively with Loggly, a remote log management service that's easy to connect to your PHP application. (Note: this post is sponsored by Loggly but it's still an interesting tool.)

When logging with PHP, we tend to use the error_log and trigger_error functions, or we can use an error handler to make the logging process more generic. [...] But what would you do if you had to log to multiple places at the same time, or you were sending logs to a given service depending on the error level? Rather than using built-in tools, it’s often easier to use logging libraries.

They go on to talk about logging using a PSR-3 compliant logger and show how to integrate the Loggly service with your application via one of the most popular options, Monolog. The integration is made even easier by the fact that Monolog already comes with a LogglyHandler built-in. The post includes the code you'll need to implement the logger, how to integrate it with a Laravel application, setting it up on Heroku and and a tour of the Loggly features for filtering, searching and examples of the graphs showing query results. Loggly is free to try out, so you can see if it will work for your application before making the commitment.

Gonzalo Ayuso as a new post today showing the results of some of his testing with the event dispatcher and Silex to send logs to a remote server.

Today I continue playing with event dispatcher and Silex. Now I want to send a detailed log of our Kernel events to a remote server. We can do it something similar with Monolog, but I want to implement one working example hacking a little bit the event dispatcher. Basically we’re going to create one Logger class (implementing PSR-3 of course).

He includes the sample code defining a "Logger" class that takes whatever message sent to it and pushes it into a given socket resource. He also creates a provider for the logger to implement it in the example and registers it with the event dispatcher. He hooks it into the request, get controller, terminate and exception events. On the other side he uses React to make a basic server to listen on port 4000 for the incoming log data.

On PHPMaster.com Patrick Mulvey has written up a new tutorial looking at using the PSR-3 logging structure to make a basic logger for your application.

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.

In this latest post to his site Chris Hartjes shares some of his thoughts about the recently approved PSR-3 standard (for logging) and some of the reception that the other PSRs (PSR-0, 1 & 2) have gotten from the PHP community.

For those who pay attention to the workings of the PHP community you might have heard about the “PHP Standards Recommendations” that have been coming out of the PHP Framwork Interop Group. [...] More recently this group has been working on a standard for logging interfaces called PSR-3. I spoke about this on Twitter, and I will repeat it here: I think PHP programmers should get behind PSR-0 and efforts like PSR-3. I feel that PSR-1 and PSR-2 are solutions looking for a problem and seem, to me anyway, to me out of place with the solutions offered by PSR-0 and PSR-3.

He likens the PHP PSRs to the Python enhancement proposals (PEPs) and, more specifically, to the PEP-8 - their own version of "coding standards" that was highly championed by Guido van Rossum and put into wide practice.

Any programming language community that does not work as hard as possible to make it easier to integrate other’s libraries of code together [by standardizing their formatting] is asking for irrelevancy.

With the PSR-3 logging interface recently accepted by the PHP-FIG, Jamie Munro has written up a post for PHPMaster.com that shows how to implement the interface with log4php, the Apache logging tool.

With the recent passage of PSR-3, a standard for a common interface for logging libraries, it seems appropriate to discuss the implementation with my favorite logging library. log4php is an open source Apache project that is a very versatile logging framework. Through log4php’s configuration files, logging has a variety of output locations, so it’s possible to send specific log levels to different output locations.

He includes the Composer requirements for the interface and shares the code for a wrapper class that implements the Logger interface and defines methods for each of the logging levels (alert, notice, debug, etc). Also in the post is an example XML configuration for log4php and how to load it into your class instance.

The PHP-FIG (Framework Interoperability Group) has recently accepted the PSR-3 definition for a standardized Logger interface structure that can be used for interoperability between frameworks (and other tools).

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.

In his latest post, Stuart Herbert has shared some thoughts about the recently proposed PSR-3 proposal for a unified logging interface for PHP projects.

PSR-3 is a proposed standard (voting has finished, it should appear as an accepted standard when the PSR folks recover from too much Christmas turkey) describing a common logging interface for PHP frameworks. It’s based on a small subsection of RFC 5424, which describes the Syslog standard, which is a very sensible choice. Sysadmins think in terms of Syslog levels, and they utterly hate dealing with loggers that don’t map cleanly onto Syslog.

He briefly introduces the PSR and the format of the logger with some of the main methods it should implement and what they do. He talk gets into some of his critiques about the proposal, namely the method naming, the exception handling parameter and the proposed LogLevel constants.