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.

The PHP-FIG group, the ones responsible for the standards that helped to make Composer a real possibility (PSR-0 and PSR-4) have posted a general update of the various PSRs that are currently in progress and a brief summary of the status on each.

Hello everyone, we (the secretaries) decided it was time to post a status update for the PSR which are pending, as a way to update you members and the whole community on our work, and also to start discussion around some PSR that need a little more participation.

Current PSRs in the list include:

• PSR-5: PHP docblock recommendations
• PSR-12: Coding style guidelines
• PSR-17: HTTP factories
• PST-19: Streams/Async processing

If you would like to participate in the working group for any of the items listed in the full post, reply to it and the group will get back with you shortly.

Michael Cullum has posted the October 2017 edition of what has been happening in the PHP-FIG group for the month over on Medium.com.

As part of the effort to communicate better what’s going on within the PHP FIG we’re starting a new series of ‘A month of PHP FIG’ articles to be released towards the end of each month, each being a 2 minute read or less.

Topics mentioned in this month's edition include:

• PSR-12 being formally re-introduced into the draft stage
• a start of the voting for the secretary elections for two secretary posts
• a discussion as to whether or not new PSRs should require PHP 7 or PHP 5 still
• an agreement that PSR-18 will not cater to async http client requests due to the lack of a Promise PSR standard

There were also several new PSR ideas proposed including ones for internationalization, cache tagging and deprecation handling. You can read the full post here

On the SitePoint PHP blog paul Jones has written up some of his own perspective on the PHP-FIG and the work that's currently being done by the group on restructuring to make the group more effective, learning from past issues.

In his article The Past, Present and Future of the PHP-FIG, Larry Garfield gives a whirlwind tour of his impressions of the FIG, from its founding to one of its possible futures. I encourage you to read it in its entirety before continuing.

Herein, I will attempt to address some of the errors and omissions in Larry’s article, and offer two other possible futures for the FIG.

He starts by talking about the largest change the group is working on - the PHP-FIG 3.0 proposal. He compares the vision of this effort to some of the founding goals and principles of the group as documented in various emails and posts from current (and past) members of the group. Paul also talks about the FIG 2.0 workflow, what PSRs were before/after it was introduced and some of the overall impact that these and other PSRs from the group have had on the wider community.

He wraps up the post with a look at two alternatives he's proposing for the group's consideration as a way forward and an alternative to the PHP-FIG v3: independent interop groups and disbanding the PHP-FIG all together.

On the SitePoint PHP blog Deji Akala has written up a post talking about the PHP-FIG - some if its history and its current role in the community.

The Polish writer, Henryk Sienkiewicz, was awarded the 1905 Nobel prize for Literature for his epic novel Quo Vadis, which is a Latin phrase meaning “Where are you going?”. In the face of any dilemma, a brief pause and redefinition of one’s goals may be therapeutic.

The PHP Framework Interoperability Group (PHP-FIG) has come of age. With the acceptance of more PHP Standards Recommendations (PSRs), PHP has attracted further positive attention and admiration of the programming community. PSRs governing coding standards, coding style guides, autoloading, logging, caching and HTTP messages have been accepted.

[...] However, the future isn’t as bright as painted, as a recent ruckus within the organization has thrown its continuing existence under doubt.

The post starts out with some of the origins of the group and how its organized and communicates (with a large part of it being the main mailing list). There's some mention of the successes that the group has had (like PSR-0/PSR-4 that allowed for easier creation of the Composer package manager) as well as some disputes that have risen recently about the goals of the group. the post wraps up with a look at other open source communities, the fact that people don't always "see eye-to-eye" and some of the author's own thoughts about the state of PHP-FIG and its future.

One note here: be sure to read the comments on the post - they help clear up a few misunderstandings in the article's contents and give a wider context to the group and its current state.

Phil Sturgeon has a new post to his site giving a brief overview of the state of the PHP-FIG, the v3.0 proposal that's been put out and sharing some of his own thoughts on both.

I was involved in the PHP-FIG since 2012, and I have seen every conversation, been part of every decision, and know the reasoning for a lot of stuff, regardless of the result and my person preferences. Being so involved with this group for so long, I have a fair bit of context that other people are lacking.

The latest of about four large conversations in the FIG is: whether or not a new organization should take its place. Seeing it framed in this way is odd, because I'm not sure anyone is literally proposing that.

