

Version Controlling Wordpress - roybarberuk
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.
======
gesman
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.

~~~
scarecrowbob
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.

~~~
scarecrowbob
As a note, wordpress core is also not part of my repo.

------
celticjames
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?

~~~
natemcguire
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.

------
natemcguire
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.

------
jaredgeorge
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!

------
gandalfar
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.

------
pan69
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...](http://www.lukeschreur.com/posts/configure-wordpress-for-multiple-
domains)

For deployment I simply do an export from SVN on my local machine and an rsync
over SSH to the server (scripted).

~~~
roybarberuk
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

------
cmwelsh
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.

------
hostyle
"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.

------
flexterra
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.

~~~
jonheller
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.

------
agumonkey
Could be used for intrusion detection too.

~~~
camus
absolutely , granted infection doesnt come from a plugin you have installed.

------
brianlovin
I've been putting this off for far too long - thanks for the guide!

~~~
roybarberuk
No problem Brian, the deployment side is not as detailed, but should give some
indication to how it can be used.

