I’ve written a few posts already and I’m sure to be writing many more on the subject of getting Wordpress to work in at large company, we’ve been working hard to make Wordpress a platform which we can manage through the Dev/QA/Stage/Live process with the minimum of effort and fuss on behalf of the developer.

The latest addition to this toolkit is the use of Composer to manage the plugins and themes for our various websites.

Our main aim was to remove the numerous plugins that are used across multiple sites from outside of the main site codebase and move them into git repositories where sites could install different versions based on the popular Composer dependency manager. This is a tool we already use to manage sites built using Symfony so it made sense to keep the number of different tools to a minimum.

A while back Composer added support for installers which covered a number of popular opensource applications, our first thought was great, someone else has done the work for us however the standard installers are restricted in what you can do.

For example the wordpress- installer only allows you to install plugins and themes into wp-content, for us this was a show-stopper as we have been very strict to move plugins and themes outside of wp-content so that we can easily version control them whilst leaving wp-content to just contain what really is content (this is based on some of the ideas from Wordpress Skeleton). I intend to blog more about that later!

This mean’t it was time to dig deeper into Composer and write a custom installer. The documentation on the Composer site was at first a little confusing but after some beer and pizza and possibly a few hours sleep we cracked it, using a custom installer we created our own type which allowed us to then deploy the right packages to our custom locations whilst maintaining the full benefits of using composer to deal with various dependencies.

The only flaw in our plan so far was the management of mu-plugins (Must Use – Not Multi-User ;–)) which for some strange reason don’t support the installation into sub-folders like you can with standard plugins. There are a couple of solutions to this that we are considering.

1. Remove the need for mu-plugins.
2. Have composer generate a load.php file inside mu-plugins to load the various plugins from sub-folders.

I am hoping that we can have a solution either way sometime later this week so that we can consider this problem of plugin management resolved.

I intend to share this custom installer if there is enough interest in this so please feel free to contact me if you are interested!