I develop themes, lots of them. I am given a PSD, code up the HTML/CSS, slap the code into Wordpress, and make corrections as they get QC'd. Once live, clients can edit blog posts like normal or upload photos using a custom plugin.

Sometimes I have to make changes to the theme or to the page/post content, which means I either make them live or have to download and setup the site to a development environment to be approved by the client. I have no backup, I have no version control, and I realize this needs to change.

Git and Mercurial have been suggested, and I would like to take advantage of these tools, but I am confused about how to fit them into a workflow.

Do I require all changes to a site on a development server and then push them live once approved? What about writing blog posts? Seems like overkill to write posts on dev and push the changes live, but then how do I sync the databases if they are edited on the live site? I have scoured the internet. Some guidance would be appreciated.

  • I think this qualifies as an out-of-scope ecosystem question. See here for ongoing discussion. Commented Feb 9, 2012 at 17:47
  • 4
    @ChipBennett I disagree. WordPress’ specific dependencies between themes, plugins and database and how they affect general developer practice are welcome.
    – fuxia
    Commented Feb 9, 2012 at 18:09
  • @toscho I could certainly be convinced of that; that's why I pointed to the Meta discussion. :) Commented Feb 9, 2012 at 18:12

3 Answers 3


First of all, you need to recognize that there are two workflows here: yours and your client.

Your Workflow

  • Receive PSD
  • Code HTML/CSS
  • Code WordPress template
  • Deploy theme to live WordPress site

Their Workflow

  • Devise required changes and email you
  • Write posts
  • Upload photos

The Issue

Implementing version control here has absolutely nothing to do with your clients' workflow. It's all about keeping track of the code you use for the WordPress theme. All of your theme files, custom plugins, etc should be in a version control system (Git, Mercurial, Subversion, or whatever you choose to use).

Your workflow then becomes:

  • Write code
  • Commit changes to version control system
  • Push changes to production site
  • Get comments back from client
  • Write code
  • Commit changes
  • Write code
  • Commit changes
  • Push changes to production site

Remember, this is about maintaining a version control history for your code. Code is something your clients shouldn't be changing - and you should never change the code on a production site while it's in production.

But changes to content (posts, photos, etc) are outside the scope of your version control system. In other words, you don't make changes in development and then push the database out to production. That's a poor development practice. If you need the dev and prod databases to be in-sync, then you should routinely pull a backup from the production box and restore your local version from that backup.

Code changes flow from development to production.
Database changes flow from production to development.

  • You can't really sync the databases easily unless you have a special script that manages how the content data is stored in the database. That is why you seperate code from content in your workflow, the alternative is to use a staging server or try and use one of the db syncing scripts or write your own.
    – Wyck
    Commented Feb 9, 2012 at 18:40
  • @EAMann Great response, thank you! The only thing I would add to the workflow you described would be to write code, commit changes, push to development site, get comments back from client, ... I hadn't considered two separate workflows because regularly we will have to change the content ourselves for the clients. Occasionally we'll have to put HTML in the content to accommodate for special requests within the content (special styles, etc). Sometimes they require client approval before going live, which is why the databases would need to sync. Are there best practices for this kind of setup?
    – cfree
    Commented Feb 9, 2012 at 18:41
  • @Wyck Rather than dropping content alongside the theming, it makes sense to separate the two processes. I like the idea of a dev area for theming and a staging area for content dropping independent of each other. The only issue I see is that clients like to see both the theme and the content (the site in its entirety; static pages) prior to launching it live.
    – cfree
    Commented Feb 9, 2012 at 18:59
  • It's not usually a matter of syncing database changes. What I meant to say is that you take a dump of your production database and replace your local development database with it. True, you can automate it with a script ... but you likely won't be doing it very often.
    – EAMann
    Commented Feb 9, 2012 at 19:01
  • 3
    There is not yet, is it really a thorn in the side of WordPress but not specifically a WordPress issue as many CMS's have this problem, you can read about it here wordpress.stackexchange.com/questions/119/… more in depth, some scripts do exist out there but most of them are in house because they are specific to a certain environment.
    – Wyck
    Commented Feb 9, 2012 at 19:34

You can use software that syncs the databases. But there's also the option of versioning the data itself with something like http://chronicdb.com

  • This looks interesting; may solve quite a few of the issues. I'm going to check this out, thanks.
    – cfree
    Commented Feb 13, 2012 at 22:12

I just wrote up a thorough answer to this on another question. Personally I use git and it's fantastic. In terms of getting started with it, I'd recommend checking out http://gitref.org/ and http://help.github.com/mac-set-up-git/. If you're the book type, I've read this one and it's definitely worth the $22 ebook price. Make yourself do it, you won't regret that decision.

  • Thanks, I'll have to refer back to it. The master/slave database setup sounds interesting. Thanks for the guidance
    – cfree
    Commented Feb 13, 2012 at 22:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.