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 a tutorial posted to the Cullit.com site Philip Brown shows you how to create a PSR-4 compliant package that can be installed quickly and easily through Composer. The PSR-4 standard is a part of the set of standards defined by the PHP Framework Interoperability Group (PHP-FIG) to help make it easier to work with libraries and tools across frameworks and platforms. The PSR-4 standard replaces the slightly more complex PSR-0 to define a pattern for autoloading files.

A couple of weeks ago I wrote a tutorial on the general principles behind building PHP packages. In that article I mentioned the PSR-4 standard for creating PHP packages. In this tutorial I’m going to walk you through setting up the structure of a PHP package. By having an agreed upon structure for PHP packages we make our code a lot more interchangeable and reusable for the greater Open Source community.

He starts with the basics, creating a simple "nacho" directory in a git repository and introducing Composer (and the composer.json) briefly. He also talks about the "dotfiles" that are included with the use of Composer including a sample Travis-CI configuration. He then gets into the code and shows how to use namespaces, relate them to the directory names for autoloading and even writing a simple test or two. From there he talks about documentation and, finally, pushing the package up to GitHub and adding it to Packagist for others to download.

On the Acquia blog Adam Weingarten has shared some tips for writing good (and modern) object-oriented code in PHP:

Recently I began working on a D8 module, but this isn't a story about a D8 module. The work I did provided me an opportunity to get back to my pre-Drupal object oriented (OO) roots. Writing OO code in PHP presented some curve balls I wasn’t prepared for. Here are some of the issues I encountered:

His tips touch on things like:

• Using a code structure that can be autoloaded via PSR-4
• Namespacing your classes
• Working with types and type hinting
• Using docblock comments for autocomplete in IDEs

There's also a few other quick topics he finishes the post out with: the lack of enums in PHP, working with associative arrays, no functional overloading and assigning responsibility to classes.

Paul Jones has posted an article to his site with another helpful hint to modernize your legacy PHP application. In the post he looks at updating serialized object handling with the help of the class_alias function.

Several weeks ago, a correspondent presented a legacy situation that I’ve never had to deal with. He was working his way through Modernizing Legacy Applications in PHP, and realized the codebase was storing serialized PHP objects in a database. He couldn’t refactor the class names without seriously breaking the application. [...] Before I was able to reply, my correspondent ended up changing the serialization strategy to use JSON, which was a rather large change. It ended up well, but it turns out there is a less intrusive solution: class_alias().

He talks about how this function could be useful to prevent the need for updating the class name in every serialized instance by setting up an alias to the new name. You can even use namespacing in the alias that will let the autoloader work with the PSR-0/PSR-4 handling to correctly load the class. With this in place, you can then refactor to the new version of the class without worry of breakage.

In his latest post Phil Sturgeon makes a request of the PHP community - to "send PSR-0 to to Standards Farm in the Sky". Or, to put it another way, deprecate it in favor of the more recent autoloader handling of PSR-4.

This article attempts to convince you that deprecating the PSR-0 auto-loading standard in favor of the PSR-4 auto-loading standard is not only a good idea, but a problemless wonderland of happy benefits, in the hope that when I try to get this done on the FIG mailing list, people will be happy about it instead of sad or rage-mode. [...] I believe it was talked about as an alternative at the time because we knew that the PHP community would drop their collective bricks if we tried to pull PSR-0 out from under them, right as they were just slowly getting used to using it.

He covers a few different topics and his opinions on each including the "hate" for PSR-0 (for wanting to get rid of it) and why it should even be considered for deprecation in the first place. He also reminds readers that he's advocating the deprecation of PSR-0, not the removal of it as a standard. It can still exist and be used but it will no longer be the "moving forward" method of autoloading (in favor of PSR-4). He also comments on the large user base out there on PHP <=5.2 that wouldn't be able to make the update to PSR-4 and a suggestion to projects wanting to encourage the migration.

On his site today Phil Sturgeon has a new post showing how to use autoloading with Laravel based on the recently approved PSR-4 standard.

The video shows you how to move over from the current autoloading methods, PSR-0, for your own packages, not Laravel's. He walks you through the creation of the typical PSR-0 package structure and classes then shows it in use in a simple controller.

The font's a bit small on the screencast, but it gets the idea across. Migrating over to the new autoloading is relatively easy, it just takes a little tweaking on the current structure.

As Phil Sturgeon notes in a recent post to his site, the Composer, the popular PHP package management tool, now supports the PSR-4 autoloading standard as defined by the PHP-FIG.

PSR-4 was voted in as an "accepted" PSR by the FIG in December. It took a little while to get done and went through a series of painful rewrites but when we have in the end is a document that reflects what this truly is: an improvement on PSR-0.

Today Jordi Boggiano merged a pull request by Andreas Hennings into master branch of Composer that contained support for PSR-4. Andreas was a massive help to the FIG while we were trying to shake the issues out of PSR-4 during Draft and Review stages, so he really outdone himself by providing the code too.

Phil makes a few suggestions about moving to PSR-4 including: not moving immediately, making a "psr4" branch to test it out and points to an example of how to do it. More information on PSR-4 and Composer can be found in the official documentation.

As Paul Jones mentions in his latest post, one of the latest proposals to the PHP-FIG (Framework Interoperability Group) has officially passed, PSR-4, providing a more strict standard for autoloading than the widely used PSR-0.

Counting from the date of that first formal proposal, it has taken exactly 8 months of discussions, one botched vote, one rescinded vote, an entirely new FIG workflow, and four or five rewrites to get PSR-4 passed. Maybe 8 months doesn’t sound so long when you look back on it, but while you’re in the middle of it, it’s interminable.

Paul talks about some of the differences between it and PSR-0, making for "shallower" and more concise directory structures for packages. He also points to some of the packages from the Aura framework as examples of its implementation.

The SitePoint PHP blog has a new post from editor Bruno Skvorc about a PSR standard (from the PHP-FIG group) that's proposing and update and slight change to the currently wide-practiced autoloading standard (PSR-0). This new standard, PSR-4, proposes a modification to the PSR-0 spec with a bit more strict guidelines.

If you've gone past the beginner stage in your PHP training, you've heard of PSR-0 – an autoloading standard that defines ways to automatically include PHP classes in your code without having to use statements like require and include. [...] When Composer showed up and took the PHP package management world by storm, things changed. Due to some of its rules, folders often duplicated and became too deep when looking at PSR-0 class installations via Composer. [...] Therefore, some highly qualified PHP devs got together and put together a suggestion for a new standard: PSR-4.

The goal behind PSR-4 is to define a new autoloading standard that removes allowances for things like the underscaore as a "namespacing" tool. Bruno makes some suggestions for the structure of your tools if you're going to go with PSR-4 and the handling of multiple autoloaders/paths in the same namespace.

The PHP Town Hall podcast has released their latest episode today - Episode 15, "The Joomla Framework and the Ongoing History of PSR-4". This time they've made both the audio and the video available (it was recorded live via Google Hangout).

The wonderfully handsome Don Gilbert joins us on our new YouTube Channel for our first live-recording of PHP Town Hall! He's been working on the Joomla Framework to get it up to scratch with modern standards ready for a Joomla CMS rewrite, much in the same way that EllisLab pulled CodeIgniter out of ExpressionEngine...except for the standards bit, because they didn't exist and PHP developers were too busy clubbing each other to death over tabs v spaces.

You can listen to this latest podcast in a few different ways - either watching the video from YouTube, downloading the mp3 directly or you can use the in-page players for either. If you like the podcast, be sure to subscribe to their feed too.