WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on improving my git workflow as it applies to my WordPress development projects. Often, when developing a content management system, I'll create a development server (like http://dev.finalsitename.com) containing the custom post types and taxonomies that will be used in the production version. This allows my client to begin adding their content to the site.

While they are working on this task, I'm usually building out the look and feel as well as the custom programming/plugins that will be used on my localhost environment. To ensure that I don't overwrite any of their updates, I generally pull a copy of their database down and replace mine. However, there are times where I just need to hop into the WP admin area and change a setting or something else small...

If there are multiple developers working on a WordPress project, we each do a (timestamped) database dump of our version of the site and include in in the root directory before committing and pushing their local branch back to the remote repository. The trouble with this approach is that the databases are often out of sync with no easy way to determine which to use.

What are other developers doing to keep their databases in sync while still allowing multiple developers (and clients/content producers) to work on the same project?

share|improve this question
up vote 3 down vote accepted

There are 3 options from easiest -->

  1. Use only one remote database that you all connect to with lots of backups. That way you just have to worry about files and not the db.

  2. Use the import and export functionality built into WordPress and throw it into your version control right into the wp root (like in a new folder). Sure it takes an extra few minutes but its dead simple and you can automate it, but more importantly it will become part of the version control.

  3. Use a custom updating script to version the actual database sync. I honestly don't know how you can manage that with git because its a just a script and doesn't really know what is going on, I know there are 3rd party tools that do this commercial and free ( http://www.liquibase.org/).

share|improve this answer
i would go with option one since it is the only one "in real time" tough every action might take longer. – Sagive SEO May 22 '12 at 13:14

If you need to keep the databases in sync entirely, ie. schema and data, you might develop a custom versioning system based on backups.

Or if you want to keep the data from production but evolve its schema, you might work with a custom solution (a versioned file with all the schema changes), or with a standard solution based on the concept of migration. You can find a lot of info in this stackoverflow thread: Mechanisms for tracking db schema changes.

share|improve this answer
Also a simple one here stackoverflow.com/questions/825787/… – grm May 22 '12 at 20:28

I'm sorry if this seems incredibly obvious but if you all need to have the same copy of the database with the same structure, would it not make sense to have an office/central SQL server and use that? Clone it locally if you need to experiment but keep it as the authorative defacto standard and take backups of that server and only that server.

Otherwise when I'm working on a group project we have our own setups with different content. The code takes care of upgrading and migrating table structures and we can access eachothers local installations of the code running on our machines over the LAN, so there's no need for us to share content.

If we're entering content we run it on a test server which we can then either export and import into the live server, or we can migrate directly on to the production server if no live instance currently exists.

If at any point you need a separation of live test and WIP data, then just use a live, test, and development branch in your repository

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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