Avoiding WordPress Database Merging


When WP Migrate DB was first created its main task was to easily migrate an entire site’s database from one location to another. As time passed more and more people have been experimenting with the plugin attempting to solve other problems.

One such problem looks like this:

You have a live client website that is updated regularly. You clone that website to a local development website and begin tweaking the code and content. When the time comes, you decide to push these changes to the live website.

Here’s where things start getting a little tricky. While you’ve been working on some local changes your client has been adding new blog posts, images, etc. to the live site.

If you push your local changes to the live website you’re going to overwrite your client’s work. But, if you pull the live database back into your local environment you will overwrite your own work.

Currently WP Migrate DB Pro does not have the ability of “merging” two databases together. This has been an often requested feature and we are currently brainstorming ideas of how this could be solved with the plugin. So far though, our solutions are looking very complex and still require manual conflict resolution. We haven’t come up with a magic bullet just yet.

But there are ways to avoid getting into this situation in the first place.

SQL Scripts

Let’s pretend you’ve decided to add an e-commerce solution to your client’s website. WooCommerce 2.0, as an example, requires you to create a few pages. Once these pages have been created, you could create an SQL file and record the SQL used to create these pages. e.g.

INSERT INTO `wp_posts` (`ID`, `post_author`, `post_date`, `post_date_gmt`, `post_content`, `post_title`, `post_excerpt`, `post_status`, `comment_status`, `ping_status`, `post_password`, `post_name`, `to_ping`, `pinged`, `post_modified`, `post_modified_gmt`, `post_content_filtered`, `post_parent`, `guid`, `menu_order`, `post_type`, `post_mime_type`, `comment_count`) VALUES
(NULL, 1, '2013-02-27 21:03:13', '2013-02-28 01:03:13', '[woocommerce_checkout]', 'Checkout', '', 'publish', 'closed', 'closed', '', 'checkout', '', '', '2013-11-04 09:52:16', '2013-11-04 13:52:16', '', 0, 'http://yourwebsite.com/checkout/', 0, 'page', '', 0),
(NULL, 1, '2013-02-27 21:03:13', '2013-02-28 01:03:13', '[woocommerce_my_account]', 'My Account', '', 'publish', 'closed', 'closed', '', 'my-account', '', '', '2013-11-04 09:52:50', '2013-11-04 13:52:50', '', 0, 'http://yourwebsite.com/my-account/', 0, 'page', '', 0);

Once you’re ready to deploy simply import your SQL script and you’re ready to go.

PHP Scripts

Instead of recording the SQL queries you could instead write a PHP script that creates the data. Of course you can include SQL queries in there as well, but can also do a lot more. Let’s use the scenario above again as example, but instead I’ll write a function to deploy the changes.

 * To run the deployment
 * 1. Login as an administrator
 * 2. Go to http://yourdomain.com/?deploy_changes=1
function deploy_changes() {

  // If the request is not our deployment
  if ( !isset( $_GET['deploy_changes'] ) ) {

  // Only allow a logged in admin to run the deployment
  if ( !current_user_can( 'install_themes' ) ) {
    echo 'Not logged in.';

  // Run script for 5 mins max

  $pages = array(
      'content' => '[woocommerce_checkout]',
      'title'   => 'Checkout'
      'content' => '[woocommerce_my_account]',
      'title'   => 'My Account'

  foreach ( $pages as $page ) {
    $new_page = array(
      'post_type'   => 'page',
      'post_title'  => $page['title'],
      'post_content'  => $page['content'];

    wp_insert_post( $new_page );

  echo 'Deployment complete.';
add_action( 'template_redirect', 'deploy_changes' );

Once you’re ready to deploy simply push this code to your live site, login as an admin, and visit http://yourdomain.com/?deploy_changes=1 to run the code.

For this site (deliciousbrains.com), we have a maintenance.php file that we put this kind of code into and include it from functions.php. (It would probably be better to create a custom plugin for this, rather than include it in the theme, but either way works.) Then after we’re done with it, we simply remove the function from the file to make sure we don’t run the deployment again accidentally. Source control (git) ensures that we always keep a history of the old deployment code in case we need it again.

Why Database Deployment Scripts Are Awesome

One of the great advantages of scripting your database deployment is that you can test your deployment as you develop.

You can use Migrate DB Pro to easily pull down the latest database from the live site. This will overwrite your local database changes, but then you can simply run your database deployment script and continue developing. If there are any major issues, there’s a good chance you’ll notice them as you continue to develop.

Do you use database deployment scripts? How would you like to see WP Migrate DB Pro help out in this area? Let us know in the comments below.

Update: Read about how we’ve improved our scripting process and the current state of database merging in WordPress.

Photo credit: OneFuller

About the Author

Brad Touesnard

As founder of Delicious Brains Inc, Brad has worn many hats. He now spends most of his time managing the product teams and growing the business. Before starting this company, Brad was a freelance web developer, specializing in front-end development.