Installing WP plugins via Composer

In this article, we will discuss how to install plugins using Composer. The instructions will cover plugins that are located in the WP repository and plugins that are developed on github.com and added to the default PHP package directory https://packagist.org/.

For plugins from the WP repository, there is a separate repository https://wpackagist.org/ - this is a copy of the WP plugin catalog specifically created to make it convenient to add a plugin via Composer (do not confuse it with packagist.org).

Note: All descriptions below assume that you already have installed Composer.

Installation from wpackagist.org

The first thing to do is to create a composer.json file. Usually it is created in the root folder of the project. Check the schema (possible parameters) of this file in the documentation.

Suppose we created it with these parameters:

{
  "name": "My Project",
  "description": "One more project.",
  "license": "proprietary",
  "authors": [
	{
	  "name": "Author Name",
	  "email": "[email protected]"
	}
  ],
}

Since wpackagist.org is not packagist.org (default repository), it needs to be registered in the composer.json file so that Composer knows that there is another repository where packages can be found for installation:

{
  "name": "My Project",
  "description": "One more project.",
  "license": "proprietary",
  "authors": [
	{
	  "name": "Author Name",
	  "email": "[email protected]"
	}
  ],
  "repositories": [
	{
	  "type": "composer",
	  "url": "https://wpackagist.org"
	},
  ]
}

Now in the require parameter, we need to add the name of the plugin we want to install. And also specify the extra.installer-paths parameter - the path to the WP plugin folder where we want Composer to install the plugins.

For example, let's install the plugin redis-cache:

{
  "name": "My Project",
  "description": "One more project.",
  "license": "proprietary",
  "authors": [
	{
	  "name": "Author Name",
	  "email": "[email protected]"
	}
  ],
  "repositories": [
	{
	  "type": "composer",
	  "url": "https://wpackagist.org"
	}
  ],
  "require": {
	"wpackagist-plugin/redis-cache": "^2.4.4",
	"composer/installers": "*",
  },
  "extra": {
	"installer-paths": {
	  "path/to/wp-content/plugins/{$name}": [
		"type:wordpress-plugin"
	  ]
	}
  },
  "config": {
	"allow-plugins": {
	  "composer/installers": true
	}
  }
}

All plugins from the wpackagist.org repository have the type wordpress-plugin. In the installer-paths parameter, we specify that all plugins with this type should be installed in the specified folder, not in the default Composer folder vendor.

Also, we install the package composer/installers, and in the config.allow-plugins parameter, we allow it to be loaded together with Composer and extend its functionality.

Package composer/installers is an official Composer package that allows specifying a directory different from vendor for package installation. However, it only allows changing the installation directory for restricted package types, for WordPress these are:

wordpress-plugin
wordpress-theme
wordpress-muplugin
wordpress-dropin

That's it! Now, to install the plugin, we need to run the command:

$ composer install

Nuance with plugin versions from wpackagist.org.

wpackagist.org copies the WP plugin repository (https://plugins.svn.wordpress.org/) and does not care about preserving previous versions. Therefore, the presence or absence of a specific version of the plugin falls on the developer's shoulders. The developer must maintain so-called tags (SVN tags directory). That is, when publishing each version, the developer must ensure that a published version of the plugin is created and remains in the tags directory in the future.

To better understand what this means, let's consider an example. Let's take the plugin wp-sitemap-page. Suppose we specified a specific version 1.6 (this was the last version at the time of installing the plugin):

"require": {
  "wpackagist-plugin/wp-sitemap-page": "1.6"
}

Time passed and a new version 1.7 of the plugin appeared. Now, if we run composer install for an environment where the files of this plugin are not in the desired folder (for example, when deploying to a dev or production server, we always install all packages anew), version 1.7 will be installed, despite the fact that in composer.json it is explicitly specified that we need version 1.6.

This happens because wpackagist.org simply copies the WP repository, and if we look into the tags directory (plugin versions) https://plugins.svn.wordpress.org/wp-sitemap-page/tags/, we will not find the required version 1.6 there, so there is simply nowhere to download it from, and therefore the latest dev version from the /trunk directory will be downloaded.

This can also be seen in the composer.lock file. The URL for downloading does not contain any version and points to the current version from the trunk directory:

Fortunately, according to my observations, there are fewer and fewer such plugins in the WP repository. Especially if the plugin is popular (although there are similar glitches there too).

Installation from packagist.org

Everything is done similarly, with the only difference being that we do not need to specify an additional repository, and it is necessary for the plugin author to add the plugin to the directory https://packagist.org/.

For example, the same plugin redis-cache can be installed with this configuration in composer.json:

{
  "name": "My Project",
  "description": "One more project.",
  "license": "proprietary",
  "authors": [
	{
	  "name": "Author Name",
	  "email": "[email protected]"
	}
  ],
  "require": {
	"rhubarbgroup/redis-cache": "^2.4.4",
	"composer/installers": "*",
  },
  "extra": {
	"installer-paths": {
	  "path/to/wp-content/plugins/{$name}": [
		"type:wordpress-plugin"
	  ]
	}
  },
  "config": {
	"allow-plugins": {
	  "composer/installers": true
	}
  }
}

The downside of this setup is that it is not clear that the package rhubarbgroup/redis-cache is a WP plugin, not a PHP package. However, it is devoid of another drawback described above (versioning works more reliably).