WordPress plugin management with Composer – the Why and How

wpheartcomposer

Hi there!
In this blog post I will talk a little about using Composer to install and manage your WordPress plugins.
You might ask why you would want to do that, so let’s dive right into The Why.

The Why
At Aftonbladet we are running a fairly large and complex WordPress installation. We are of course using a SCM (Git) and as any developer (or DevOps) we want our repository to be as lean and clean as possible and still be able to deploy our app as an isolated entity.
One step on the way is to make sure that any third party plugin (and our own plugins, for that matter) is not checked into our project and thus not “polluting” our codebase. Why should we version control code that someone else is maintaining if we don’t have to?

The How
Composer is an awesome tool for managing dependencies within any PHP application. If you’re not already using it, read this guide or any other guide you might find on Google and you’ll soon realize why it’s a must for any modern PHP developer.

So how would you use this with your WordPress installation? First of all, this solution is mostly for VPS solutions (and such) where you would have some control of the server (so that you can install Composer). If you’re using a share host (like on Binero, Loopia) you would not be able to use Composer in the matter that I am about to describe.
The first thing you need to do is to add a new Composer Repository containg all of the plugins from wordpress.org. You’ll find this over at wpackagist.org.

Modify your composer.json and by adding this (example from wpackagist.org):

 {
   "name": "helloworld/brilliant-wordpress-site",
   "description": "My brilliant WordPress site",
   "repositories":[
     {
       "type":"composer",
       "url":"http://wpackagist.org"
     }
   ],
 }

You will now be able to install all available plugins from the wordpress.org repo, neat!
Add this to the require section of composer.json to install Contact form 7 and Yoast SEO (two popular WP plugins):

"require": {
   "wpackagist-plugin/contact-form-7": "3.8.1",
   "wpackagist-plugin/wordpress-seo": "~1.5.3"
 },

The number “3.8.1” is of course the version of Contact Form 7 that I want to install. Specifying “~1.5.3” from Yoast SEO would update that plugin to all 1.5.x versions of the plugin. More info on that over at getcomposer.org.

(Optional: want to create your own composer repo containing your private repos? Satis to the rescue! Read more at https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md)

So now I want my plugins to be installed in the wp-content/plugins folder (since they are pretty useless in /vendor).
Start by adding composer/installers (https://github.com/composer/installers,  https://packagist.org/packages/composer/installers) to the require section of composer.json. (This step is not 100% necessary since the plugins at WP Packagist already defines composer/installers as a dependency, but I will still add it to make the example a bit clearer and easier to follow.)
Composer.json should look something like this:

"require": {
   "composer/installers": "~1.0",
   "wpackagist-plugin/contact-form-7": "3.8.1",
   "wpackagist-plugin/wordpress-seo": "~1.5.3"
 },

Your WP-plugins will now automatically be installed in wp-content/plugins!
Using a custom path for your plugins (we are at Aftonbladet)? No worries, just read this section about custom installation paths with composer/installers: https://github.com/composer/installers#custom-install-paths

We are also using the require-dev part of Composer to install some plugins only needed on our local dev machines. By adding the lines below to the require-dev part of composer.json all developers in the team gets easy access to the Debug bar and Debug bar console plugins:

"require-dev": {
   "wpackagist/debug-bar": "0.8.1",
   "wpackagist/debug-bar-console": "0.3"
 },

Just add the plugins that you are using on your local machines and you will be good to go!
Here is the final example composer.json file.

Now it is about time to add the entire wp-content/plugins to your .gitignore (or whatever SCM you are using):

# ignore plugins since they will be installed by Composer in deploy
 wp-content/mu-plugins
 wp-content/plugins

Run composer update to create a new composer.lock that will be used when running composer install. If you need to update the version of a plugin, alter the version number and run composer update again. The output from composer will tell you what packages/plugins that have been updated.

The final step is to add the composer install –no-dev command in your deployment procedure. At Aftonbladet we are using Vlad the Deployer (the leaner cousin of Capistrano) and have one custom task that runs composer just before putting the latest release as the current one. More on that in a later blog post!

That’s all for this time! Want to discuss Composer with me?
You’ll find me at Twitter (@chredd) or just send me a mail: christoffer.larsson@aftonbladet.se

Next time: Taking it one step further – installing the WordPress core with Composer.
And after that: Installing your own private plugin from GitHub using Composer.

Fin.


A Holistic View on Developer Productivity

What does developer productivity mean, really? Is it churning out more code or less code? Is it to have less bugs in production or shipping code more often? Is it doing a lot of things or just one thing? Let’s think about this for a moment. I believe developer productivity is about getting more things […]


Improving the usability of Aftonbladet Video-clip pages

We have recently started the process of improving the usability of video-clip pages. In order to get an idea of where Aftonbladet stands compared to other world-class online video/news providers, we conducted an online test answered by 110 visitors of Aftonbladet TV. In this test we compared their perception of an Aftonbladet TV video-clip page […]


Schibsted’s 1st iOS Deployment Meet-up

Schibsted’s 1st iOS Deployment Meet-up Thursday, 28th of April 2016: getting to know each other, guests arrive Friday, 29th of April 2016: the meet-up date We here at Aftonbladet had been planning on having a meet-up with iOS developers across various Schibsted companies for many months. We had a range of topics in mind for […]


Hackday: The Future of Storytelling is social, engaging and rewarding

We gathered students, journalists, developers and designers to get together and conceptualize something new for the news industry. This was our first organized hack event – The Future of Storytelling Hack. The hack was a team-based, news-media-focused prototyping and experimentation event within storytelling over two days at Kungsbrohuset, Schibsted and Aftonbladets headquarter in Stockholm. A good story used to […]