Borked Composer Dependency Chains

One of the biggest changes to working with WordPress over the last few years has been the addition of dependency management utilizing composer. Composer is a PHP dependency management solution akin to NPM and when used wisely it can be down right magickal. However when it is abused things can quickly devolve into a royal mess.

Let’s first take a small detour to understand why you would use composer over the plugin and theme management system built into WordPress. In an enterprise environment where your production site has a large readership and is possibly even a source of revenue you need to establish procedures that ensure there is minimal disruption during deployments. Furthermore if something should go awry you need a reliable method of investigating the phenomena.

Properly utilizing composer along with git and a CICD build pipeline you can explicitly define and preserve any given state of your production environment. This means should you experience a catastrophic failure you have your entire WordPress environment defined in an easily reproducible format. More importantly your development team has the ability to operate as cohesive entity. Meaning you can easily scale up your dev team as the work load increases. Consider the following:

• You can quickly restore from a significant system failure in what could be mere minutes as opposed to hours.
• You can also establish a clean and clearly defined build ladder (see Tao of Releasing)
• You can easily spin up a regression server for testing

As you can see in the following image you can easily define the plugin or theme and the version to be installed. In fact in my shop we explicitly define as many of these as possible to eliminate arbitrary bugs. I prefer the extremely methodical approach to blind faith Hail Mary approach often proposed by others. This deliberate approach to dependency management can mean the difference between the success of the entire team or a significant loss in revenue on the production site and subsequently one’s livelihood.

I will not go into installation of composer as that is entirely a topic for another discussion. My goal in this case is only to show that you can easily add plugin or theme definitions to the manifest by going to WordPress Packagist and searching for the plugin/theme in question. In the following I search for the brightcove plugin and once located you can click on the specific version you want to install and the site will present the entire line definition to cut & paste into your manifest.

So the big problem comes in when the developer removes a previously installed version. This itself can be the result of a deliberate change or possibly the break down of their own build CICD chain or worse neglectful ignorance.

In the above screen shot you will notice that my manifest was searching for the 1.8.2 version of the Brightcove plugin and was denied because it could not find it in the publisher source. This is a problem since I have not changed my manifest regarding this asset, but the plugin maintainer has removed the entire 1.8.x version from the tree.

Issues like this do not always present themselves under normal daily working circumstances, because composer caches the installation data. Unless you run composer cache-clear or are setting up a new work environment you may not be aware of the missing dependency. When they do, they tend to rear their ugly RPITA heads in a way of crashing your happy developer vibe for the day. Worse if you have a large team every dev who touches the composer manifest will invariably include this additional change in their update.

After you have modified the composer.json manifest you need to run composer update to regenerate the lock file and install/update the appropriate dependencies. This file is referenced during the deployment by the CICD build pipeline and can make adjustments depending on the configuration for the destination environment. For instance take the following snippet of code:

"require-dev": {

    "wpackagist-plugin/debug-bar": "1.0",

    "wpackagist-plugin/show-current-template": "0.3.3",

    "wpackagist-plugin/debug-bar-elasticpress": "1.4",

    "phpmd/phpmd": "@stable",

    "squizlabs/php_codesniffer": "3.*",

    "phploc/phploc": "^4.0",

    "sebastian/phpcpd": "^3.0",

    "wp-cli/wp-cli-bundle": "v2.4.0"

  }

This section defines the local development dependencies and my team’s CIDCD build pipeline explicitly excludes these with the composer install –no-dev command as they are NOT needed nor should they be installed on a production environment.

In this article we have touched upon the power that composer brings to WordPress in the enterprise and there is far more that you can do. I have installations where the entire site even the version of WordPress and various mu-plugins are defined by composer as dependencies. These are sophisticated installations that build upon the discussion here.

The problem is that with that power and sophistication there comes a good deal of responsibility and deliberation. You can easily run amuck and when maintainers remove entire version trees things can break down rather quickly. One way to work around this it to add the update for this as a specific feature branch that each dev can merge into the new working branch thus centralizing the change and making it easier to keep the work flow clean, but that require team wide coordination.