This post was contributed by David Hayes. David loves solving difficult problems at Press Up, publishing new WordPress tutorials at WPShout, and eating cold cereal with milk.
The developer tool Composer has been sneaking in around the fringes of the WordPress community. Rarst is a fan. The Roots theme framework folks like it. There’s support infrastructure like WPackagist.
Composer is widely known in the wider PHP development space. Developer types who mostly focus on WordPress probably have some passing familiarity with it. Maybe you ran across a project I mentioned, or heard about it at a WordCamp or meet-up. Or maybe you’ve seen Sarah’s intermittent coverage here at the Tavern when projects — most recently BuddyPress — take steps to support it.
Composer is awesome. I think it’s the most exciting thing to happen to PHP in the last five years. WordPress is awesome. I’ve been using WordPress for nearly a decade now, and I wouldn’t recommend people use anything else for a beautiful, feature-rich publishing experience for the web. But I don’t think the two fit together as well as some would like, and that’s our focus.
But don’t worry if you don’t know what Composer is, we’ll start with that. Then we’ll cover a bit about why WordPress is great and explain where the two fit together, sometimes a bit awkwardly. Finally, we’ll look at how and when it makes sense to incorporate Composer into WordPress work.
What is Composer Anyway?
In the very simplest version, Composer is dependency management for PHP. That is, it’s the way that I can pull in external code — libraries, classes, whatever you want to call them — that other people wrote, make sure it’s loaded for me to use, and never need to worry about it again. Many other languages have had solutions to this problem for awhile, of varying quality. In Ruby, Gems are very well known. For front-end JavaScript development, there’s some standardization on Bower. Python’s pip has been around awhile. All of these things have similar roles, but the specific implementation is different.
The big problem dependency managers solve is the way most people deal with dependencies — other people’s code they’re using to solve a problem. Without a tool like Composer, it is sloppy and haphazard. When you want a user-friendly date handling library, you go to your search engine, find a few hundred lines of code, copy them into a file, try your best to figure out how to work with them, and never ever know or care when the author of those lines later realizes they created a giant performance bottleneck or security vulnerability.
Dependency managers also take care of the issue that some code you want to use may itself rely on other libraries, classes, etc., that you aren’t already using. This leads to big headaches. And in solving these issues, Composer also makes sure that it gets versions of all that software that work for all the various libraries your application makes use of.
So with Composer, you’re saved from a lot of copy-pasting, you get super-powers about dependency issues, and you’re also given a much easier path to get performance improvements, security patches, new features, and so on.
So you can, for example, tell Composer you want to use a nice date parsing library like Carbon, set your code up to load the Composer dependencies for you before you use them (with a simple include ‘vendor/autoload.php’; to use this article’s only snippet of PHP) and you’re set to go. And when Carbon, or another dependency, gets updated, you’ll be able to quickly get the latest version with a simple run of Composer’s update command.
What Makes WordPress Great
Since you’re reading WPTavern, I’ll just say, succinctly, that WordPress is an easy-to-use CMS with a rich ecosystem of plugins and themes that make it easy to accomplish a wide variety of goals.
WordPress is made to be easy-to-use — specifically, for the end user. An average WordPress user, who is put a little on edge by the mention of PHP code, is still able to easily change the look or behavior of their site just by installing a new theme and a few of the thousands of great plugins out there, right from the simple user interface. Even for commercial plugins and themes, the user can probably rely on few-click updates. Users get security updates to their core WordPress code without even needing to think about it.
How Composer and WordPress Can Work Together
As Josh Pollock called out in a great article about Composer, there are three basic ways WordPress and Composer can be combined:
- To manage dependencies for a theme or a plugin you’re developing
- To manage your themes and plugins used on a site
- For total site dependency management
We’ll take on the last two first, as they’re the most common way in which people are talking about Composer.
Why Composer and WordPress Aren’t as Compatible as Peanut Butter and Jelly
So WordPress is great and easy to use for slightly-more-technical-than-average people. Composer is great — really really great — for developers. Don’t two great things make a new even greater thing? I mean: I love peanut butter, and I love jelly, and I think a peanut butter and jelly sandwich is one of the top ten foods invented in America. So why don’t I love the combination of Composer and WordPress?
It’s not that they’re useless together. I think they can work together quite well, but I don’t think the solution of “run your whole WordPress site with Composer” that’s creeping into more and more places works well. It takes care of one problem — WordPress being awkward to manage and deploy for developer-types — by creating another — a less-than-great experience for the mortals left with the WordPress site who just want to install this new plugin.
Basically, in trying to cram WordPress into Composer we’re forcing a square peg into a round hole. WordPress’ focus on end-user ease-of-use — just jump into the admin area and search for a plugin on the WordPress.org repository, or upload the Zip archive you got from the seller — is conceptually at odds with using Composer to install WordPress.
The change of behavior, and frankly the greater knowledge required, makes it the opposite of a simple experience for most. For a site with dedicated and knowledgeable developers or admins around 24/7, that’s possibly a wise trade off, but for most WordPress sites I see, that’s a losing combination.
When Composer and WordPress are a Good Combination
Even for most WordPress cases, I think there’s one place where Composer’s great: when you have some dependencies in a theme or plugin. It’s the combination of WordPress and Composer I’ve tried repeatedly and recommend heartily. It is brilliant. When you’ve got a project that you know doesn’t really need to support down to PHP 5.2, and where you really do want some helper code, Composer is fantastic as a way to get that external code and seamlessly keep it up to date. (Autoloading, a Composer feature which we’ve ignored until this point, is also a big perk.)
For plugin or theme development, I think Composer is great. If you’re making a plugin that would benefit from a great date-parsing library like Carbon, a Markdown parser, or something else, by all means use Composer to pull that in. For more WordPress specific stuff, such as CMB2 or TGM Plugin Activation, it’s far better to pull that from Composer than an old-school copy and paste.
There’s a Time and a Place for Composer
WordPress and Composer aren’t useless together; far from it. But the “run your whole WordPress site with Composer” solution is only right for developer-intensive use of WordPress. If you’re using something like Capistrano for deployments already, go ahead and slot Composer right in beside it. For casual WordPress users, even those who’ve made or modified a theme or plugin before, Composer is most likely to end up feeling like awkward-to-integrate overkill.
As a developer, you should know how to use Composer to take care of complex dependencies inside of a plugin or theme and then package up your Composer dependencies in a way that is invisible to the end user. Let them be blissfully unaware that you’ve used Composer at all. Let them keep that smooth and comfortable WordPress flow with core security and easy updates. That way we get the best of both!
Composer is a developer tool. I find the argument that developer tool is bad fit for end users… a little self evident? :) It is obviously bad fit. No one had even tried to claim otherwise.
“Most WordPress sites” out there (statistically speaking) are poorly managed, outdated wrecks.
Composer based WordPress stacks certainly aren’t for them. They are for serious well maintained sites, made and run by developers. Not users.