I Love Composer, I Love WordPress, But I Object to a Marriage

photo credit: Jesse Kruger - cc
photo credit: Jesse Krugercc

david-hayes
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!

25 Comments


  1. 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.

    Report


    1. I think we’re on the same page, just coming from different directions.

      Part of the nuance I was trying to get at — which I think I may have failed to convey — is that there are different levels at which a developer tool like Composer is appropriate and a good fit. Until you’ve used Composer internal to a plugin (or in a small non-WordPress project) to pull in something simple like a Markdown, Twig, etc package, using it for the management of all of your WordPress site’s plugins or all of your site will feel awkward and overwhelming. You don’t have to be a (plebeian) end-user for the full-site Composer solution to feel like overkill. But a more modest use is something you should definitely consider.

      My big goal was trying to walk through the tradeoffs of these different uses in a public space where people could see the whole thing including comments like yours. I really appreciate you weighing in!

      Report


  2. David-

    Great post. As you know, I love Composer. I agree that it’s a difficult thing to integrate into public-facing plugins and themes. It’s wrong to expect all users to be setup, and willing to install and update Composer before using the plugin. This is one of the tricky things about GitHub, or similar, as a distribution system for plugins. Same issue with using Grunt. I think the solution is to maintain a latest stable, and latest dev, pre-built downloads as zip files.

    That said, as a I developer, I love it, especially for deployments and building new sites in VVV, it can’t be beat.

    Take care,
    Josh

    Report


    1. Thanks, Josh. Totally agree about the complexities. It’s hard to distill down all the issues. Keep up the great work!

      Report


  3. Rarst already said the main and obvious rebuttal to this article above so I’ll try and avoid repeating it completely. As the author of Bedrock (which is “total site dependency management” in your words), I made it specifically for developer-driven sites. It’s not meant for freelances to crank out a WP in 1 day and then hand it off to the client. Any developer can still do that if they want. It’s just not the focus of the project.

    There’s also 2 statements made in this article that are simply wrong:

    1. “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 — doesn’t work when you’ve used Composer as your way to install WordPress.”

    2. “WordPress core’s hard-won auto-patching is disabled when you’re using WordPress as installed by Composer.”

    Using Composer does nothing to stop/prevent/disable the above functionality.

    Anyone can use Composer to install WP core/plugins AND still be able to update/install either from the admin. Which is why if a developer wants to start a site with Composer and then hand it off to the client, it will work exactly as a normal WP install would (provided they include all the package sources along with it).

    I hesitate to put much stock into this article when such glaring mistakes were said as facts.

    Report


    1. Thanks for clarify the auto-updating, Scott. I can’t deny that as a pretty substantial oversight on my part. My thought process — well I’d keep up to date by `composer update`s, so I’d not want a user fiddling — obviously isn’t the way you work with it.

      And to be clear, I think all the stuff you’re doing it really great. My intent was not to attack you (or anyone else) for using Composer with WordPress. As I say, I think it clearly has a place.

      My motivation is that I think there are non-trivial number of people just getting comfortable with development and running their WordPress site who hear about Composer and all its cool features and quickly get overwhelmed by all the new stuff that doesn’t fit together so well. It’s an extra layer to learn about, but it’s neither a necessary nor universally better one to my mind.

      Report


      1. Don’t worry, wasn’t taken as a attack or insult or anything. I just wanted to clear up some issues in the post.

        But just to confirm, I do personally use Composer for everything and disable core updates, plugins, etc. But that’s a personal choice and not one that using Composer forces on you.

        I find myself defensive against attitudes like this in the WordPress world because most people (including WP core devs) are so against new tools and technologies. It’s for that reason that I usually find posts like this more harmful than helpful (which I know isn’t your intention).

        Report


      2. I gotcha there. Completely. And I really do appreciate the correction, Sarah just updated the text for me so the difference between the way I’d use it (or you use it) and the way it can be used isn’t mixed together as it was in the original.

        And I completely understand your concern about pieces like this one being ammo for the “never changers.” It’s a tension I feel myself. I try to always thread a needle around such things, but I know I can easily fail to capture the nuance.

        Report


      3. I use Bedrock & Composer, and love it, but I just want to reiterate this point from Scott:

        “Anyone can use Composer to install WP core/plugins AND still be able to update/install either from the admin. Which is why if a developer wants to start a site with Composer and then hand it off to the client, it will work exactly as a normal WP install would (provided they include all the package sources along with it).”

        There really isn’t any downside to using Composer and handing it off to an end user. You can manage the site and deploy using it and the user can still expect things to work “The WordPress Way” if you stop. Heck, I update plugins using the Admin panel if there was an important bug fixed (recently updated BackWPUp because it’s Dropbox integration broke from the panel, actually) and update Composer later.

        So quite frankly, I don’t see there being much of a drawback even for people quickly spinning up a site and handing it over to an end user. The only thing I’d say is it doesn’t really make sense to use it if you’re still new; you should be learning how to develop, not fiddling around with tools (and I’ll admit, early in my learning, I spent too much time fiddling around with tools), but I think that can be said of a lot of things, and it’s not really particular to WordPress development so much as it’s a programming thing more generally.

        Learn the basics before you dive into tools like this.

        Report


      4. > I find myself defensive against attitudes like this in the WordPress world because most people (including WP core devs) are so against new tools and technologies. It’s for that reason that I usually find posts like this more harmful than helpful…

        Amen. You know why most traditional devs hate WordPress? It’s because of things like this. My clients pay me to be a professional and maintain very functional sites with high availability and uptime… To do this I have to adhere to utilizing positive development techniques such as utilization of a package manager.

        I absolutely agree that this post is harmful and caters more to a population of more casual WP developers who would rather not spend the extra time ensuring proper dependency management and adhering to solid/testable/safe practices.

        Report


  4. The way I see it is there are two levels of WordPress development. Casuals and professionals.

    **Professionals** have business-level logic they maintain through the utilization of the WordPress CMS. A good example of this is a WooCommerce shop making tens of thousands of dollars every month. If that site goes down due to my mishandling of a WP plugin/core/theme update, I can absolutely get sued by the client for damages to their company… Rightfully so because due to negligence and poor development practices I have literally closed the doors to their online business and directly effected their potential revenue stream.

    Now, as a professional I have a dedication to testing, maintaining, upgrading, and building products that are secure and functional over time. I have to make sure (via software audit) that any code in which my code relies upon works 100% with the software (ie: website) in which I have published; for money, for my clients. I see it as my responsibility to “marry” my WordPress installations with Composer and use proper development practices such as implementing package management and version control.

    FACT: Anytime I update a plugin, a theme or the WP core I risk introducing issues to my sites. To combat this I track changelogs, audit third party plugin/theme code, have a strict testing policy, fully version control everything on a private GitLab server, do development reviews, implement semantic versioning, adhere to PSR-5/PHPDoc standards (cough as much as possible), do FULL file/DB-level backups before any change, and last (but not least!) implement composer on EVERY project I self-host.

    I do this because my clients PAY me to do it. My clients pay me for consistently working websites that are fully tested, documented, and exhibit almost perfect functionality/uptime. Speaking as a professional – you can take your objection to this marriage and shove it.

    **Casuals** run WordPress because it’s “easy”. Yes – truth be told some of my clients are at this level and prefer to self-host their sites without proper developer management. They pay less for their product because in the long-run I can’t guarantee the functionality of their project over time and allow them to do their own core, theme, and plugin updates.

    Truth is they often run their sites into the ground, or just have general issues managing it. I then end up charging these folks for my full hourly maintenance rate to come back into their project and fix messes caused by software updates/modifications gone wrong. They are the people who can deal with a day or two of downtime if something breaks and I specifically make them sign paperwork that takes me 100% out of the scope of liability as soon as I hand the keys back to them after a project/bugfix/update.

    For these clients yeah, using Composer breaks down. But in the long-run if you’re looking to manage/sell/build a site that needs true high-availability then go learn version control and package management.

    TLDR: Composer is a tricky and finicky gal to be married to but guess what: a stable marriage takes a lot of work and learning. Truth is many people aren’t ready for the responsibility and stability a solid marriage to a worthwhile gal brings. Otherwise if you’re still foolin’ around letting your (almost always less-than-competent) clients touch their WordPress installs in funny places don’t come knocking on Composer’s door. She’s a clean and classy gal, wants a stable man and don’t want no scrubs.

    Report


    1. have to LOL for your definition of “profesional”, by it only people working on multi million dollars projects are professional wordpress developers. The reality is that most (99% ?) of wordpress projects do not require dependency management as they are small in size or just have everything developed by a very small team with little need for dependency management. A true profesional do not use tools that do not benefit a project he is doing, that do not reduce time to market or enhance the quality of his code, just to feel leet.

      Report


  5. I think these two play together very well. I have used them in multiple configurations. I have even handed sites off to clients afterwards and watched them manage it. A developer tool should not prevent the end user from using the site. Its meant to develop with.

    As many have mentioned above, you can still update and add new plugins without using Composer. You can add new themes. You can edit the code. You can do anything you want.

    If the developer comes back and runs composer again after all of this, some of it may be bad news. But for maintaining large sites running automatic updates and deployments through Composer and Capistrano is one of the best things I’ve ever done for my sanity.

    Couple that with a custom Satis build to host your plugins and you can actually support and roll out changes to custom developments.

    No offense, great article understand the point but I completely disagree. Whether we like it or not developers have to work in this ‘user-friendly’ system and make it easy for us to use at the same time.

    Report


    1. Really appreciate you weighing in. As I tried to say, I think if you’re a developer comfortable with it all and running it all top to bottom forever, go all-in on Composer, Capistrano, or whatever tool lets you breathe easier. Your endorsement is genuine and convincing in its value for you.

      It’s the in-between cases — where a developer sort of thinks they should be using fancy stuff but aren’t comfortable yet, where they’re going to leave the site to a non-technical owner, etc — that I was trying to explore. There are a lot of those sorts of situations in the WordPress world, and their place in a discussion of “Composer: yes or no?” is probably most appropriately a “sometimes yes, other times no” answer. That’s where I was trying to get to.

      Report


      1. Yeah, I totally understand. I just have been running Composer and WordPress together in production for quite awhile and am a big advocate. However, as I have experienced some builds are simply not worth using it. Really simply builds don’t benefit from the complexity.

        Report


  6. Are there any plans for adding native support for composer to WP? I’d like to be able to maintain a single copy of certain library files and have all my plugins reference that copy.

    Drupal has a libraries folder for this sort of thing.

    Report


    1. There aren’t.

      I am not sure if you mean private plugins or public. For private this is very well possible already with Composer.

      But for public you’ll have to stick with more traditional development route. You can still use Composer for individual plugin development, but if you ship plugins individually they will each contain copy of dependencies.

      Report


      1. It’s not creeping to anywhere, it’s desperately deadlocked and dead ticket. Forget it.

        Report


  7. I’d like to add a little to this article. One small feature that I find really useful for when developing themes & plugins is the `archive` command. Basically you can archive up the entire project before deployment.

    You can place filename wildcards that should be excluded from the final archive in `composer.json`, and you can run scripts before or after the archive command. This is great since you can opt not include the `vendor` folder, `.DS_Store`, and other configuration files and assets and scripts which are not really needed in the final product.

    Report


    1. Dude. Nice. I’m going to be looking into that actually. One of the more rough parts of my composer workflow is doing the final push to production and this looks like a great way to move a project with compiled assets around. TIL =)

      Report


    2. This is really nice. Doesn’t appear to be a ton of documentation on this, but can’t believe I missed this!

      Report


  8. I recently started learning about Composer, and being a WordPress enthusiast wondered about using Composer to build up a site with the WP core, plugins, and themes. There’s some discussion about adding Composer support to core (https://core.trac.wordpress.org/ticket/23912), but that won’t be resolved too soon from the looks of it.

    There’s nothing preventing developers from doing this on their own. In fact, there has been at least one proof of concept for an external package to do the work – see https://github.com/johnpbloch/wordpress-core-installer for source, and the package on Packagist – https://packagist.org/packages/johnpbloch/wordpress. Something I’m going to be trying out :)

    Report

Comments are closed.