Use WP Bulk Plugin Updater to Automate WordPress Plugin Updates

The general idea behind the program is simple:

That said, it’s tedious work. It’s boring enough if it’s, say, a dozen plugins but what if you’re maintaining a site or headless application that has twice – or even four times – that many?

Verify the site as a repository set up to manage the code (and set it up, if not).
Also verify the repository has wired up to a CI/CD tool so branches, tags, and so on can be deployed across staging, beta, or production environments (and set it up, if not).

The program will also generate two output files: One file tracks the list of plugins that were successfully updated. The other tracks what files need to be manually updated which usually comes in the case of premium plugins.

Create a develop branch off of master
For each plugin update, create a new update/ branch (named something like update/plugin-slug
Perform the actual update
Then commit that branch to the repository.

Regardless of how many plugins you’re dealing with, this strategy allows you to update plugins independently of one another, perform a revert when necessary, cherry pick certain commits to set up a custom release, and so on.

For the last year or so, I’ve spent the majority of my time working on technologies adjacent to what I’ve historically done (case in point), but that doesn’t mean there aren’t times where I’m not still working directly with WordPress.

Recently, I’ve needed to manage a set of servers and sites that needed a round of updates. One of the most common set of updates needed to be performed was updating plugins with known CVEs. The process by which I like to do this is:

Finally, if you use the Bulk Updater and find it useful, open any issues, feature requests, or PRs.

And it maintains good Git workflow practices.

WP Bulk Plugin Updater: Automate Updates

All of this is available in the README in the repository.

I describe WP Bulk Plugin Updater as:

Finally, if you’re interested in running the program but not actually taking any action until you’re sure it’s going to do what you want, then you can use any of the available options:

Find the list of all plugins that need to be updated,
Create a branch for each plugin that’s updated,
Commit each branch to the repository.

Ultimately, it allows you to set up tags or, more generally, revisions for how you want to release your site without having to wait for every single plugin or dependency to have a problem resolved.

WP CLI. This must be installed. The program will verify that it is, in fact, available and will terminate early if not.
Git. This should be obviously, but the program is meant to be run in the root of the WordPress project’s installation (it can run in wp-content as well but I initially designed it to drop into the application’s root directory).
PHP 7.4. This is the minimum version of PHP required (though you’re always going to hear me pushing for 8+).

A PHP tool that automates WordPress plugin updates with individual Git commits, push capabilities, and detailed logging for easy site maintenance.

The program isn’t officially tagged as I’ve been using master for the work I’ve been doing as of late. If it continues to work fine, then I’ll include a CHANGELOG, a proper ISSUE_TEMPLATE, and tag an official version.

Then, the workflow I usually use is, at a high-level, like this: