When Is Composer the Right Tool?
This is the beginning of a series on building and deploying a WordPress site using Composer to manage dependencies. At the start here, I want to lay out some of my assumptions and roughly what I will be going over in each part of this series.
My first and biggest assumption is that you already know what Composer is and how to use it. There are already plenty of good articles introducing Composer to WordPress developers. I don’t feel the need to write the same information over again. This series is specifically meant to address development and deployment strategies.
Another assumption I have is that you are a technically-minded person who works directly on the source-code of WordPress websites. Seems obvious, but it should still be said.
Before You Start A Composer-Managed Project
Before diving into your next project and deciding to use composer to manage its dependencies, it's a good idea to figure out whether it makes sense to even use it. None of these should be taken as absolutes. If you think these considerations are wrong (either for you or in general), by all means, please disregard them. I think Composer is a fantastic tool and close to all of my WordPress projects use it. These are just the situations I've found to be more or less suited to using it with WordPress.
When You Might Not Want Composer
Older PHP Versions
Composer uses namespaces, a feature added in PHP 5.3. WordPress' minimum supported PHP version is 5.2. So if you're on a host that still uses PHP 5.2, change hosts. If that's not possible, you're going to have a very hard time of it. First of all, very few Composer packages will be compatible with your version, but there are compatibility layers that generate an autoloader compatible with PHP 5.2. Even using those, though, you will need to have continuous integration and continuous deployment servers set up to actually run Composer, since your host will not be able to.
As a side note, in case you're wondering: if your website is not on PHP 5.6 or higher, upgrade. If you can't, find a new host ASAP.
No SSH Access
Lack of SSH (Secure SHell) access isn't a compelling reason not to use Composer, but it is going to require a more complex setup. If you can't log into your hosting environment to run Composer, you need to do so on a build server (DeployBot, CodeShip, Buddy, Jenkins, etc. are all good options here). All the same, if you're looking to get up and running with a Composer-managed deployment without too much fuss, you're going to want a host that gives you SSH access.
If you're using managed hosting that is restrictive of your plugins, themes, etc., I would check with them about using Composer first. I won't say none of them support it, but I will say I've never had an experience with one that did (in all fairness, I tend to manage my own hosting, so my sample size is admittedly small).
If the site you are building will be maintained by somebody who cannot reasonably be expected to use Composer and version control (at the least) do not use Composer. You will saddle them with an overly complex system that they will never be able to update. Seriously, don't do it. Whoever manages the site needs to know how to use Composer and whatever deployment system you put in place.
Installing Themes and Plugins with WordPress
If the site owner needs to be able to use the WordPress plugin/theme/core updater/installer, you almost definitely shouldn't use Composer. The whole point of Composer is to lock your dependencies to an approved list and at approved versions. New packages and new versions should not be added to the dependency tree without making sure they actually work. If somebody can radically alter production by adding, updating, and deleting packages, this will present two problems:
- You cannot easily reproduce the state of production in a development environment
- You can easily eliminate code changes in production just by deploying the codebase
None of this is insurmountable, but it will make things much more difficult.
When You Should Use Composer
With all these precautions, what are the scenarios where it makes a lot of sense to use Composer?
- Multiple Developers: When everybody is trying to work on the same codebase, Composer helps reduce the likelihood that the team is using vastly different versions of third-party plugins and themes. You can assume that everybody either already uses the correct versions or is Doing It Wrong™.
- Multiple Deployment Stages: Strict dependency management means predictable and repeatable deployments. That's critical if you need to be able to deploy to multiple environments or need the ability to roll back a deployment. Keep in mind that your local development environment is also a stage.
- Separation of Concerns: If you use Composer, WordPress doesn't need write access to your filesystem. If the web server can't write to your filesystem, there are fewer attack vectors for malicious actors.
- Complex Dependency Trees: Ever had multiple plugins that all rely on another plugin, but one of them can't be upgraded because it's incompatible with another one until they finally fix that bug? Yeah. That's the exact problem Composer was meant to solve.
- Learn a Useful Skill: If WordPress isn't the last major project that hasn't adopted Composer, it sure is close to last. If you plan to work with PHP and want to branch outside of WordPress, you'll need to know how to use Composer anyway. Why not learn now?
Next week, I'll continue the series with an article on project setup.