PHP project structure survey

I like Kohana (Which is Kohana based), but think it should be /core. Less typing.

For the love of sanity, I would not use PHP Namespace scheme. Over the time it has been introduced, the more I think it was a bad idea. More typing and more chances of collisions. A decent directory structure and decent auto loader will go a long way.

USE \Mylib\Xyz,
\Monkey\Xyz as MonkeyXyz;

$xyz = new Xyz();
$mxyz = new MonkeyXyz();

Proper directory structure and autoloader:
$xyz = new mylib_xyz();
$mxyz = new monkey_xyz();

/$0.02

"users should install their own 3rd party dependencies in /vendor as well. I... really don't think that's a good idea. :-)"

It's common practice (see GNU/Linux for example) and it's only normal way, because otherwise you will need to store all dependencies in your repository and check each minute, if one of them was not updated.

composer dependency manager an sf2 boundels(self contained apps) seems to me the best tools available, becouse relying on an automation tool and not only on conventions ensure better consinstency

I realise it's part of the PSR-0 spec, but "vendor" implies something has been sold. How does that sit with free, open-source software? Or do these terms not have to relate precisely to English definitions?

Larry asked me to create a comment on this blog post.

PPI Framework
http://www.ppi.io

PPI is a web application framework that's fully namespaced, PSR-0 compliant and running on PHP5.3+

It's code base is built upon libraries such as Symfony2 and Doctrine2, so by default it has great Vendor support.

The framework is in PPI/ folder
The tests are in the PPI/Test/ folder
The vendor libraries are in the Vendor/ folder.

The skeleton application glues all this together in a very simple and accessible manner.

Thanks,
- Paul

The vendor dir is configurable with Composer. Just add this to your composer.json:

Also, if the vendor package you are installing defines and bin scripts, you can customize where those are installed

You can configure where composer stores libraries it installs by default:

See https://github.com/composer/composer/blob/master/README.md

We don't recommend changing it, to keep things familiar across projects, but it is possible. Custom installers allow you to install some types of packages in a different location than others, if that is desired.

Furthermore composer does not only generate an autoloader but also a namespace map (a simple array). So if you want to use your own autoloader you can still use that array to get all the information about namespaces and directories installed by composer.

Since composer is meant for third party code only, any directory format for your own code (src/, lib/, tests/ etc.) works fine with composer. You can actually add any such directory to composer's automatically generated autoloader rather easily as well.

