composer / installers

A Multi-Framework Composer Library Installer

Dependency Management for PHP

Composer helps you declare, manage, and install dependencies of PHP projects.

See https://getcomposer.org/ for more information and documentation.

Installation / Usage

Download and install Composer by following the official instructions.

For usage, see the documentation.

Packages

Find public packages on Packagist.org.

For private package hosting take a look at Private Packagist.

Community

Follow @packagist or @seldaek on Twitter for announcements, or check the #composerphp hashtag.

For support, Stack Overflow offers a good collection of Composer related questions, or you can use the GitHub discussions.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project and its community you agree to abide by those terms.

Requirements

Latest Composer

PHP 7.2.5 or above for the latest version.

Composer 2.2 LTS (Long Term Support)

PHP versions 5.3.2 - 8.1 are still supported via the LTS releases of Composer (2.2.x). If you run the installer or the self-update command the appropriate Composer version for your PHP should be automatically selected.

Binary dependencies

• 7z (or 7zz)
• unzip (if 7z is missing)
• gzip
• tar
• unrar
• xz
• Git (git)
• Mercurial (hg)
• Fossil (fossil)
• Perforce (p4)
• Subversion (svn)

It's important to note that the need for these binary dependencies may vary depending on individual use cases. However, for most users, only 2 dependencies are essential for Composer: 7z (or 7zz or unzip), and git.

Authors

• Nils Adermann | GitHub | Twitter | [email protected] | naderman.de
• Jordi Boggiano | GitHub | Twitter | [email protected] | seld.be

See also the list of contributors who participated in this project.

Security Reports

Please send any sensitive issue to [email protected]. Thanks!

License

Composer is licensed under the MIT License - see the LICENSE file for details.

Acknowledgments

• This project's Solver started out as a PHP port of openSUSE's Libzypp satsolver.

installers's Issues

Add binary to get list of packages with their respective paths from command line

Hi,

I've used Composer + Installers for quite some time now. I am looking for a way to get the list of installed packages (including dependencies) with their respective installer paths.

I don't know if this is possible, but I was thinking something like this:

$ composer show --installed --path
composer/installers    /home/user/path/to/package    v1.0.12    A multi-framework Composer library installer 

If we can't use the core show binary then maybe something like this:

$ composer show-paths --installed
composer/installers    /home/user/path/to/package

Thank you

Type Compatibility Matrix

As a consumer, I would like to install libs from other frameworks. Currently if I install a lib from another framework, installers would use the install path from the package. Being a consumer, it should use the path of my framework. A consumer could override their own path for each package with #10 but I think it would be friendly to translate the path if a compatible one exists.

For example, I'm a CakePHP user that wants to use a Laravel library. The package type is laravel-library and my consumer type is cakephp-app. Installers could determine a laravel-library type when installed to a cakephp- should use the cakephp-vendor type instead.

This of course would be succeeded by the any consumer set install path and is dependent on the ability for installers to access the consumer's config file.

Add support for type:drupal-site

In our environment, each site directory will be a composer package. It would be nice if this would be supported by adding a "drupal-site" type which would place the package in question under sites/{$name}

Auto-Detect Drupal Single Site Install Path

Reference #42, #36 and #15. The Drupal types currently require the composer.json to be located in the sites/all folder to allow for multi-sites. It appears to be common to want to locate the composer.json in the root of a drupal app. So would be nice for the DrupalInstaller to detect whether it's in root of the app to prefix sites/all/ to the install path.

@RobLoach has done this in his DrupalInstaller. I think the detection stuff makes sense (and would love a PR or your copy permission Rob) but I would like to get #43 done first.

This would make it so core drupal modules and themes cannot be installed with composer/installers. Which is a good thing but just making it clear.

extend $locations

Hello, is there an easy way to extend these locations?

https://github.com/composer/installers/blob/master/src/Composer/Installers/CodeIgniterInstaller.php

I would like to add widget, shared-addon paths...

Thank you!

Drupal location needs love

https://github.com/shama/baton/blob/master/src/Baton/DrupalInstaller.php#L10
Just found this project and a quick heads up:

drupal expects for TYPE modules/themes/libraries to be in sites/all/TYPE/{name} by default, but sometimes (for a multi-site install), needs modules installed in, say, sites/example.com/TYPE/{name}

For now, even changing modules/{name} to sites/all/modules/[name] etc would be a huge improvement, as only core themes/modules should be placed in the directory that's specified now :)

Will look into submitting a pull request after work

Allows for custom name that is different from package name?

I'm not sure if this is related to #10, but I feel it is different.

Currently installers determine that the name for a package (for example, the name for a CakePHP plugin) to simply be $prettyName. I feel that that may not always be the best name for a package.

For example, I have a this Git repo: https://github.com/uzyn/cakephp-aws-datasources. Its name at composer.json is uzyn/cakephp-aws-datasources.
However, when it is installed as a CakePHP plugin, I would prefer it to be installed to Plugin/AwsDatasources instead of Plugin/CakephpAwsDatasources.

I could name my package uzyn/aws-datasources, but that would make it less obvious that it is a CakePHP-related package on both Packagist and GitHub.

Add extra to disable installers

Setting this extra would disable installers and install to the native vendor dir. Useful for users who have configured their framework to consume packages from the default dir (but the framework has not officially supported it).

Reference this topic: https://groups.google.com/forum/?fromgroups=#!topic/composer-dev/9JtvlkQ1DNE

Maybe installer-disable?

Bug triggered by simple name of package

If I create custom pacage from git for exaple. And give name like "name": "sfPhpunitPlugin" it throw nitice in Composer\Installers\BaseInstaller

If I give name like "name": "plugin/sfPhpunitPlugin" it works fine but you should display specific message or add support for simple name.

Joomla

How is the Joomla component envisioned to work? IE is this to install code into an existing Joomla website or for something else?

Primarily I ask because if it is for a Joomla website then there is some missing items: for Joomla Components there are typically 2 directories which contain component code. For example, for MyComponent
administrator/components/com_mycomponent
components/com_mycomponent

Configuration code goes under the admin root, end user code under the main root.

Not the end of the world and easily modified, I'm just curious to know how it is envisioned that this would be used?

Unable to install with Composer

Just did a composer self-update and I get the following exception:

[RuntimeException]
Plugin composer/installers is missing a require statement for a version of the composer-plugin-api package.

Composer version 242c58c789cb6505d12593b8258625e5f83bba0c

Possibility to prefix installation path

It would be very helpful if the installation path could be prefixed. The installation path can be overwritten via composer.json [extras -> installer-paths], but this has to be done for every package or package type.
A prefix of the install path would solve this issue. A possible use case of this feature is the following:
With the help of Webroot Composer Library Installer Wordpress could be installed in a subfolder like web. If we include a Wordpress-Plugin in the same composer.json without a declaration of 'installer-paths' the plugin will be installed at wp-content/plugins/{$name}/. The correct path would be web/wp-content/plugins/{$name}/.
With the support of prefix this could be solved easily.

{
    "extra": {
        "installer-paths-prefix": "web"
    }
}

This can be extended even further:

{
    "extra": {
        "installer-paths-prefix": {
          "package-folder": ["vendor/package"],
          "type-folder": ["type:wordpress-plugin"],
          "framework-folder": ["framework:wordpress"]
        }
    }
}

Let me know what you think about this proposal. I might find the time to do a PR.

Composer Installers "reserves" package types it specifically intends to never use

I built a WordPress Core installer to handle installing WordPress core as a package outside the vendor directory. It tries to use the wordpress-core package type, but it's running into issues when used together with the installers package because of how the BaseInstaller handles unrecognized types. It's already been established that core types are out of the scope of Installers (e.g. #77 ) and the correct approach is to build my own installer, but the current behavior of composer installers prevents me from using the package type that makes sense for my installer.

Installers should only concern itself with the types it supports and should get out of the way for all other types.

Create tag v1.0.7

The last release was 3 months ago.

Support for concrete5 has been added since: v1.0.6...master

how to have same library class file but packaged for multiple frameworks?

This is more of a question than an actual issue I found with composer installers.

Suppose I write my own utility class, say a NumberFormat class.

I want to be able to use it easily as a Symfony component AND a CakePHP plugin.

Of course, I can simply have two separate repositories and each composer.json would naturally have a different type.

But that would mean I have the same code written twice.

Is there a DRY way to expose same library class to multiple frameworks to install?

Consider new types for DrupalInstaller?

//cc @grayside @RobLoach

Just a meta-issue -- not really actionable yet. Just for your consideration:

Currently Baton supports module and theme types, but here are the types that Drush uses: http://drupalcode.org/project/drush.git/blob/HEAD:/docs/make.txt#l110

I know you probably don't want to get into the tedium of drupal-narnia, but there's a CLI tool called Drush that we use, and it has a make command that converts a file manifest into a working website layout.

Some people are thinking that Composer could someday be used to drive some parts of Drush (and Drush Make). I think the thought is that Baton might be able to help with some of that logic.

Just to give some context, that is :)

