Version Controlling Wordpress

Nice tut on git. Although not very real-world practical in case of Wordpress.<p>First - wordpress core does version control itself and offers one-click update for core files that are updated frequently.<p>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...).<p>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.<p>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.<p>This allows you to accomplish two <i>very important things</i> (that git does not do):<p>1. You may restore complete website from scratch in minutes - including full database structures.<p>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.<p>That's a perfect tool for the job.<p>Thanks for putting tutorial though - I love git and use it often for separate projects.

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.<p>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.)<p>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?

We've struggled with this quite a bit at our company (<a href="http://thesiteslinger.com" rel="nofollow">http://thesiteslinger.com</a>). 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.<p>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.<p>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.

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 <i>both</i> downstream and upstream.<p>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.<p>Great post!

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:<p><a href="http://www.lukeschreur.com/posts/configure-wordpress-for-multiple-domains" rel="nofollow">http://www.lukeschreur.com/posts/configure-wordpress-for-mul...</a><p>For deployment I simply do an export from SVN on my local machine and an rsync over SSH to the server (scripted).

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’m presuming you have ssh &#38; 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.

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.

Could be used for intrusion detection too.

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