Updating Themes and Plugins (for entire WordPress site)

In last chapter, we saw how to add theme and plugin dependencies to WordPress project using composer.

Like WordPress core, many themes and plugin releases updates from time to time. So we need to keep our composer.json updated.

Fortunately, composer allows us to specify versions in many ways, which will avoid need to edit composer.json file after certain updates. You can read this composer version guide for details.

Here, we will see managing versions with an example.

Problem (with example)

Following is a sample code for nginx-helper plugin version 1.9.3.

    "require": {
        "wpackagist-plugin/nginx-helper": "1.9.3"
    }

In above example, we are using specific version. This means when 1.9.4 or any other update comes, we will need to edit composer.json again and again.

Just imaging doing for 50+ plugins many WordPress projects have!

Workaround

We can specify range as well as use wildcard "*" which will fetch latest version. But using wildcard is not recommended as we can end up upgrading to a version which is not backward compatible, thus braking our site.

When adding packages using composer require command line version, you may omit version number and composer will pick latest version with patch-level update support.

During manual edit to composer.json, instead of 1.9.3, we can use ^1.9 which will give us update till 2.0, which are unlikely to break.

If WordPress theme/plugins are following semantic versioning, specifying version names this way can worj out really nice.

composer.lock and versions

Although, range/wildcard versions can remove need to edit composer.json file again and again, we need to update composer.lock file by running composer update.

Continuing with above example, say composer downloads nginx-helper plugin version 1.9.3, which is latest at the time of writing this post, it will put that version information in composer.lock file.

So when version 1.9.4 releases, on a new (remote/production) server, composer install will download 1.9.3 – a version specified in composer.lock file.

We need to run composer update first, which shall update composer.lock and then git commit/push update composer.lock file to remoter server. After that running composer install will fetch 1.9.4 as expected.

The entire workflow looks like this:

1. Updates are available
2. Run composer update locally or on dev/staging server. This will update composer.lock and download updates locally.
3. Test – usually this can be automated using CI (continuous integration) tools.
4. If test pass, git commit/push changes to composer.lock
5. On remote server (e.g. production), changes to composer.lock will be pulled followed by composer install. This is usually automated using git + webhooks.

The entire process can be automated if you have a robust test coverage for your WordPress project.

Note for theme/plugin developers

If you are using your own WordPress theme and plugins published on wordpress.org for a client project, and if you need to do a public release, you may notice that new version is not readily available on wpackagist.org which syncs hourly!

So you may wait for an hour to run composer update which can get frustrating. In this case, it’s better to add your own theme and plugins to composer project using VCS repository method.

As a developer, you can consider adding composer.json file to your own project. We will describe this in detail in next chapter.