WordPress’s automatic core updates feature is an amazing boon to security. The WordPress core team is quick to squash vulnerabilities as it is, and automatic core updates mean that potential vulnerabilities are resolved on your own site before you even know they exist.
WordPress updating itself does create a challenge in git workflows though. The main problem is that typical git workflows can be broken by code changes taking place on a production server.
In a typical git workflow, all code changes are made and tested locally, ideally I’m a separate development branch. Once determined ready for production, the development branch is merged into the master branch, which the production server is set to. A
git pull is done on the production server and the new code is in production. Ideally another intermediary branch and environment for staging also sits between development and production.
develop (local computer) => staging => master (production server)
If code changes take place on a production server though, this system breaks down somewhat. But it doesn’t have to.
Making it work
This site actually does use WordPress’s automatic core updates, as well as git in a tidy development -> production workflow. Core updates itself in production, all development takes place locally in a
develop branch, and it’s smooth as butter. Here’s how:
No single repo for the entire site
There’s no real need for me to keep WordPress core files in version control. I’m never going to edit them, and excluding them from git allows for core files to change automatically without needing to commit changes to a private repo.
Instead of a single site repo, I have a repo for the theme itself, which happens to be on GitHub.
Site plugin repo
Similar to the theme repo I also have a separate repo for the site plugin, used for defining custom post types, taxonomies, and other non-theme-specific site functionality. This repo is also on GitHub.
Optional plugins repo
Although this can all work by replacing the single site repo with two repos, for the theme and site plugin respectively, I’m also using a third private repo for transferring plugins used on the site. This allows me to test plugins locally before committing them to
master. I’m not completely sold on this third repo, and an alternative could be testing plugins locally and installing them separately in production with WP-CLI. I figured I’d mention this plugins repo anyway though since I am using it, and it is working for me for now.
If you’ve been holding out on automatic core updates on account of git workflows, I recommend trying this strategy. It has been working well for me, and this site is a lot more secure for it.