Prefix vendor-dir if defined in user's composer.json to paths

Ref #148.

Given the following composer.json:

{
    "repositories": [
        { "type": "git", "url": "https://github.com/Mihailoff/installer-test.git" }
    ],
    "require": {
        "mihailoff/installer-test": "0.1.0"
    },
    "config": {
        "vendor-dir": "custom"
    }
}

installer-test should be installed into custom/blocks/installer-test but currently it is installed into blocks/installer-test.

Actual Package Install Tests

Probably a good idea to pick or create actual packages to install, update and remove in the test suite. The current tests just double check the results but don't actually do any installing.

Lib without Packagist + composer/Installers dont work

My composer.json:

{
    "repositories":{
        "cakephp-unofficial":{
            "type": "cakephp-plugin",
            "package": {
                "name": "pronique/CakePHP-Sluggable-Behavior",
                "version": "1.0",
                "source": {
                    "url": "git://github.com/pronique/CakePHP-Sluggable-Behavior.git",
                    "type": "git",
                    "reference": "origin/master"
                }
            }
        }
    },
    "require": {
        "php": ">=5.3",
        "composer/installer": "*",
        "pronique/CakePHP-Sluggable-Behavior": "*"
    }
}

Then:

-> % composer install --dev
Repository type is not registered: cakephp-plugin

installer-paths bug

Not too sure if it's a bug, or there's something wrong in my config.

My root composer.json:

{
    "require": {
        "uzyn/cakephp-opauth": "dev-composer"
    },
    "minimum-stability": "dev"
}

composer.json for uzyn/cakephp-opauth under dev-composer branch included this:

    "extra": {
        "installer-paths": {
            "Plugin/Opauth/": ["uzyn/cakephp-opauth"]
        }
    }

After running composer install, package gets installed to Plugin/CakephpOpauth/ instead of the expected Plugin/Opauth/

Yii native support

Hi, can you please describe how Yii is natively supported?

I know it had support in 1.0.3 version, but this is not true with next version.

When I browse through issues #68, #71 and #75 i see it was removed finally.

So native suport means I have to manage it own way, right?

Thanks!

Custom Install Type (Like Names)

I was thinking about #178, and I realized that perhaps we're going about this all wrong.

What if Composer Installers recognized custom types? I understand that a package author is not allowed to do this, for good reason. But what if a consumer is allowed to?

We already have the ability to define Custom Install Names. Perhaps it's not too far of a leap for Composer Installers to accept Install Names of types that it does not recognize itself?

For instance, if I put this in the project's root composer.json file:

"extra": {
  "installer-paths": {
    "web/sites/{$name}/": ["type:drupal-site"]
  }
}

Composer Installers obviously wouldn't understand what to do with drupal-site.... but aren't I telling it what to do? I'm telling it to put it in web/sites/{$name}/.

Doing this would allow people to manage custom project types in a "safe" way (i.e they are not at the whim of the project author). It also prevents having to have to define what should or should not be included into Composer Installers. Actually, I could make a case for not having Composer Installers understand any types at all, but that's probably pushing it. :)

I think this would solve a lot of people's problem. Honestly, I tried this to see if it would work before I proposed #178. I think this would be the best solution for everyone.

Process installer type in declared repositories

Suppose there is such config

{
       "repositories": [
        {
            "type": "package",
            "package": {
                "name": "vendor/foo",
                "version": "2.6",
                // DEFINE INSTALLER TYPE //
                "type": "some-plugin",
                "require": {
                    "composer/installers": "~1.0"
                },
                // --- //
                "dist": {
                    "url": "http://download.org/package.zip",
                    "type": "zip"
                },
            }
        }
    ],
    "require": {
        "vendor/foo": "2.6"
    }
}

Expected result is to get installed vendor/foo as some-plugin.
Actual result is that it installs like ordinary package in vendor directory.
I have no access to given package and can't create composer.json there.

