One of the reasons I’m fond of static site generators like Jekyll is that they allow developers to use version control systems, such as Git. The development files and the site itself are plain text, so it’s easy to keep a complete record of any changes and to use development workflows like feature branches — not to mention the benefits to collaboration.
Static sites have a limited user-base and they aren’t suitable for non-technical users or complex publishing workflows. That’s where content management systems like WordPress take over. WordPress is easy to use for non-technical publishers and companies, but WordPress makes it difficult to use version control systems.
The problem with version control in WordPress is that WordPress sites aren’t just files — they’re files plus a MySQL database. Merging two different versions of a MySQL database is difficult, to say the least. Version controlling databases from outside of the database layer is a complex problem, which is why version control systems for WordPress are rudimentary at best.
At least, they were until now. With the release of VersionPress 2, WordPress developers and users have access to comprehensive version control — including version control over the database.
In case it’s not clear how that benefits WordPress users, consider this example. Your company website is having its theme updated, but the site owners don’t want to do the update on a live site — all sorts of things could go wrong. They create a copy of the main site to use as a staging site. Copying a WordPress site is relatively easy.
Development goes ahead on the staging site, including changes to the site’s sales copy, images, and layout. In the meantime, several articles are published onto the live site’s blog.
When the work on the staging site is complete, there’s a problem. The developers can’t simply copy the staging site and make it live, because then the blog articles on the live site will be lost. Nor can they easily move the contents of the live site to the staging site — the databases don’t match any more. The solution is to port the changes from the staging site to the live site manually, which is a time-consuming task.
This is a problem faced by software developers all the time and version control developed — in part — as a solution. If a developer wants to add a new feature to an application, they create a branch of the project. A branch is similar to our WordPress staging site — it’s a complete copy of the project. They make their changes to the version in the branch, and when they are finished, they merge the new branch back into the main branch. The version control system will take care of the merge, and the developer will only have to manually deal with direct conflicts between the branches — if the same bit of code has been changed on both branches.
The process is much faster than our hypothetical WordPress staging site example — so fast that branching and merging become part of developer’s everyday workflows.
VersionPress 2 is impressive because it can carry out version control operations of the sort discussed here on an entire WordPress site, including the database, making the version control-centered workflows available to WordPress site owners. With VersionPress, creating a staging site is simply a matter of cloning the live site, making the changes, and then merging the copy back into the main site.
I’ve focused on one benefit of version control in this article, but there are many others including fast rollbacks to previous site versions, “undo” for plugin and theme installations that go wrong, and easier collaboration between team members.
It’s worth noting that these features are available only on the command line at the moment, but the VersionPress team intend to release a graphical interface in the near future.
If you manage a WordPress site and want to enjoy the benefits of version control, VersionPress is well worth consideration.