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.

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 Stephan Hochdörfer shows you how to define Phing tasks according to the PSR-0 autoloading format. Phing is a PHP-based automation tool that uses an XML configuration to execute a series of tasks.

Before anybody complains: I know that "as of 2014-10-21 PSR-0 has been marked as deprecated. PSR-4 is now recommended as an alternative." - Anyway I still think this little gem makes sense to be shared because a lot of people are probably not aware of it. I recently found out by accident that it is possible pass a task name in PSR-0 style to the "taskdef" task. In the old days you had to use the Java-like dot-style notation like this and also define the classpath to make sure the class could be loaded correct! This is ok if the task resides in the same project. If the task is located in a dependent package loaded via Composer this can get ugly.

The post is quick but provides two very handy code examples, one showing the old "dot notation" version and the other showing how to make use of the autoloader. The trick is in the classname value and using the full namespace/class name rather than the dot notation.

That Podcast has released their latest episode today, hosted by Beau Simensen and Dave Marshall - Episode #8: The one where PSR-0 is dead ("because controversial titles bring all the hits").

Beau and Dave are back together for another chat, covering conference talks, shellshock, Linux (on floppies), PHP Jeopardy and the marketing machine that is Jeremy Mikola, PHP-FIG, learning about AngularJS with CodeSchool.com and working with the TV on.

Other topics included in the episode are things like Mockery spies, the PSR-7 draft and the mention of middlewares for Laravel 5 from Taylor Otwell on Twitter. You can listen to this latest episode either through the in-page audio player or by downloading the mp3. Don't forget, if you enjoy the show, be sure to subscribe to their feed to get the latest shows as they're released.

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.

Ben Ramsey has an interesting post to his site today looking at what he calls the Fall of PEAR and the rise of Composer when it comes to package management in the PHP community.

PEAR’s biggest selling-point -the curation of packages by a governed community - was also its biggest problem. There was no choice, and things moved slowly. If a package stagnated in development, I couldn’t find another actively supported one to solve the same need. In theory, the maintenance of the package could be taken over by someone else, but this didn’t always happen, and contributing patches was not clear or easy.

Ben talks about how, despite the PEAR development's best efforts, the proposed new package manager (Pyrus and PEAR2) couldn't keep up. Then, from a discussion had at a conference, the idea of a standards group was formed, the PHP-FIG, and the first standard soon followed, PSR-0 for autoloading. With this in hand and becoming widely adopted, a new tool was created to make it easier to share and install packages with this new standard - Composer.

Composer is what PEAR should have been. Through Packagist, Composer is the democratization of PHP userland libraries. Many libraries in the repository implement similar functionality, but through a show of popularity, the community self-selects the packages that are of the best quality. [...] In just a few short years, Composer has revitalized the PHP community and changed the way we do development.

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.

In this new post to his site, Cal Evans shares a handy tip for those using non-Composer libraries in a Composer-friendly project - using classmaps to bridge the gaps.

A problem I ran into when starting this project is that the official MailChimp API wrapper for PHP is NOT a Composer package. Thankfully, the wizards behind Composer have thought this through. To facilitate using non-Composer packages in composer projects, all I had to do is add one line to my "autoload" section of my project.

Using this "autoload" section, you can get Composer to add the path as a namespace to the class mapping. This lets it load them up in the same way i would any other PSR-0 formatted package. This will even work if you have libraries that aren't PSR-0 as it finds all of the files and pulls them into the map automatically.

Phil Sturgeon has a new post today that looks at the relationship between the PSR-0 standard (autoloading structure) and Composer - noting that they're friends, not relatives.

As a huge proponent of Composer, a happy user of PSR-0 and a voting member on the PHP-FIG I get into plenty of conversations about all of them and it worries me how much confusion there is in the community about these things not actually being related. [...] It seems that a lot of folks discover Composer and PSR-0 at the same time and seem to assume they are the same thing - especially since both Composer and PSR-0 have the idea of a "vendor" and a "package", but those two things are not related to each other either. These are a few points that I have wanted to clarify during some strange conversations over the last few weeks.

He goes on, trying to clear up some of the confusion around the idea of "vendors" and vendor names. He talks about naming schemes and how they may or may not be related to the vendor name on the package. He looks at the PSR-0 loading methods and how the structure of the library/repository effects that (noting that Composer can be made to accommodate something not PSR-0 by default). He suggests that PSR-0 needs to remain "implementation agnostic" and that Composer, at the same time, should remain "specification agnostic" .