Articles, Uncategorized, WordPress

Using Composer To Increase Your WordPress Development Powers

In the last few months I’ve been using Composer to improve my development and deployment of WordPress projects. It’s an important tool that is not only easy to use, but also leads to increased code reusability, a reduction in copypasta errors, encourages best practices like using namespacing and autoloaders, and can aid in deployments.

I’ve covered how composer works in my posts for Torque on the subject already. But, in this post I wanted to just briefly go over the various scenarios in which composer is useful and how it can improve your life, and increase your personal powers as a developer and a human being.

If you are new to Composer, I recommend that you read my Torque posts on it. So far I have written an introduction to using Composer with WordPress and a guide to improving WordPress plugin development with Composer.

Improved Site Deployments

One of the trickiest things about moving between a development and production site is dealing with the parts of the project that do not belong in version control. Sometimes you end up with all of your plugins, and WordPress itself in the Git repo you use for the site.

This is, objectively speaking, an absolutely terrible idea. Why should you write every change to WordPress or a plugin to your Git history? That makes no sense. Use version control to track changes to code you are changing and no other code.

For HoloTree, we have a Git repo for building the live and development sites that establishes the structure of the site. It includes wp-config, my VVV config and a few other things, but does not include any plugins, the theme or WordPress itself. All of that gets pulled in by Composer.

Mark at Kinsta helped me set up to automate the process. Since connects to my server via SSH, it is able to run composer update for both the main repo and the plugins that power HoloTree, each of which pull various libraries.

This is all made easy by the fact that every plugin in the plugin and theme repositories are automatically available as a Composer package, thanks to wpackagist.

Update: I created a git repo that has everything set up for new WordPress site development using Vagrant, and my preferred way of using Composer for dependency management.

Sharing Code Between Plugins

As you go through life, you will find yourself developing repetitive patterns you like to use in all of your plugins. That’s great, unless you are cutting and pasting those patterns between projects.

Moving the classes and collections of functions you use for a part of a project into a Composer library is a little bit of extra work. You will see a return on investment for that small amount of work the first time you use the library again. When you fix a bug in the library and are able to easily share the change across all projects using that library… well that’s just awesome.

Using Other People’s Libraries

Packagist, GitHub and the internet at large are full of great libraries that you can pull into your plugin or other project using a dependency manager like Composer or NPM. Using a dependency manger makes doing so both easy to do and easy to keep up to date.

If you ever wanted to use a piece of another PHP framework, say for example Symphony, Composer makes it easy. Also, some talented WordPress developers publish libraries on Packagist. For example, Mark Jaquith, Andrey “Rarst” Savchenko and Eric Mann.

Of course, a package doesn’t have to be on Packagist. If it has a valid composer.json file, you can pull it directly from GitHub.

Composer Libraries Are Git Repos!

Note: I know they could be SVN or whatever repos, but using anything besides Git is, objectively speaking, silly.

Let’s say you have a plugin constructed of several Composer libraries, and one file with the plugin header and a function to include the autoloader. First off, great victory, you win a _doing_it_right() award in my book. You might be worried about having to maintain separate checked out version of the repo to commit changes to.

This is not the case. When Composer pulls in a package, it includes the .git file and sets the remote origin properly. If you have write access to the repo, you can simply CD into the package’s directory and commit and push like any other Git repo.

No New Copypasta!

copypastaDon’t Repeat Yourself (DRY) is one of the most sacred principles of programming for good reason. Cutting and pasting the same code between files is an equal, if not greater violation of this important principle.

Not making your code easily reusable for the benefit of yourself and others makes your life harder. Further, it robs you of the ability to help others while promoting yourself.

So stop.


Featured Image by:  Lance Anderson via Unsplash


  1. Thank you for this post. I just started looking to switch a site to Composer. I also use and would be interested what configuration that you are using.

    How do you handle updates? For example while I was updating WordPress with Composer the site was down as Composer was fetching all of the files.

    • Ulrich –

      I’m careful about when I do it. OK, that’s a bad answer, good thing is running Composer Update via Grunt is easy. That means I could be using Grunt to move the file into place that puts the site into maintenance mode, then run Composer Update, and then take it out of maintenance mode.

      Hope this helps,

      • You shouldn’t run `composer update` on production. You should run it locally and be as explicit as possible in your dependency versions. Then, commit your composer.lock file to production and run `composer install` instead of `update`. This way, the packages composer checks out will be locked to the versions you are developing with. For example if you have a dependency “1.0.*” you could be using v1.0.2 locally, but 1.0.3 in production, which is bad for obvious reasons. Using `composer install`, production is locked to the same versions as what you are developing with.

  2. Thanks for the great write up Josh! I’ve been a WordPress power user and blogger for a long time now. This year I’ve decided to actually get into the development side of things too. I’m sure I’ll be using Composer in the near future.

Leave a Reply

Theme by Anders Norén