Version Controlling Wordpress(roybarber.com)
roybarber.com
Version Controlling Wordpress
http://roybarber.com/version-controlling-wordpress
A lot of friends of the web asked how i usually work with Git + WordPress, so i wrote this to show the structure and steps I take to setup WordPress locally, version control and then deploy to a live server with Git. Avoiding the need for ‘Cowboy Coding’ and a fully backed up version of your website.
20 comments
How do other people keep databases in sync between multiple developers and the production server? Source code is easy. Source control and code merging are mostly straightforward.
But in something like wordpress, a lot of what gets displayed to the end user is in a database. Aside from page content, widgets and other configuration often ends up in a database. It's not unusual for themes to keep css, javascript or php in the database. (Every time I use a theme that allows me to put PHP into a database I feel like I've failed as a programmer and the gods of MVC will smite me.)
So developer X adds content to his dev copy. Developer Y adds content to his copy. Meanwhile, the client or end users are adding content to the production copy. Using a shared development/staging server somewhat mitigates this, but not totally. You can't just git merge the sql together. (Can you? I mean, sure you can merge two sql files. But is the end product actually usable?) Is this a solved problem?
But in something like wordpress, a lot of what gets displayed to the end user is in a database. Aside from page content, widgets and other configuration often ends up in a database. It's not unusual for themes to keep css, javascript or php in the database. (Every time I use a theme that allows me to put PHP into a database I feel like I've failed as a programmer and the gods of MVC will smite me.)
So developer X adds content to his dev copy. Developer Y adds content to his copy. Meanwhile, the client or end users are adding content to the production copy. Using a shared development/staging server somewhat mitigates this, but not totally. You can't just git merge the sql together. (Can you? I mean, sure you can merge two sql files. But is the end product actually usable?) Is this a solved problem?
you would probably need to do something along the lines of creating a sql.diff file that has the difference between production and local database and then ONLY inserts into the production database so you don't overwrite changes that have occurred since you started working locally.
This is something that could be written but really would only be worth it for someone that does a ton of WordPress development...definitely an interesting problem.
This is something that could be written but really would only be worth it for someone that does a ton of WordPress development...definitely an interesting problem.
Maybe a database with immutable data, like datomic?
I've been putting this off for far too long - thanks for the guide!
No problem Brian, the deployment side is not as detailed, but should give some indication to how it can be used.
Nice tut on git. Although not very real-world practical in case of Wordpress.
First - wordpress core does version control itself and offers one-click update for core files that are updated frequently.
Second - wordpress website consists of ever updating database (that is hard to version control) + set of custom files (like custom plugins, themes, uploads, images, media, etc...).
It does not really make sense to version control wordpress-based website although it makes perfect sense to take care of backups, especially comprehensive off-site backups in case of hack-attack or crash.
For that I use backupbuddy plugin (not affiliated, just grateful customer). It allows you to automatically create unattended, complete, compressed backups for your whole website: core files + your files + database. All in one piece - without you lifting a finger. Plus it auto-uploads your regular backups to chozen destination like amazon S3 or another FTP server and allows you to keep, say, last 10 backups.
This allows you to accomplish two very important things (that git does not do):
1. You may restore complete website from scratch in minutes - including full database structures.
2. You may copy your website to different domain and it will automatically update all URL's from old to new URL - again - in minutes.
That's a perfect tool for the job.
Thanks for putting tutorial though - I love git and use it often for separate projects.
First - wordpress core does version control itself and offers one-click update for core files that are updated frequently.
Second - wordpress website consists of ever updating database (that is hard to version control) + set of custom files (like custom plugins, themes, uploads, images, media, etc...).
It does not really make sense to version control wordpress-based website although it makes perfect sense to take care of backups, especially comprehensive off-site backups in case of hack-attack or crash.
For that I use backupbuddy plugin (not affiliated, just grateful customer). It allows you to automatically create unattended, complete, compressed backups for your whole website: core files + your files + database. All in one piece - without you lifting a finger. Plus it auto-uploads your regular backups to chozen destination like amazon S3 or another FTP server and allows you to keep, say, last 10 backups.
This allows you to accomplish two very important things (that git does not do):
1. You may restore complete website from scratch in minutes - including full database structures.
2. You may copy your website to different domain and it will automatically update all URL's from old to new URL - again - in minutes.
That's a perfect tool for the job.
Thanks for putting tutorial though - I love git and use it often for separate projects.
Thanks for the feedback, I too used to use backup buddy, but found this way the quickest for deploying different branches to different sit-ups, an example would be dev/staging/live.
I agree it could be overkill to version control the full Wordpress install, but I prefer to have instant roll back if a update goes wrong.
Can backup buddy now deploy a backup via ssh? For locked down servers
I agree it could be overkill to version control the full Wordpress install, but I prefer to have instant roll back if a update goes wrong.
Can backup buddy now deploy a backup via ssh? For locked down servers
I use a method very similar to the one in the tutorial to manage development on a site that I've been developing features on for the last six months. Basically the site is the MVP for a proudct that is being redeveloped in another system, but for the time being, they just want to push out features to see how well they work, and so... WordPress.
So I am sending out revisions to custom plugins and the theme daily, and for me there is a great advantage in that I can just push to my production environment and not have to do all the annoying things that I used to do as far as uploading files via FTP.
Generally, I have the uploads directory outside of the repo, and so if I need to sync up my local version to the site I will pull the uploads directory down and create another version of the database, and then update my local config file.
This is a very different use case than backing up the site (but obviously that needs to be possible as well). But git is very helpful in my case as well.
So I am sending out revisions to custom plugins and the theme daily, and for me there is a great advantage in that I can just push to my production environment and not have to do all the annoying things that I used to do as far as uploading files via FTP.
Generally, I have the uploads directory outside of the repo, and so if I need to sync up my local version to the site I will pull the uploads directory down and create another version of the database, and then update my local config file.
This is a very different use case than backing up the site (but obviously that needs to be possible as well). But git is very helpful in my case as well.
As a note, wordpress core is also not part of my repo.
In my experience it's enough to version control custom parts of wp-content (you theme, your un-published plugins) as everything else is better left to Wordpress one-click updater.
I'm kinda intrigued by the way different settings for different domain are handled. I'm using the following approach:
http://www.lukeschreur.com/posts/configure-wordpress-for-mul...
For deployment I simply do an export from SVN on my local machine and an rsync over SSH to the server (scripted).
http://www.lukeschreur.com/posts/configure-wordpress-for-mul...
For deployment I simply do an export from SVN on my local machine and an rsync over SSH to the server (scripted).
I've used the same approach before, you can also do it by setting the environment within apache. But this was the simplest for multiple developers who wold work on the same repo
We've struggled with this quite a bit at our company (http://thesiteslinger.com). Much of our web development business includes WordPress...We host most of our client sites on WPEngine so the git push feature has made a lot of it easier but keeping your .sql files versioned correctly from live and local development is a pain, to say the least.
I would disagree that everything can be left up to the one click updater, versioning it all is important. That assumes you aren't creating complex functionality on your site, so no updating tables, custom development or anything that changes more than views.
It will be interesting to see if WordPress can continue to improve and grow and get new users. From a growth perspective it seems more and more like wordpress:php as rails:ruby, bringing people to the platform en masse.
I would disagree that everything can be left up to the one click updater, versioning it all is important. That assumes you aren't creating complex functionality on your site, so no updating tables, custom development or anything that changes more than views.
It will be interesting to see if WordPress can continue to improve and grow and get new users. From a growth perspective it seems more and more like wordpress:php as rails:ruby, bringing people to the platform en masse.
At this time my comfort zone is managing each theme and plugin as a separate Git repository and using WP Engine to rollback if I break anything during a WordPress/theme/plugin upgrade. WordPress is just upgraded using the 1-click upgrade, and plugins are upgraded using 1-click if they're on the official repository.
I do version control on my themes. What I ended up doing is having a repo outside the web server and setup a post receive hook that checks out the latest version to the actual public folder.
Same here. I'm not sure I see the need to version control the entire Wordpress install, seems like it makes things a bit messy.
Thanks! This gave me some great ideas for how I can use this method in my own deployment process. The only exception is that many times I need to sync content both downstream and upstream.
For example, in one case I want up-to-date content from production down into dev for an enhancement I'll work on. In another case I'll want to create content in dev before publishing on production. Most of the time I actually do have domain specific URLs in the content so I'll need to use a different method to migrate content between environments.
Great post!
For example, in one case I want up-to-date content from production down into dev for an enhancement I'll work on. In another case I'll want to create content in dev before publishing on production. Most of the time I actually do have domain specific URLs in the content so I'll need to use a different method to migrate content between environments.
Great post!
"I’m presuming you have ssh & root access to the server" - is might be a good idea to start the article with this sentence, rather than ending with it, as the entire story depends on it.