Using Composer in managed WordPress installations

A middle ground WordPress installation using Composer.

Composing

I’ve became a fan of Composer and use it whenever I can: the convenience the tool offers for managing dependencies coming in from so many different sources and its array of configuration options lend it to many uses.
My starting point into it was Rarst’s guide and the idea of having a WordPress installation “compose itself” with a simple command was too attracting to let it pass.

Limited configuration freedom

While Composer will let anyone assemble a PHP project in any conceivable way some really cheap, and hence popular, hosting providers will offer WordPress specific hosting with a twist: the installation has to be a complete vanilla installation of WordPress not moving the content folder or any part of it anywhere.
The rules extend to the point of preventing the installation of some plugins but will gladly not take a peek into the folders to the point of paranoia.

Vendors

The two main powers of Composer I’m interested in while working on fully managed client sites are:

  • autoloading in a fast, cheap and convenient way
  • being able to define site wide dependencies outside of the powerful but sometimes limited WordPress plugin structure

The file below is the composer.json file I’ve modified starting from the one Rarst shared to my needs

{
  "name": "lucatume/acme",
  "description": "Acme site",
  "authors": [
    {
      "name": "Luca Tumedei",
      "email": "[email protected]",
      "homepage": "http://theaveragedev.com"
    }
  ],
  "type": "project",
  "repositories": [
    {
      "type": "composer",
      "url": "http://wpackagist.org"
    },
    {
      "type": "vcs",
      "url": "https://github.com/lucatume/DI52"
    },
    {
      "type": "vcs",
      "url": "https://github.com/lucatume/cmb2-tad-fields"
    },
    {
      "type": "vcs",
      "url": "https://github.com/WebDevStudios/CMB2"
    }
  ],
  "config": {
    "vendor-dir": "wp/wp-content/vendor",
    "preferred-install": "dist"
  },
  "require": {
    "WebDevStudios/cmb2": "~2.0.5",
    "lucatume/cmb2-tad-fields": "dev-master",
    "lucatume/args": "~0.1",
    "lucatume/DI52": "dev-master",
    "xrstf/composer-php52": "1.*"
  },
  "require-dev": {
  },
  "extra": {
    "installer-paths": {
      "wp/wp-content/plugins/{$name}": ["type:wordpress-plugin"]
    }
  },
  "autoload": {
    "psr-0": {
      "Acme_": "wp/wp-content/mu-plugins/src/"
    }
  },
  "scripts": {
      "post-install-cmd": [
          "xrstf\\Composer52\\Generator::onPostInstallCmd"
          ],
      "post-update-cmd": [
          "xrstf\\Composer52\\Generator::onPostInstallCmd"
          ],
      "post-autoload-dump": [
          "xrstf\\Composer52\\Generator::onPostInstallCmd"
          ]
  }
}

What the file above is doing is defining some dependencies I will probably need, if that’s not the case Composer allows removing dependencies as easily as removing a line, and specify the custom installation paths I will be using.
Particularly the vendor and the src folders are going to be sub-folders to the mu-plugins folder: this is not breaking any hosting rules and seems not to bother any hosting provider.
I’m not pulling WordPress in because that’s pre-installed and managed by the hosting provider and I’ve reduced the plugins list to the safest maximum I’ve never had problems with.
The repo, as is, is PHP 5.2 compatible and the xrstf/composer-php52 package is taking care of producing a vendor\autoload_52.php file that will provide PHP 5.2 compatible auto-loading.
The other part of this set up is a small plugin I will put in the wp-content\mu-plugins folder that will take care of including the autoloader first thing file and that’s done.

I appreciate your input