Solving dependency management in WordPress plugins

I’ve been working on a proof of concept for solving dependency management in WordPress plugins for a while now. It was in a private repository on GitHub, where I would invite some people in to work out the most obvious issues, while keeping it a bit on the down-low (this is a big change, potentially, after all).

Now it’s time though. The WordPress Composer Installer repository is now open to the public. Note that this is not more than a proof of concept, albeit it a working one. There are some hoops to jump through to get this working, but all these steps can be automated once I make this a fully featured plugin.

Recent blog posts like Ryan McCue’s take on solving dependencies and Gary Pendergast’s response to that are likely to fire this discussion up again. I will publish a more detailed post about why I think this is important, but I’m on a short vacation while I’m typing this and should probably be out enjoying sunny London. ☀️

Join the Conversation


  1. Hi,

    your post reminds me of something I did in a quick-hack a while back.
    It takes an (satis) repository, reads out the packages and creates a list table in the backend with install options.
    This still works so far, but is of course missing a lot.
    I think I’ve stopped when I realized that reading packages from (wp)packagist would need a lot more work and time.
    You might check it out if you’re interested:


    1. Thank you. I’ll have a look at your code for sure. I haven’t figured out what the best approach is for users to determine what dependencies they need (or want) to install.

      The (WP) Packagist route is definitely one I’m familiar with, but it only works when your whole website is Composer managed, but that doesn’t work with cases where you’d just install one or more plugins that require some dependencies. My plugin idea does both.

Leave a comment

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