PHP Composer Library Installer did not install any plugin

I already posted a question here: http://stackoverflow.com/questions/16603879/php-composer-library-installer-did-not-install-any-plugin

Basically I want to ask did I miss something?

Missing a require statement for a version of the composer-plugin-api package.

[RuntimeException]
Plugin composer/installers is missing a require statement for a version of the composer-plugin-api package.

composer install on project does not create autoload files for subpackage

I made a WP plugin as a composer package and tried to use the autoloader functionality by composer. This all works well if I do a composer install in the plugin directory because the autoloader files are created and I can require vendor/autoload.php just fine in my main plugin file.

 "autoload": {
    "psr-4": {"ExamplePlugin\\": "src/"}
}

But when I put this plugin as a package in a project composer file the plugin ends up in: web/app/plugins/example-plugin because of the installer-paths. That's great. Works perfectly.

But the autoloading files were not generated because composer only generates it for the main composer.json which means the plugin will be broken because none of the internal classes will be loaded correctly.

I hope I explained it well.

Installer class in programmatic use

Hi,

i am playing around with Composer and trying to use it embedded in an WordPress environment. For me it makes not much sense to use the Installers as requirement in a WP Plugin package i also don't think some deployment directory path change for a package should result in a dependency requirement.

Anyway, i think there might be a problem in Installer.php

public function uninstall(InstalledRepositoryInterface $repo, PackageInterface $package)
    {
        $installPath = $this->getInstallPath($package);
        $this->io->write(sprintf('Deleting %s - %s', $installPath, $this->filesystem->removeDirectory($installPath) ? '<comment>deleted</comment>' : '<error>not deleted</error>'));
    }

In my setup the Installer is programmatically added to the InstallationManager. So i am not sure, if this will be reproducible in normal use, but behaviour now is, that after uninstalling a package it is still present in the local repo json, due to the missing line

$repo->removePackage($package);

Let me know if i can do something...
Best Regards

Adjust var replacements

In the composer config, values can use other config values like this:

"{$vendor-dir}/bin" for example is the value for bin-dir. It might be good to use the same pattern in the installers (i.e. add the $) for consistency.

Remove "default" from supported types

I don't see the need for a default subtype. Package authors should write full type explicitly.

How can I test a new installer locally

Hi,

I am trying to create a custom installer, following patches like puppet and roundcube as all I need is to copy certain directories to specific places in the application structure.

I made the changes and now I would like to test it before submitting the pull request but I don't know how.

I tried directly appling the changes to the Installers src directory after downloading and deleting my module's content but after "composer update" the code ends up inside the vendors directory again so I don't know if I did something wrong or that is not the way to test it.

Thanks for any help.

Automatically Determine Install Path

Most, if not all, install locations could be automatically discovered rather than hard coded into Baton.

Please define a tag on the current version

Hi,

Please define a tag on the current version.

Thanks :)

Folders of custom path are not created

Hi,

I am trying to install dependencies using either a recognized type or some pseudo type with the following definition :

{
  "extra" : {
    "installer-paths" : {
      "application/modules/{$vendor}/{$name}/": ["type:maell-module"]
    }
}

Unfortunately, it looks like the folders are not automatically created as should be expected and I end up with an UnexpectedValueException exception from RecursiveDirectoryIterator::__construct().

Am I doing something wrong ?

Add wordpress-core type

WP extensions are already finely supported by installers, but the situation with WP core itself is less smooth. If it is placed in root then it's not subject to Composer, however subdirectory installs (which only recently became supported for all cases) are and probably should be.

However typical subdirectory install for WP is not the same thing as for typical Composer library, because paths matter, are exposed in admin area URLs, etc. In a nutshell putting WordPress core into vendor directory would be atypical and possibly problematic (technically and/or to satisfy requirements of specific projects).

Currently working options:

1. Declare core to be of wordpress-plugin installer type and customize installer path for it to wordpress (or other desirable path with single level of nesting). Confusingly puts core into plugins directory, if path is not customized.
2. Declare core to be of fake wordpress-core type. More logically goes into vendor if path is not customized, but non-existent type feels like a hack, I am not sure won't stop working.

Proposal:

Add wordpress-core type with default wordpress path for valid subdirectory install by default without path customization.

Roll your own path feature

The "roll your own path" thing should really be removed from the package definition, and moved to the consumer side. I think something like this would make more sense:

{
    "extra": {
        "baton-paths": {
            "sites/example.org/modules/{name}": ["vendor/package", "vendor/package2"]
        }
    }
}

Although we could maybe just add that at the top level and add support for it in composer, that way people can define where they want their stuff installed, and the baton installers would respect this if present, otherwise fallback to default dir. I think it would fit well with the planned stuff for assets in composer/composer#524.

Are packages uninstalled, when dependency is removed?

Hi,
today I've noticed, that packages installed in custom way (via composer/installers) are not deleted after removing dependency in composer.json. Composer writes "Removing SOME/PACKAGE (VERSION)" but package is not deleted physically. For me, it is huge problem. My packages installed via installers have other dependencies (normal packages) and when their dependencies are deleted, then my package breaks whole webapp.

Add a generic `custom` or something type

One common request is to install packages in a custom dir. Now this package allows this for common patterns of various frameworks, that's cool. But I think if we had a custom type that just enabled composer-installers handling without however specifying any path, it would at least allow people to register their own weird packages as type:whatever and then in their app package specify the install paths with extra.installer-paths.

I think it would alleviate the need for small shops with weird old setups to create a custom installer just to drop files in another folder.

Remove YiiInstaller

I am sorry that I have to create this issue, but please remove the YiiInstaller from composer/installers.

As discussed on composer-dev and Yii issues there are no specifications for Yii 1.x applications how they have to be structured and the current installer might break existing composer-based Yii applications.

Drupal Site

In a Drupal Multi-Site environment. It would be really helpful if Composer Installers supported installing a Drupal Site. This would allow site administrators to manage each site in a different repository like davidbarratt/davidwbarratt. This would allow the admin to have each site separate from the Drupal install itself and use Composer to manage the sites across different environments (staging, dev, local, etc.).

It would also allow the site itself to define PHP/Drupal dependencies. (i.e. the site can list out all of the libraries, modules, themes, etc. that the site requires to operate). You could even use this in a single-site setup by just pointing the site to the "default" folder.

Not only would this be helpful to Drupal admins, it's a minimal change for Composer Installers.

Thanks!

Commit Dependencies in my Plugin Directory

This picks up from option 4 here:
https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md

i'm using the installer with CakePHP and therefore the packages will be within the Plugin folder.

i've tried to add the following to git ignore so that i can commit plugins to the master project (i know this is frowned upon by most of the composer community, but in my situation it is the best option):

Plugin/.git
Plugin/**/.git

But, alas, git still treats these as submodules and will not commit them to the master project.

Are plugin "submodules" being tracked within the installer somehow? I'm completely stumped...

Add repository WP plugins/themes/mu-plugins from GitHub

Hello everyone,

I am a little lost on how to add WP plugins/themes/mu-plugins hosted on GitHub as a new repository. My composer.json file defines repository this way:

{
  "type": "package",
  "package": {
    "name": "wpgrouse/grouse",
    "version": "0.1.0",
    "type": "wordpress-theme",
    "source": {
      "type": "svn",
      "url": "https://github.com/wpgrouse/grouse"
    },
    "require" : {
        "wordpress/wordpress": "3.9"
    }
  }
},

... which throws this exception: A repository of type "package" contains an invalid package definition [...] .

I suppose the problem lies within the souce block as documentation provides reference parameter which I don't quite understand.

Thanks in advance!

CakePHP Plugin install path

The install path of a CakePHP plugin is Plugin/$name, and this would be correct if the composer.json is located within the /app/ directory.

What if the composer.json is located one level up? The plugin will not be installed into app/Plugin/$name nor in plugins/$name.

Proposed fix:

• Check the location of the composer.json and install in Plugin/$name or app/Plugin/$name accordingly

Since app can be named something else, it's probably easier to install the plugin inside the application-wide plugins/$name directory instead.

Support For Symfony 2.0

Reference: https://twitter.com/seldaek/status/214995304792068096
Unfortunately my experience with Symfony is limited. I assumed it worked out of the box because of the vendor folder. Could someone point out the desired install paths for Symfony 2.0?

Native Extensions Installer

There was an initiative about a year ago to make composer able to compile and install native extensions (composer/composer#498), but I think its kind of dead at the moment.

I would really like this ability in composer (As it would work really well with travis-ci and presumably other CIs) but it seams the core team is unreceptive to the idea.

So I was wondering can composer/installers be used for such a task. I'm prepared to strike on my own and implement this, though I will not be able to test this under windows probably.

The question is "Is this actually possible under composer/installer (without windows support) or this is something that can only be implemented in the core? Does anyone have tips/suggestions for me?

Add extension- or plug-in mechanism to register new installer types

It would be nice to write additional (may be proprietary) installers, that can reuse the existing functionality of this project.
Wouldn't it be nice to add installers just by writing a new class that extends the BaseInstaller and defines the $locations array without the need to modify Composer\Installers\Installer::$supported types?

Allow per package installer-paths for unmanaged types (or add a special type)

There are times when it's necessary for a dependency to live outside of vendor/. For instance, projects such as WordPress want to live somewhere in the web/ folder.

A couple of requests to that order have occurred in the past, asking for wordpress-core or drupal-core or what not. As I understand it, they got closed owing to the fact that they're too localized, in the sense that only one package would ever use it. Which is fair enough.

The current options are to either write a custom installer to that order, or abuse composer/installers by making e.g. WordPress itself masquerade as a wordpress-plugin and configuring a custom installer-paths accordingly. The same for language files. This makes absolutely no sense...

Could we instead simply have composer/installers pick up the installer-paths directives for any package, including types it's not supposed to recognize?

Along the same lines, could we force it to recognize a type by merely encountering it in composer.json with an assorted installer-paths directive? This could be useful, for instance, in a scenario like:

{
  "name": "wordpress/core",
  "type": "wordpress-core",
… 
},
{
    "name": "wordpress/locale-fr
    "type": "wordpress-language",
…
},
…
"installer-paths": {
    "www/wp": [ "wordpress/core" ],
    "www/wp-content/language/{$name}": ["type:wordpress-language"]
}

If that is not an option, could we add a generic sounding type, e.g. web-package or custom-package or even custom that could be used by all of these projects?

Simplify BaseInstaller::templatePath() with eval()...

Please forgive this totally oddball question. I just stumbled upon the project today and reviewed the code. I occasionally know what I'm talking about. Occasionally.

In BaseInstaller::templatePath(), it seems like rather than reinventing the PHP parser with regex patterns, it might be simpler to execute eval() on the templated path. I know, I know, eval() == evil, but this usage is precisely what it's for. Consider:

if ( strpos($path, '{') === false ) return $path;

extract($vars);

return eval('return "' . $path . '";');

No looping necessary, just variable replacement via the interpreter, the way Rasmus intended. Could be shortened further with a ternary, but why confuse matters...? A nice comment on the line could go far to explain the voodoo.

I have braced for stones and tomatoes.

Stable version release

Are we able to have a stable version release soon due to https://groups.google.com/forum/#!topic/composer-dev/_g3ASeIFlrc/discussion ?

It's not very convenient to require user of an installer plugin to have "minimum-stability": "dev" all the time.

Thanks.

Using Composer/Composer Installers in CakePHP app

This is not an issue of Composer Installers per se. More to do with the use of Composer/Composer installers in a CakePHP app.

Elaboration below:

I am having some weird issues with git submodule update for a Plugin dependency with Jenkins @ CloudBees.

So I am switching some, if not, all my dependencies from git submodule to Composer.

I came across this repo called composer installers. https://github.com/composer/installers

I was wondering how to use this for both Plugin and Vendor dependencies.

I am not familiar with Composer and even after reading the docs, I am uncertain how to say, place this dependency specifically to Plugin/xxx

I know how to do this with git submodule add.

So how do I do the same but with Composer or better yet, Composer installers, please advise me.

To make things easier, I want to use 2 actual examples.

• https://github.com/milesj/Utility is to be placed inside my app/Plugin/Utility
• https://github.com/simkimsia/php-gd-simpleimage is to be placed inside my app/Vendor/SimpleImage

Missing Frameworks

More PHP frameworks that should be included (in no particular order):

• Magento 29a5ba9
• Yii 85e4442
• Solar/Aura See #24
• Zikula
• PPI c50ae51
• Agavi
• Chisimba
• ezPublish
• Phorum
• MicroMVC
• Kohana 59bb85073c92d77c07112188726546e3958d16d0
• TYPO3 a02480a
• FLOW3