Month: March 2018

HTTP/2 Server Push with PHP

A few days ago I blogged about the exciting news from the Nginx about the support for HTTP/2 Server Push.  It’s good to see that this is getting picked up pretty fast.  Here are a couple of examples:

Mainstream support and implementation alternatives are not too far away, and that’s super exciting.

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.