Loading a Private WordPress Plugin with Composer

Previously, I described my process in loading WordPress.org plugins via composer, however, a number of plugins I use are private plugins (either because they are commercial plugins I’ve purchased or internal plugins I’ve written). One can use composer to load these plugins by doing two things:

1. Create a repository for the plugin (this can be a public or private repository) with an appropriate composer.json
2. Define the plugin repository and require the plugin in the project composer.json

On the Repository for the Plugin

Add a composer.json file similar to the following to the plugin Git respository. You can create this file manually or use composer init to define it interactively. The code below is taken from my Example WordPress Composer Loaded Plugin on GitHub.

{
  "name": "ironcode/example-wp-composer-loaded-plugin",
  "description": "Example WP plugin loaded via composer from a Git repo",
  "type": "wordpress-plugin",
  "require": {
    "composer/installers": "^1.0"
  },
  "license": "GPL-3.0+",
  "authors": [
    {
      "name": "Sal Ferrarello",
      "email": "sal@example.com"
    }
  ]
}

Check Your composer.json

You can check your composer.json file by running composer validate from the command line.

On Your Project (website)

For the WordPress project where you want to load the plugin, add a composer.json file similar to the following. Again, you have the option to use the interactive composer init command.

{
  "name": "example-vendor/example-wp-website",
  "description": "WordPress website",
  "license": "GPL-3.0+",
  "repositories": [
    {
      "type": "vcs",
      "url": "https://github.com/salcode/example-wp-composer-loaded-plugin.git"
    }
  ],
  "require": {
    "ironcode/example-wp-composer-loaded-plugin": "dev-master"
  }
}

Version Number

In this example, the version number is dev-master. This will pull the master branch. Alternatively, you can use another branch name prepended with “dev-” (e.g. dev-develop will load the branch develop).

Generally, it is preferable to use git tags to define your version numbers. For example, you can create a tag of “2.3.5” to represent version 2.3.5. Using a tag representing a version number allows you to make use of the caret operator, which allows version definitions like ^2.2.0 (which allows versions from 2.2.0 up to 2.x.x, i.e. anything up to a major version change as defined by SemVer).

Create and Push a Tag to the Server

git tag 2.3.5
git push origin --tags

Private Plugin Repositories

In the case of a private repository housing the plugin, composer will prompt you for login credentials for the repository. You can avoid this authentication step by leveraging SSH keys for Git Authentication.

Sal Ferrarello (@salcode)

Sal is a PHP developer with a focus on the WordPress platform. He is a conference speaker with a background including Piano Player, Radio DJ, Magician/Juggler, Beach Photographer, and High School Math Teacher. Sal can be found professionally at WebDevStudios, where he works as a senior backend engineer.