So, I wrote this article in March of this year, and it is no longer true: It is now possible to do full version control for WordPress deployment. I hope to write about how, soon. Now it’s October. Maybe by 2016 it’ll be easy.
Here’s the old post, anyway:
A client recently asked:
Question for you.
We need to refine our process for pushing content from UAT to Production. Here are our requirements:
- Near-instantaneous updates
- Database downloads quickly. Currently, it takes ~ 20 minutes
- Eliminate the need to download the full database every time. We perceive this as risk mitigation, the potential overwriting and downloading of the database, potentially multiple times a day.
Oh, how I wish I coulda said “No problem!”
The current state of affairs with WordPress deployment is ‘it’s not easy or obvious yet, but getting closer’.
The problem with WordPress:
Over the last couple months I’ve looked for better tools. The problem is this: With WordPress, the database is integrated with plugins and themes, as well as content. Site, theme and plugin settings are stored in the DB. If you update a plugin or a theme or change any setting the DB is changed. So any change that is not done on the live server cannot be kept in sync with any dev server, without copying the live server to a dev server, make sure the live server is ‘frozen’ (no changes allowed), complete the work on dev, and then everything live gets overwritten by dev (or the dev server ‘becomes’ the live server, by pointing the main domain.
The Problem with Databases:
With a database, it’s ‘all or nothing’. There’s no version control tool I’ve ever heard of for syncing changes within a database. Since WordPress ‘mingles’ the content and settings everything fragile during transitions. In addition, URLs (links and images) are stored complete – including the domain, so a dev domain to live requires not just overwriting the DB, but then running a couple queries to change the domain throughout. Ugh!
For several years, I have used a backup program (BackWPup) to dump my live site to DropBox. If I then work on the site locally or on a development server, I can do a backup, copy the wp-content directory, and grab the database dump and import it locally. Then I can make any changes, while freezing changes on the live server. Then I move the changed files back to the live server, and if there have been substantial database changes I replace the database on the live server, if they’re minor changes on the db, I might just repeat the steps on the live server (usually a setting or two).
This is really only suitable for development in large chunks, with major design changes that hit both the DB and the files.
Content changes and additions are always done on the live server. For most people, updating WordPress, plugins and content is all done live, with a backup immediately prior (we hope). Also keep in mind, WordPress may receive priority patches for security without intervention by you.
The Ugly: This is not modern ‘version control’. It’s just what ‘everyone’ does.
There is now an alternative or two…
WP-Engine is a host that allows you to ‘clone’ your live site, make changes to the clone, then push the changes back to live with a couple button pushes… but still the live site must be ‘frozen’ while development is happening.
There is this new tool called “Revisr” https://wordpress.org/plugins/revisr/faq/
It supposedly makes version control simpler. It handles the database, too, even allowing control over syncing some tables, and not others — for instance, the “wp-options” table contains all the plugin, theme and WordPress settings (unless a plugin/theme has its own custom table). If your changes are all content-related, it can be left alone. If the changes don’t touch the content, you can ignore the ‘wp-posts’ table, etc. It’s pretty new with only 8 reviews… but all 5-star reviews.
They should try it repeatedly on a clone dev and a clone live site, before trying it in production. They should develop a procedure that is fully tested and provide that procedure in documentation… why? Because you could easily wipe out content or settings in a permanently destructive way, just doing things in the wrong sequence.
There are some other projects out there, like Gitium,
which is still in Alpha…
But neither of these seem to address the database problem.
…uses Capistrano which I have no experience with… but may also be a solution.
Here’s some further reading that kinda validates what I’m saying: