The php[architect] site has posted a new tutorial from editor Oscar Merida showing you how to create an autoloader for a legacy codebase using one of three options.

If you’ve inherited a legacy code base, you may find it does not use an autoloader and has an idiosyncratic directory and file hierarchy for its Classes, Interfaces or Traits. Worse yet, it might not use name spaces consistently or at all. So you can’t use a posting on Twitter. [...] In this post, I’ll detail the three solutions I found: using Composer’s classmap autoloader, Symfony classmap generator (deprecated), or Zend Framework’s ClassFileLocator.

He then goes through each of the tools mentioned above and shows how to implement them to locate class files and auto-generate the autoloader files. They each have slightly different methods of getting the class files from the current code but they all end up with basically the same result: a classmap (set of relations between classes and the files they live in).

Alan Storm has a new post to his site that takes an in-depth look at Laravel's autoloader and how things have changed with the release of Laravel 5.

Last time we finished up our look at Laravel 4.2’s autoloader implementation. Like a lot of features in Laravel, (or any framework), once you pull out the microscope sharp edges begin to jut out everywhere. However, unlike many other framework teams, the Laravel core team is willing to make shifts in their platform and application architecture. If you’re familiar with the internals of Laravel 4, looking at the internals of Laravel 3 may be a little disorienting. Similarly, the recent release of Laravel 5 presents some new wrinkles at the system level.

In the post he compares some of the differences based off of things found in a previous look at Laravel 4.2's autoloading system. He lists out the autoloaders initialized during the autoloader phase, four of them, including the use of the PhpParser library and Composer-only autoloading. He also includes a section at the end about some other smaller autoloading changes in the Composer configuration in both the "autoload" and "autoload-dev" sections.

Matthew Setter has a new post to his Master Zend Framework site today with a recommendation on how you can use a classmap in your autoloader to reduce the time it takes "searching" for the files it needs.

Zend Framework 2′s been critiqued many times as being slow, at least slower than some of the other leading PHP frameworks. And to be fair, sometimes it’s true. But it doesn’t need to be and there are simple things you can do to improve performance of your applications. So this post will be the first in a multi-part series looking at ways in which you can improve the performance of your Zend Framework 2 application, with only a minimum of effort. Today, we’re looking at the 2 autoloaders which are available in Zend Framework 2; these being the StandardAutoloader and ClassMapAutoloader.