PEAR2 uses src/ for own code, nothing for 3rd party code (since it's only self-contained components) and tests/ for unit tests

I believe you misunderstood the way Symfony2 is handled. The Symfony2 github repository only contains the "library" code, and that sits in src/ as you pointed out. However, when you want to create a Symfony project, you use https://github.com/symfony/symfony-standard or other "distribution". Those distributions are what is really more comparable to Drupal or most other frameworks. It is the application shell in which you put your code (in src/), and it contains the Symfony library in vendor/ as well as all other third-party code.

As far as your application is concerned, Symfony is an implementation detail, not your code, there is no reason it should be treated differently than other vendors. That is also why Composer puts everything in vendor/, because you should ideally never have to worry about this stuff and go dig into it.

The Aura project provides independent library packages for PHP 5.4+. Aura is not a new one, but the second major rewrite of the Solar PHP Project by Paul M Jones ( The father of PHP Framework Bench Marks https://github.com/pmjones/php-framework-benchmarks ) .
The Aura packages can be used standalone, in concert with each other, or combined into a full-stack framework of their own.
The Aura project also includes a system that composes the independent packages into a full-stack framework. All the Aura packages resides in /package folder .
All the packages are unit tested and aims for 100 % code coverage, it has its own tests folder . Aura follows the psr-0 standard and all the source resides in the src folder with the psr-0 standard.
Currently the third party libraries can be kept in the include folder of the system. As all are using the term vendor I have asked @pmjones to look whether we need a change in the name, so the community has a common name for libraries outside it.

Project own-namespace external-namespace 3rd party tests
Aura /src /include /include /tests

Source Code : https://github.com/auraphp
Website : http://auraphp.github.com/
IRC : #auraphp
Groups : https://groups.google.com/forum/#!forum/auraphp
Version : Beta 1.0

Try Onion, which is PEAR-compatible bundler (builder), pretty simple to use. :-)

Check here:

https://github.com/c9s/Onion

Caveat: I'm project lead for Zend Framework.

It's entirely clear from reading your analysis of ZF2's project structure that you:

• Did not look at any of the ZF2 RFCs (which are clearly linked from http://framework.zend.com/zf2, which is in turn linked from our github repository)
• Did not ask on any ZF mailing lists
• Did not talk to any ZF2 contributors

I'll clarify the structure for you, but I have to wonder how well you evaluated other projects, and which projects had folks you were already collaborating with. If you're going to do any sort of honest evaluation, you should definitely state where you're getting your information, and also definitely state how you tried to get in contact with developers from the project -- this ensures an open and transparent process, but also serves as good information to the developers of projects, as they then know how others try and reach out to them, and whether or not they ultimately succeeded.

Also, editorial comments about the relative sizes of projects should be kept to a minimum -- size of a library -- be it small or large -- should not be the consideration. What they offer you and your project is what is of interest here.

Now, as for ZF2 structure...

Suggested project structure is as follows:

config/
    autoload/
data/
    cache/
module/
    (modules -- more below)
vendor/
    (3rd-party code -- more below)
public/
    css/
    js/
    images/

Third party code should go under the "vendor" directory. There are no assumptions made about how code in that directory is installed, and the assumption instead is that you will instantiate appropriate autoloaders in your bootstrap to load this code. In terms of the Zend Framework 2 distribution itself, you would install it as you would any other 3rd party library -- and thus under vendor/.

Modules are the bits and pieces you assemble to create your application. These may be anything -- library code, public assets, or MVC code. MVC code will always be delivered via modules. Our recommended module directory structure looks like this:

{ModuleName}/
    Module.php
    config/
    src/
        {ModuleName}/
            {source code files, often MVC code ...}
        {OtherNamespace}/
            {source code files ...}
    test/
    public/
        css/
        images/
        js/
    view/
        {view source files here, typically PHP ...}

The "Module.php" should contain a class named "Module" under the {ModuleName} namespace. The ZF2 module manager will consume this to expose the module to the application. However, there is nothing saying that a module must contain MVC code or be specific to the ZF2 MVC layer; this is simply another way to distribute code.

Typically PHP source code, under {ModuleName}/src/, should follow PSR-0 naming conventions, allowing you to use a PSR-0-compliant autoloader. (We actually also recommend shipping a classmap file and/or a file containing a callback for use with spl_autoload_register() to make the module easy to consume in non-ZF2 applications.)

As such, 3rd-party modules will be located under vendor/, while the modules you write specifically for your application will be under module/.

The "modules" directory you found in the ZF2 distribution is a set of code we've removed from the core ZF library and which we intend to distribute as stand-alone ZF2 modules. One of which, the ZendFramework1Mvc module, contains the previous ZF MVC implementation, which we've removed from core in order not to confuse new developers, but retained as a module to provide a potential migration path for developers of ZF1 applications. This module follows the same conventions for modules that I outliend above.

The amount of attention devoted to this is ridiculous. And pressuring a diverse project structure as that of Drupal into a PEAR scheme will of course incur some drama. Is that really worth the buzzword compliance?

Why not use an automap-based autoloader? That's most independent from the discrepancies in directory structures. It might need some professional coding to get progressive updates for directory scans, but the autoloading lookup itself is heaps speedier than with any sort-of rigid directory traversal scheme.

PHP Frameworks (and tools like composer) are not the only thing using a vendor directory. For example, Ruby on Rails uses a vendor directory as a place for 3rd party code. Using the vendor directory is fairly common and if Drupal continues to deviate from that it would be an exception. Cake, Symfony2, Silex, ZF2, and Rails are all examples here using the vendor directory. Is there a good reason not to use the vendor top level directory name? Ya know, aside from how we handle things (modules/themes) where one version could be in profiles, sites/all, or sites/foo and this would deviate from that pattern (which I'm ok with).

Something to think about with these frameworks is that the entire project isn't always supposed to live within your sites web root. For example, with symfony2 you will often point the web root at the web directory inside a symfony2 install. The src directory is not web accessible. Distinctions like this are important to understand when making our naming conventions.