Year: 2018

Updating WordPress with Composer and WP-CLI

The other day I came across this blog post by Mark Jaquith, who is one of the lead contributors to WordPress, in which he describes his process of updating WordPress plugins with WP-CLI and Git.  I think a lot of people these days are trying to use Git for version control and automate their deployments, so WordPress developers aren’t an exception, and Mark’s post is a useful resource for that.

With that said, however, I think there is a better.  At work, we’ve been dealing with quite a few WordPress-based projects, and automation of builds and deploys is very important to us.  So we’ve taken a different approach.

The initial inspiration for our approach was taken from this blog post by Scott Walkinshaw of the amazing Roots team.

Yes, that’s right, we use Composer to manage the WordPress, plugins and themes, both during the initial installation and the upgrades later.  But we’ve taken it a step further by also integrating the WP-CLI to our setup, which you can find in our project-template-wordpress GitHub repository.

I have oversimplified both the development and deployment process below, mostly for clarity.   (We do a lot more automation for our needs.)

During the development:

  1. Configure Composer to install WordPress into the webroot/wp folder.
  2. Configure Composer to install plugins and themes into webroot/wp-content folder. (Notice: we use a different wp-content folder location from the default WordPress one).
  3. Adjust wp-config.php for the new paths and drop it into the webroot/ folder.
  4. Add Composer’s vendor/ folder, and both webroot/wp and webroot/wp-content to .gitignore.
  5. Add all required themes and plugins to the composer.json.
  6. Run composer update to create or update the composer.lock file.
  7. Commit both composer.json and composer.lock, as well as .gitignore and any other files you modified.
  8. Add a WP-CLI script that automates activation of plugins and sets the current theme.
  9. Push your changes to the git repository.

During the deployment:

  1. Clone or pull the changes from the git repository.
  2. Run composer install to fetch and install specific versions of WordPress, plugins, and themes, from the composer.lock file.
  3. Run the WP-CLI script to finalize the installation or update with the plugin activation, theme selection, etc.

While it might look a little bit more complicated than what Mark and Scott described in their respective blog posts, I think this is a better approach for the following reasons:

  1. Use a specialized tool to solve each problem.   Git is great for version control, so that’s what it should do.  Composer is great for managing dependencies, and that’s what WordPress and its themes and plugins are for your project.  WP-CLI is great for automating WordPress tasks.
  2. Keep the git repository clean and simple.  When working on a project, we never ever modify the code of the WordPress or any of its themes or plugins.  And our setup enforces this approach.  If you need to change the WordPress source code for a particular project, you are probably doing something wrong.  If you need to change the plugin’s source code or the theme’s source code, you are probably doing something wrong again.  Instead create child theme or your own version of the plugin and install those with Composer, keeping the plugin or theme related code changes in a separate repository.
  3. Easily extendable and customizeable.  Git, composer, and WP-CLI are great tools and we love using them.  But the world is moving forward and there are constantly more and better tools to help with the complexities of the web development.  Our setup expands and extends to welcome any tools that we find useful.  For example, we have integrated with Robo, PHPUnit and PHP Code Sniffer, TravisCI, BitBucket Pipelines, and many other tools over time.  We’ve also said good bye to a few that became obsolete or to which we found better alternatives.

Anyways, project-template-wordpress works quite well for us and I hope you’ll find it useful.  Give it a try and let us know if you find any issues or improvements.   Pull Requests are welcome. :)

Oh sh*t, git!

Oh sh*t, git! is a collection of git problems, their solutions, and some explanations of how that happened and how to get out of it.

Git is hard: screwing up is easy, and figuring out how to fix your mistakes is f*cking impossible. Git documentation has this chicken and egg problem where you can’t search for how to get yourself out of a mess, unless you already know the name of the thing you need to know aboutin order to fix your problem.

money – PHP library to make working with money safer, easier, and fun

money is a PHP library that implements Martin Fowler’s design pattern for money.  See the official documentation and this blog post for more information.

Some of the issues addresses by this library are the binding of the money amount to the currency, and currency conversion operations.  If your code needs to deal with multiple currencies, you’ll definitely benefit from this library.  But even if you are dealing with a single currency, it’s still pretty handy, making the code more transparent and future proof.

Web Developer Roadmap

I’ve been saying for years, that there is no such thing as a “full stack developer”, no matter how many CVs your HR department processes per day, matching the title.  Web Developer Roadmap is a cool little GitHub repository, which maps the road for becoming a web developer in 2018.

It shows technologies that you need to get familiar with, depending on what kind of a web developer you want to become – front-end, back-end, or DevOps – and how to organize your learning and move from one technology to another.

The reason the “full stack developer” isn’t there, is, I’m sure, because that just combines all of the other ones.  And each one of them is way more than can fit into a single human head.  So the combination would probably make it explode.

Even if you are already an experienced web developer, this roadmap is a handy thing to keep around, as it gets updated as things change.  And in web development things do change, and they do so frequently.

SQLBolt – Learn SQL with simple, interactive exercises

SQLBolt is by far the best SQL tutorial that I’ve ever seen!  Yes, I know, it’s a very bold statement.  But I promise that it’s true.

With hundreds of books, videos, and other tutorials around, the problem of delivering the understanding of data management, databases, and SQL to regular people still hasn’t been sold.  But SQLBolt provides a giant leap forward in this area.

The tutorial starts from the very basics and gets progressively more and more advanced.  But this progression is divided into small, very focused chapters.  Each chapter provides a brief description of the concept, an example query for the concept, and a set of exercises.  The exercises are all interactive, so that you don’t have to install a database or get access to a real one, and you don’t have to trust yourself on correctly solving the tasks.  The interactive exercises system marks the problem as solved the moment you type in the correct query.

If you get stuck at any point with any particular exercises, just click on the Solution link nearby, and the tutorial will show you the correct answer.  I found this to be a perfect balance between forcing the reader to try things out, but without the annoying delays for those of us who like to skip ahead.

There is really no reason now for anybody at all to learn SQL.  SQLBolt is brilliant!