We're trying to put together a workflow for Wordpress development which turns out to be pretty complicated with lots of elements. Is there a way to streamline this or filling in the gaps?

We currently have 2 developers in the team - but essentially this can be however many, all working in the same way.

The problems

WP Stagecoach seems the only way to allow us to merge a database rather than just copying over one. Does anyone know any other methods?

We work on a lot of sites that need the live version to continue to run (and the data get updated)... whilst developing new features (therefore both versions are adding to the posts table in the database). This brings up the problem of losing data, copying over some etc etc.

The problem Wp Stagecoach has is that we can create a staging site, make the changes there, then merge back with the live site - that part works great. But we want to be able to work locally rather than on a staging site (which HAS to be on the Stagecoach servers).

So the real question is, how can we work on a site locally, and get it live without copying over live data (i.e merging with it)? Doing the files is straightforward, it's the database that causes the problem.

1 Answer 1


I've never worked with wordpress, but I did work on several web applications that had a database, and the usual way to make the database play nice with source control is to use a Schema Migration Framework.

The idea is that each developer has a personal development database installed on their own machine(or on a personal server or however you want to work - but it's usually on their own machine because you don't need a powerful server for the personal development database). During development, instead of modifying the database schema(and the constant data) directly, you write migration scripts that perform these modifications. These scripts can be checked in to source control, and the migration framework takes care of running the needed scripts in the correct order.

For example, instead of adding a column to a table via the database's administration GUI, Rob with write a migration script that'll do that, and use the migration tool to run that script and add the column. Rob will commit that script into the codebase, and when Matt pulls Rob's changes, he'll also pull that script. Matt will then run the migration tool, which will recognize that the new script has not been yet run on Matt's personal development database - and run it.

When you want to deploy a new version, simply use the migration tool to run all the scripts added in these version on the database in stagecoach's staging area.

  • It feels like as this is a Wordpress workflow then we should be using something Wordpress based as it brings it's own unique problems with the databases.
    – Rob
    Jan 20, 2016 at 16:16

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.