Phil covers some of the background behind the PHP-FIG group including some of the original goals and how it grew well beyond the "framework" part of its name. He talks about some of the reasons he sees that the group has stayed around. Then he gets into the FIG v3.0 proposal - a relaunch of the group with a different structure and different way of getting things done (after learning from some of the mistakes in the current group). He also talks about the other elephant (elePHPant?) in the room: whether this new structure calls for a new group to be formed or if the PHP-FIG should just adapt and move on.

It will be interesting to see how this all shakes out in the end but the PHP-FIG group has, undoubtedly, helped to usher in a lot of the "modern PHP" work we see in the community now especially when it comes to things like Composer, logger structure and middleware handling.

With a lot of talk happening around the PSR-7 HTTP request/response proposal and PSR-4 being the last "official" standard to be posted, some people are wondering what happened to PSR-5 and 6. Phil Sturgeon, a previous member of the PHP-FIG, has posted some clarification to how the PSR process works and where those seemingly missing PSR numbers are at.

The last PSR from the FIG to be sent out into the world, to be used by whoever felt like using it, was PSR-4: Autoloader. Now people are starting to hear about PSR-7, and they’re starting to “lolphp”, wondering what has happened to PSR-5 and PSR-6. [...] This is not like The Neverending Muppet Debate of PHP 6 v PHP 7, despite it being the first though to pop into many peoples heads. Instead, this is down to the Workflow Bylaw I put into place last year.

He goes on to talk about the current workflow stages and how, unlike systems in other languages, the PHP-FIG's process gives proposals a PSR number even before they're published and accepted. He also briefly talks about PSR "nicknames", naming to differentiate between similar proposals and how, despite the need for these names, they're just reference points for conversations more than anything.

Peter Petermann has an interesting post he's added to his site describing a lesser known feature of the Composer package manager: virtual package support.

A few days ago i stumbled over a “virtual package” on packagist – and found it to be a feature that i was actually missing in composer. Turns out, composer can do it, its just not so well documented. So what is this about? Virtual packages allow you to have a more loose dependency. Rather than depending on a specific package, you depend on a virtual one, which can be fulfilled by all packages that provide the virtual one.

He includes a few examples to help illustrate the point of using virtual packages. The first describes an application that wants to use the PSR-4 logger structure but depends on "log-implementation" (a virtual package) rather than the "psr/log" package. The key is in using the "provide" keyword in the Composer configuration. His other two examples expand on this a bit, one showing the use of the "provide" keyword to define the relationship and the other of an actual application making use of this package.

In his latest post Pádraic Brady shares some of his thoughts around coding standards and the existence of tools to be sure the code is exactly formatted correctly.

The problem with coding standards is not the notion of following conventions to ensure all programmer can quickly read and understand code (and other good stuff), but that someone created a tool to actually check compliance: PHP_CodeSniffer. This isn’t a complaint about the operation of phpcs, but to complain about the mere fact of its existence. [...] Using the cover of such automated tools, we can make judgement calls about code quality, integrate style checks into Continuous Integration scoring schemes, complain about pull requests and patches, and generally impose a time penalty on writing code. There is a point at which common sense morphs into sheer nitpicking, and an automated tool is the perfect nitpicker.

In his opinion, coding standards should be "invisible and flexible" as well as easy to learn so the developers could learn and follow it quickly. He looks at these thoughts applied to the PSR standards and how adhering to them could quickly turn into something much more time consuming than it should. In his opinion a good coding standard is one that "limits the rules, eradicates ambiguity, formulates multiple use cases and avoids trivialities".

You may of heard about the PHP-FIG group but aren't quite sure what they're about or what they've produced so far. In this new post on PHPBuilder.com, they get into some of the details of the group, including descriptions of the currently released PSRs.

If you have been watching the development of PHP over the last few years, you will know all about the problems with the language. The standard story is that PHP is a fragmented language, it is a language for hacks, there is no real specification, and so on and so forth. The reality is that PHP has grown up a lot recently. PHP 5.4 brings the language closer to a complete object model, and supplies a lot of new functionality. So far, so good. But what about frameworks? [...] PHP-FIG is the short name for the PHP Framework Interop Group (am I the only one who finds the naming of PHP groups and libraries after fruits amusing?) and their mission is simple: to find a way to get the PHP frameworks to work together.

They cover some of the members of the group (well, the projects represented) and look at each of the PSRs in detail:

• PSR-0 - Autoloading Standard
• PSR-1 - Basic Coding Standard
• PSR-2 - Coding Style Guide
• PSR-3 - Logger Interface
• PSR-4 - Improved Autoloading