3

We've been developing for Wordpress for several years and whilst our workflow has been upgraded at several points there's one thing that we've never solved... merging a local Wordpress database with a live database.

So I'm talking about having a local version of the site where files and data are changed, whilst the data on the live site is also changing at the same time.

All I can find is the perfect world scenario of pulling the site down, nobody (even customers) touching the live site, then pushing the local site back up. I.e copying one thing over the other.

How can this be done without running a tonne of mysql commands? (it feels like they could fall over if they're not properly checked!) Can this be done via Gulp's (I've seen it mentioned) or a plugin?

Just to be clear, I'm not talking about pushing/pulling data back and forth via something like WP Migrate DB Pro, BackupBuddy or anything similar - this is a merge, not replacing one database with another.

I would love to know how other developers get around this!

File changes are fairly simple to get around, it's when there's data changes that it causes the nightmare.


WP Stagecoach does do a merge but you can't work locally, it creates a staging site from the live site that you're supposed to work on. The merge works great but it's a killer blow not to be able to work locally.

I've also been told by the developers that datahawk.io will do what I want but there's no release date on that.

  • First of all, what's the goal you want to achieve? Why you want to use two separate data stores to obviously manage one data volume? I mean there might be valid reasons to manage data via a remote system, that's what (REST) APIs are for in theory. (I don't know any existing solution yet that fits your requirements.) Another way would be to export the data to a uniform format (something like the WXL) and import it on the remote system. But that's nothing to keep data in sync easily. – David Feb 8 '17 at 7:39
-1

If you just merge the local DB into the production DB it actually means that your local install is a production as well. The problem is not with the ability to perform merge, the problem is that you don't have a separation between production staging and dev servers.

DB on dev installs are likely to contain garbage values of some sort and you might get unexpected results if you just "merge".

Your software design should avoid DB settings unless they actually should be used by a user. Avoid "development by DB values" tools like ACF, override and hardcode the values stored in options that the user will not change but you need to set for the configuration if it is a bought theme.

Once there is no setting in the DB which you use to control the behavior of the site the whole merge problem disappears.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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