WordPress Plugins with Composer

This post was last updated 2023-02-20

This is a follow-up to my previous post on Using Composer with WordPress. Read that first for an introduction.

Bedrock, our WordPress boilerplate, uses Composer for dependency management.

A few common questions came up after my last post and screencast. This post will hopefully clear up two of them.

How do I make my own custom plugin a Composer package?

Let’s get the easy scenario out of the way first. If your plugin is already published to the WordPress Plugin directory, then it’s already available as a Composer package through WordPress Packagist.

Obviously if it’s not in the plugin directory, and you want it available on WPackagist, you can just publish it there first. But let’s assume that you don’t want it publicly available. Maybe it’s a paid premium plugin. Or maybe it’s an internal plugin.

How do I make my own private plugin a Composer package?

If it’s your own plugin and you have control over it, it’s as simple as adding a composer.json file. Here’s the absolute minimum you need to create a Composer package:

{
  "name": "roots/plugin"
}

That’s it. Just a name with a vendor name first, then the actual package name. Your vendor name might be a GitHub username, your companies’ name, etc. Pick whatever makes sense but keep it consistent.

Of course this won’t really work if you want it to be a WordPress Plugin. So we need to add some more information so it’s recognized as a WordPress Plugin:

{
  "name": "roots/plugin",
  "type": "wordpress-plugin",
  "require": {
    "composer/installers": "v1.0.6"
  }
}

We require the Installers custom installer as a dependency. This custom installer defines a wordpress-plugin package type which we also set as our type. This means by default it will be installed into wp-content/plugins instead of the usual vendor directory.

Requiring composer/installers also means that anyone using our package can customize the install path as well (app/plugins for example).

I’m just using the latest stable version of composer/installers found on Packagist.

I suggest you add some extra metadata to your composer.json file as well like the following:

{
  "name": "roots/plugin",
  "description": "WordPress Plugin description",
  "keywords": ["wordpress", "plugin", "roots"],
  "homepage": "https://roots.io",
  "license": "MIT",
  "authors": [
    {
      "name": "Scott Walkinshaw",
      "email": "scott@roots.io",
      "homepage": "https://roots.io"
    }
  ],
  "type": "wordpress-plugin",
  "require": {
    "php": ">=8.0"
  }
}

Note that I also added the PHP version needed under require which is a good practice.

It’s useful to know that WordPress Packagist basically follows the same steps for every plugin in the WP directory.

How do I make a 3rd party plugin a Composer package?

In this case, since you don’t have control over it you can’t add a composer.json file yourself. If the plugin maintainer isn’t nice enough to add one for you, you’ll need to define a custom repository in your project’s composer.json file. Here’s an example of one:

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org"
    },
    {
      "type": "package",
      "package": {
        "name": "vendor/plugin-name",
        "version": "1.2.3",
        "type": "wordpress-plugin",
        "dist": {
          "type": "zip",
          "url": "https://github.com/vendor/plugin-name/archive/main.zip"
        }
      }
    }
  ],
  "require": {
    "php": ">=8.0",
    "vendor/plugin-name": "1.2.3"
  }
}

You can see that under repositories we have 2 custom repositories defined: the standard wpackagist.org and our new one for contentlead/contentlead-wp-plugin. That’s an actual plugin that isn’t currently published to the WP Plugin directory.

Yes it’s a little bit of a hassle to do this but hopefully as Composer becomes more popular in the WordPress world, we’ll have to do this less and less. And remember, go bug your favourite plugin author about adding Composer support!