After php|tek 2009, a number of PHP Frameworks developers launched a new initiative: PHP-FIG, the PHP Frameworks Interoperability Group. The idea is to  have projects representative members in the PHPFIG talk about the commonalities between different projects and find ways to collaborate all together.

Membership and group Governance

The group evolved from 5 to 37 current members who joined the PHPFIG group from different Frameworks projects and other related projects such as CakePHP, Zend Framework, Symfony, Drupal, Laravel, Yii Framework, Solar Framework,… etc.

It’s probably the key element that make this initiative works compared to other initiatives, because it is based on active members from active projects in the PHP world. The  governance of the group is quite simple, there are voting members and simple voting rules. Finally current members vote on new membership requests, and that’s how the  groupe members can grow.

Current PSRs

Since that time the PHPFIG released ten PHP Standard Recommendations (PSRs), they are actually 5 accepted, one under review and 4 drafts. Below the list of current PSRs :

Status Num Title
Accepted PSR-0 Autoloading Standard
Accepted PSR-1 Basic Coding Standard
Accepted PSR-2 Coding Style Guide
Accepted PSR-3 Logger Interface
Accepted PSR-4 Autoloading Standard
Draft PSR-5 PHPDoc Standard
Review PSR-6 Caching Interface
Draft PSR-7 HTTP Message Interface
Draft PSR-8 Huggable Interface
Draft PSR-9 Security Disclosure

Thoughts & Case Studies

Now who is using these PSRs by the way, since even voting members does not have to comply to the standards. CakePHP will release soon version 3.0, and in the latest release it fully adopted PSR-2, the coding style guide recommendation which will make you see the source code in a format that you are familiar with. We’ll be back soon on CakePHP with more details once the 3.0 will be ready for prime time.

PHP Magazine Network asked Matthew Weier O’Phinney, Zend Framework Lead, about PSR-7 and why do PHP frameworks need it :

“PSR-7 is specifying a set of interfaces related to and describing HTTP messages. PHP has always followed the Common Gateway Interface specification with additions; $_SERVER represents what CGI would be passing a script, while the other superglobals are syntactic sugar to make getting at the various input elements (such as query string parameters, POST parameters, cookies, etc.) simpler.

[pull_quote_right]Superglobals are nice, except they make testing harder[/pull_quote_right]Superglobals are nice, except they make testing harder, and do not cover the full set of use cases we have today, which include APIs that use non-form-encoded payloads and/or non-POST methods; encrypted cookies; path-based routing; etc.

A more convenient abstraction than superglobals, and one that is easier to test, is to model the HTTP messages themselves. Frameworks have been doing this for a decade or more, but each framework does it differently. This means developers write framework-specific solutions to common problems, and this leads to duplication of effort.

[pull_quote_left] by providing HTTP message abstractions, we can simplify using PHP as an HTTP client itself. [/pull_quote_left]By providing a set of HTTP message interfaces, PSR-7 sets the stage for frameworks to be a thin layer around the messages, allowing developers to create framework-agnostic solutions, as well as to compose solutions that may have originated elsewhere.

Additionally, by providing HTTP message abstractions, we can simplify using PHP as an HTTP client itself. Developers will work with the request and response messages — which client implementations can now share. This means that HTTP clients can focus on the hard stuff — working with proxies, automating authentication details, setting up and executing asynchronous requests, etc.”

And when asked about how PSRs are contributing to the maturity of PHP frameworks and PHP applications in general, Matthew told us :

[pull_quote_right]tools like Composer largely exists because of the very first PSR[/pull_quote_right]”The Framework Interop Group was formed to allow framework developers to identify the problems that are common across all implementations so that they can stop duplicating effort and focus on the real work of creating differentiated application architectures. Some frameworks want to focus on performance, others on usability, and others on flexibility. In the end, low-level details such as logging, HTTP messages, caching, and more are largely boring, busy work that does not really need many different implementations.

With tools like Composer (which largely exists because of the very first PSR, which defined a common mechanism for autoloading!) making pulling dependencies into your applications trivial, it makes sense to create things like shared interfaces that frameworks can depend on, and discrete, standalone implementations that consumers can pull into their applications. This allows developers to focus on smaller, discrete projects (those implementing the interfaces), and on the specific features that differentiate their frameworks. In the end, it’s a win for the entire ecosystem. ”

More information

PHP-FIG official Website
GitHub Repository
Twitter account
Articles by Matthew Weier O’Phinney PSR-7 By Example and On HTTP, Middleware, And PSR-7.