He briefly introduces the concept of autoloaders and the PSR-0 standard that helped to bring a more unified method for their handling. He then gets into examples of using each of the two autoloader types. The Standard version (a fallback if nothing else is set up) resolves things based on a file path and locating classes in the right namespaces. The ClassMap autoloader does this mapping ahead of time and matches a path to a namespace+class. He includes code snippets showing how to set each of them up and a few statistics (using Apache's ab tool) of the difference in performance.

Phil Sturgeon has a new post today looking at PHP-FIG and upcoming proposals the group currently has in progress. It also shares some of the problems with some of the current standards (including some amendments and replacements that need to happen).

I've managed to get myself involved in a lot of projects in and around the PHP community because I like to offer my advice, experience and time to trying to make things better. Recently, I've been putting in lots of time for bits around the PHP-FIG. Like it or not, tabs or spaces, PSR-2 or no, the PHP-FIG has had a huge impact on the PHP community and it's going to continue to do so. We have more PSR's in the works now that at any point before, and they're awesome ones.

He starts with a brief look at the next PSRs coming down the line: PSR-5 for PHPDocumentor standards, PSR-6 for a caching interface and PSR-7 with a standardized HTTP interface structure. He then gets into the problems around some of the current standards including the differences in autloading (PSR-0 vs PSR-4), the amendment process and a suggestion that PSR-2 (the coding standard) needs to be replaced.

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.

As is mentioned in this Reddit post, the PHP-FIG group has moved a new autoloader structure proposal into "Draft" status, making it past the initial proposal (Entrance Vote) level as PSR-4.

This new autoloader has been in the works for a while, and is meant to be a modern autoloader that reflects the changes in the PHP landscape since PSR-0 was originally put together. Yesterday it passed the Entrance Vote, which means its now a formally worked and supported by the FIG.

While PSR-0 is new to many, its been around for years - since before Composer was really a thing - and PEAR/SF1/ZF1 were the prominent sources of distributed code. Now that so many are building components with Composer and using PSR-0 (yay) it's about time a new standard took care of a few hangovers from the PEAR/Zend style.

The newly proposed autoloader gets rid of some of the allowances that PSR-0 included like proper namespace support (no more underscores) and a reduction in the required folder structure to make it work. The Composer project is also a part of these discussions and are on board with making these proposed changes in the project's autoload handling.

We'd love to get constructive feedback on PSR-4. Post stuff up here, on the mailing list, get in #phpfig on freenode, whatever, just get involved. That doesn't mean everything will be implemented, but there is more chance of the standard containing your feedback if you make it - so post something.

Robert Basic has a new post today about the autoloaders in Zend Framework 1.12 and how to use them to create a classmap for use in your application.

The latest, and last, release of the Zend Framework 1.x series is just around the corner as ZF 1.12.0RC1 was announced this week. As I still have projects running ZF1 I thought about giving the most interesting new feature (for me) a spin - the new autoloaders which are backported from ZF2. I decided using the classmap autoloader as the main autoloader, and the good ol' standard autoloader as the fallback autoloader.

He includes the changes to the Front Controller (index.php) to have it know about these new autoloaders and has a command that will go through your code any pull out any require_once statements out and let the autoloader handle it instead.

Stefan Koopmanschap has a quick new post to his blog with a handy tip for Composer and Cilex/Silex users when dealing with custom namespaces.

For a new proof of concept application I'm building, I need both a simple web interface as well as some commandline tools. I decided to use Silex for the web interface and Cilex for the CLI tools, and opted for using Composer for installing these dependencies into my project. I ran into some issues with the custom project libraries I was building for this application however. Registering my custom namespace into Silex and Cilex didn't result in the classes being loaded for some reason. Composer helped me out though.

His solution involves letting Composer be the default autoloader for the application via an "autoloader" configuration option in the "composer.json" (that can also take a classmap option if you're not PSR-0 compliant, see here).

In a new post to his blog Rob Allen introduces you to the autoloader that comes with the Zend Framework 2 and shows how to use it to load your own classes.

Autoloading is the process in PHP whereby the system attempts to load a class when it is first encountered (via new or via class_exists) if it hasn't already been loaded via a require or include. Autoload works by looking for a method called __autoload or walking through any method registered with spl_autoload_register. Zend Framework 2 provides the ZendLoaderAutoloader component for autoloading of Zend Framework and your own classes.

The PSR-0-standard tool allows you to load files, set up class mapping and allows for multiple autoloading methods to work side-by-side. He shows how to use the standard autoloading functionality to define paths to locate files (with prefixes and namespaces) in both a constructor-based setup and a more programatic approach. He also shows how to use the ClassMapAutoloader to load from a mapping of class name to class file. Wrapping it up, he shows how to combine the two methods into a single ZendLoaderAutoloaderFactory instance.

On the Liip blog today, there's a quick post about integrating Symfony2 and Magento, the popular PHP-based ecommerce platform.

So last week four developers sat together on a regular Hackday to see what’s needed to hook up Magento into Symfony. To make this short the outcome is a Magento bundle for Symfony2. When we met in the morning we weren’t even sure what exactly to try out but soon agreed on implementing a Symfony authentication which uses the Magento customer database.

The post talks about some of the issues they came across in their work - mainly a problem with incompatible autoloaders. There were also problems getting the logins to play nicely with each other and each product's session handling. You can find the current results from their hacking in this bundle posted to github.