Explaining the WordPress plugins dependencies problem

There is a lot of confusion in the WordPress ecosystem when it comes to the issues around bundling dependencies. Peter Suhm has published a detailed post about this exact issue: A Warning About Using Composer With WordPress, where I have left the following (partial) comment:

So imagine both of us loading library x in our plugins, both requiring a version that’s incompatible with each other. No matter how well tested your plugin is, if I get a chance to load my autoloader before yours, I can load a version of the library that is not compatible with yours and your plugin will break (at least, the end user will see it like that and the horror of finding the culprit begins)…

This obviously is not a Composer issue, but related to the way WordPress loads its plugins. It’s also not a well known issue, since Composer isn’t used a lot in the WordPress ecosystem (yet!), especially not in distributed plugins. But as Composer becomes more used, more collisions like this will happen. Without a proper dependency management system in place, this is really hard to solve.

My WordPress Composer Installer proof of concept is as close to solving this issue as I’ve ever been. If there is anyone more experienced with the plugins installer in WordPress and maybe knows their way around Composer as well, I could use some help. 🙂

Join the Conversation


  1. In all software development industry (not WordPress, not Composer, not PHP, but ALL software) when different software pieces work together means that may happen the case of incompatibilities.

    Is not something that can be solved.

    If a plugin is oxygen, and another is hydrogen, put them together and you’ll obtain water. You can’t fight physics.

    So, the problem is not to find a way to make sure all the plugins can always work together, that’s not going to happen. The problem is, on the contrary, recognize the incompatibilities and prevent simultaneous installation of incompatible softwares.

    And this is already fixed using Composer to manage the whole site.

    Let’s state it clearly: in 2015 the only sane & professional way to deal with plugins and their dependencies is to use Composer for the whole site. If you do that, there are no other issue to solve.

    To me, the only thing left to do is try to educate people to use Composer to install and manage their sites. All frameworks and application stacks over there are already doing this. But that is not going to happen unless core will support and encourage this. And we all know that’s not going to happen in the next century.

    I already saw close-to-core developers put some kind of effort in building a WordPress-way to solve the problem (that does not involve Composer). Just like WP is not already enough isolated in PHP community. Because “hey, we are WordPress, we don’t care about you f*ing PHP!”.

    To me, we, as non-core developers, can’t really fix something that core won’t fix. Not in a sane and sustainable way.

    Any attempt, like the yours, is really appreciable, but to really work ALL the WordPress developers out there should embrace it, and again, that’s not going to happen.

    In short: Do you want to put plugins in WordPress official repo and/or sell your plugin? Don’t use Composer, or use one of the hackish tricks people are already using and that works for you. Or maybe use Composer and be prepared to face incompatibility issues (or maybe to maintain an alternative “compatible version” where all deps are embodied and namespaced).

    Want to share your plugin with community for free? Just don’t use WordPress official repo and encourage people to use Composer the right way (manage whole site). If they have problems because of incompatibility, explain them the issue, and let them take a decision. What they decide is not really a problem of yours: that’s a good part of free software.

Leave a comment

Your email address will not be published. Required fields are marked *