If this were a feature project, how would you take a design-first approach with it? Also, given this original problem statement: When customers use Offload S3 along with another plugin that relies on and bundles the AWS SDK, unless that plugin is using v2, we encounter an issue of incompatible libraries. WordPress loads plugins in the order they were activated, and PHP loads files as they are required and classes as they are called (when using autoloaders), so it is a real lottery which plugin calls the SDK code first. The other plugin is the one that suffers. What's the ideal outcome / user experience for the end user? In what ways would dependency management improve the user experience?

This has been a big issue for me in my development. There are a couple of libraries that are key for API connections that would take so much effort to recreate for a simple plugin that I want to provide to the community. I don't want to cause issues for other plugins, but I also haven't found a good alternative for dealing with dependencies. I'll keep an eye on your posts and look forward to any resolutions you come across!

I know this is only a small part of the deep integration you're talking about, but we've had great results using composer with johnpbloch's wordpress fork and wpackagist. They are at the core of the Roots.io wordpress stack, and go a long way towards alleviating the problem (at least for developers). Ironically, the only plugins we can't manage with composer are premium ones like WP S3 Offload and DB Migrate Pro :D

Doesn't roots.io already deal with this?

i would be extremely happy to see something composer based in the core we were able to solve the similar jQuery issue years ago and now it's time to solve it with generic dependencies

Great article. And it is only one weak part of the problem: think about the numerous JS libs called, sometimes twice with different versions and, as a user, I am horrified that I can not master what my website is calling outside its domain.

Ugh. I am one of the vocal opponents of including Composer in WordPress. I won't repeat my objections here because they can easily be found in Trac but I will leave this ditty: "A WordPress developer had a problem managing dependencies and thought 'Wow, I can use Composer to solve that problem!' Now the developer has two problems."

rarst has a good page regarding composer in wordpress http://composer.rarst.net/

See https://github.com/mzalewski/wppm It bundles Composer and uses Composer's dependency solver to resolve plugins conflicts (or notify the user that PluginA cannot be activated). My question is: Do we want to allow users to automatically resolve conflicts by downloading different dependency versions? Composer is a dev tool, not a user tool. While I definitely think WordPress needs to add some kind of dependency management to handle conflicts, I don't think it should be allowed to modify the WP installation and potentially introduce some site-breaking changes that could be a nightmare to debug.

This is a great well written article. Like many of the commenters below, we have been using Bedrock from roots.io for our base install. I recently had the need to integrate a Laravel app with a Wordpress backend. Using the s3 drivers from League's Flysystem for Laravel 5 requires AWS SDK v3, and the delicious brains plugins use v2 - basically an unsolvable dependency conflict! It's time Wordpress catered more for developers by integrating with the tried and tested industry standard solutions out there like Composer.

Iain, I feel that this is a big problem for WordPress in that all of the other serious PHP based projects are composer friendly and we've all just kind of done our own thing. I started down this road (see: https://github.com/mikelking/dummy). In any event I got dummy working to the point of building a working site out of several different layers of composer abstraction. Ultimately getting hung up on some of composer's 'There can be only one' obliterate the destination directory magick and making certain it works in ALL dev environments. Keep in mind that .org has abandoned PHP5 altogether (as an end of life prospect). See https://wordpress.org/about/requirements/ which stats the following: * PHP version 7 or greater * MySQL version 5.6 or greater OR MariaDB version 10.0 or greater * HTTPS support I don't think that you need to get .org onboard w/ composer out of the gate. My vision for the dummy project was to make it easy for a developer to fork dummy and then define their dependencies in the composer manifest and build their plugin or theme without having to worry about the other details. The secondary goal was to make it possible for anyone to to fork dummy to easily define a new site in a consistent manner using the composer manifest and then use tools like jenkins or deploybot to ship the code to their hosting provider. In both cases the composer magick happens before the code hits the web heads. I think there are some synergies to what you want to do and what I've already done, thus if you want to discuss hit me on twitter: @mikelking:disqus

Good article, and I would love to see Composer in WP, as well as contribute to the development of the associated software, etc. If someone takes this on, feel free to get in touch with me. There are however a few points I would like to make: 1. Mozart is not a good solution. The namespace is part of a class' FQN, the whole point of which is to be able to identify a class uniquely. PSR-4 makes this possible by requiring a vendor/package prefix. Of course, it is possible for 2 vendors to have the same name, and for them to have 2 projects with the same name also. However, this is quite unlikely, and if this happens it can easily be fixed. Therefore, I don't see any problem here. And no need to screw with other people's code. Leave the namespaces as is, and just use PSR-4. Clever people have already created all the standards and tools we need to make this possible. It's just that WordPress developers are so attached to usability, that they tend to forget about practicality. In this case, trying to make any combination of plugins possible is something that is unnecessary. There is such a thing as incompatibility, and it's alright. It's there for a reason. 2. No need to "heavily customize" anything. Of course, there is need for some customization. The composer/installers package works great for these things. oomphinc/composer-installers-extender can be used to avoid having to write an installer, if needs be, even if temporarily. wikimedia/composer-merge-plugin can allow us to merge configs from multiple locations, which looks like a good way to solve some of the problems. And we'll probably end up writing a Composer plugin, yes. But this is not necessarily huge. Many problems can be solved via convention. On the other hand, I understand that this is probably a case of just abusing the word "heavily". 3. Plugins can also be required. There's no problem with requiring other plugins, if they provide something useful. A plugin is just a package. However, it would be much better if plugin dependencies were libraries instead. And for this, developers need to write better code. So what? Many people have been writing good code for like ever. If some people can't, that's OK. Maybe, it's even impossible to provide a way for consistent management of plugins via Composer. Maybe, that's OK too. As long as it's possible to manage plugin dependencies through WordPress with Composer. 4. Develop the functionality standalone. As Carl Alexander says, you've got to have really thick skin to be able to stand against the human factor when contributing to WP, and I am not willing to put myself through that torture. Instead, just develop a standalone tool, and wrap it in a WordPress plugin. If WP Core wants to integrate it, they can. If not, well, what's the problem? The tool would be available with an open-source GPL-compatible license such as MIT, and those who want to use it will use it. Which I'm guessing will be a great many. Anyhow, like I said, I'm available to help out here, whether it's hands-on dev work, or planning, project management, whatever. You can check out my work at RebelCode and Dhii to learn about the way I do things.

Disqus marked it as it contained a link, approved :)

This is a great topic and I would love to help see this happen. I'll do what I can to support it as a project, but if my efforts with contributing to WP-CLI are anything to go by, I'll mostly be logging issues as I find them in using the solution. I'm currently developing a plugin for a client that bundles the AWS SDK, I'd be interested to hear how you have worked around the problem in its current incarnation. Or if you get a support request do you just ask the conflicting plugin developer to update their SDK version?

Addition of composer in WP great..!!

I would love to see composer in WP

Automattic, the company who owns WordPress, DOESN'T WANT THIS FOR BUSINESS REASONS. It's not a technical issue, it's a business GOAL for them not to have a dependency manager like Composer. If you integrated Composer into WordPress, you would then break the gatekeeper function of the Automatic company. It would essentially smash the .org plugin repo [as you could now pull source from anywhere]. THIS WILL NEVER HAPPEN WITHOUT A HARD FORK. This is a great discussion, but you guys all miss the point. AUTOMATTIC IS NOT YOUR FRIEND. There already is 100% dependency management the way Automattic wants it. You give a notice to the user that they need to download another plugin from the .org repo OR YOU DON'T USE THE DEPENDENCY. That's how they want it!