A look at WordPress source control strategies
In this post we are going to look at the benefits, available tools and a few common patterns to use source control with a WordPress powered website.
Source control is quite a generalisation. There are many source control implementations. The two biggest are GIT and SVN.
For the purposes of this post we are going to be talking about GIT as a source control tool, after all it’s in our name.
What are the benefits
If you are a single administrator of a WordPress website, source control allows you to maintain a single source of truth for your website’s files. In case of problems it provides the ability to “revert/rollback” changes and it allows you to review the history of file changes.
Additionally with branches, tags and commits you have fine grain control and authority on changes to be made.
For mission critical Websites with development/staging environments, you can selectively apply changes and review before “merging” into the production codebase.
Source control really shines when working in larger teams. It enables easier collaboration and mechanisms for applying outside changes to your own work. Conflict resolution is provided with diffing tools to review and apply.
When twinned with a source control provider like Github, Gitlab, or Bitbucket you have additional features like Pull Requests and issue trackers to cross reference changes with bugs whilst giving project maintainers control over which updates are applied to main branches and when.
For WordPress specifically, source control can remove the variability of WordPress core, plugin and theme updates. For most WordPress websites there are third party files operating your website, and depending on your update strategy these changes may be out of your control.
VersionPress treats your site file and its database as one and source controls everything. This takes the concept of GIT and brings it into the WordPress admin area. Instead of GIT being used as a background process to manage the state of your website files, VersionPress turns your whole website including content and settings into a GIT repository.
WP Pusher is more traditional and looks specifically at individual plugins or themes. It provides the ability to install or update directly from a GIT repository, with features to choose a specific branch to use.
WP Rollback takes a defensive approach and utilises source control to rollback plugin or theme updates directly from WordPress repositories.
Common source control approaches
Although some of the tools mentioned above do more than source control your files, in this section we are going to focus on WordPress file source control.
We are also going to look at these patterns from a “pull changes” perspective. This means the website is only updated from source control. The website doesn’t “push changes” back to GIT.
Source control everything
This pattern takes your website files, including WordPress itself and commits it to source.
Using this approach, core, plugin and theme updates should be turned off within the administration area.
The advantages of this are that everything, even down to the specific WordPress version, is static and controlled. For mission critical sites this could be the right approach as it leaves nothing to chance.
Unfortunately this advantage is also its disadvantage. WordPress core updates can be applied automatically for good reason. Updates may include security patches to protect your website and without automatic updates, you would be responsible to ensure WordPress is always up to date.
Source control the
This is a common approach and provides an advantage over the first method. Using this approach WordPress core updates are usually turned on to ensure a secure system.
This pattern also provides some flexibility. For example you may choose some highly trusted plugins or themes that can be automatically updated. For this to work without your Website and GIT becoming divergent you can “ignore” certain files and folders from source.
Excluding any ignored files or folder (or uploads) everything within your
wp-content directory would be controlled. This would mean themes and plugins would only be updated when they are updated in GIT.
A disadvantage of this approach is that updates would require manual intervention. You would need to apply the updates in source and pull them to your website.
This approach provides protection against incompatibilities between plugins and themes. It doesn’t safeguard against WordPress core updates. However, WordPress has a long and positive history on unknown breaking changes for core updates, so it is suitable for most scenarios.
Source control per plugin/theme
This approach does not source control your website in any way it controls a particular plugin or theme. You could use this approach along with some of the tools mentioned earlier to manage individual parts of your website.
This approach won’t provide you any safeguards against future update compatibilities as the pattern is concerned only with the plugin or theme it controls.
What about the
In all of the patterns above you would not source control the
uploads folder. Unless you're using a tool like VersionPress, this content is directly related to the contents of your database. This content is also ever changing via administrators so whenever new uploads are created your website and source control would be out of sync.
Where does WP Git Updater fit in?
WP GIT Updater is designed to make the first two patterns (source control everything, source control the
wp-content folder) much easier to manage and maintain.
WP GIT Updater will automate branch and pull request creation for any updates available, from the WordPress plugins or themes repository.
It can automate this process via manual invocation, or via a schedule defined within a continuous integration environment (for example Github Actions).
What this means in practise is once in place, every day (or a schedule you define) you can take advantage of your CI system to reduce developer hours performing updates.
To “make an update” on a source controlled website the steps usually involved are:
- Pull down the source
- Review each plugin/theme for updates (either via a local environment, or manual searching)
- Perform each update
- Add the update files
- Commit the changes
- Push the changes to a branch
- Create a pull request for review
These steps may take a seasoned developer only a few minutes for each update, but a website may have many updates, especially if the task is performed infrequently.
WP GIT Updater automates this process for you. What’s more, each update branch and pull request will have consistent naming, version
to details, and any author provided changelog added to the pull request for review, eliminating a low complexity but time consuming task.
Originally published at https://wpgitupdater.dev on December 14, 2020.