1

I am involved in a redesign of a client's website and during development the client has been adding posts/pages and working with existing plugins that were on the site.

I have made a new theme and added new plugins including plugin settings to the new design. My question is how can I pull the current production database to my development without overwriting what I've developed. I was looking at the wp-db-migrate-pro plugin to migrate only certain tables but there are some complications. the wp-posts tables includes navigation menus and pages and if I were to pull that table I would destroy the pages and menus I have created. In addition there are plugin settings I need from the production site but pulling the wp-options table would overwrite the plugins and their settings I have on development.

Is there an easy deployment strategy I could follow to grab data while not overwriting my own? This article https://deliciousbrains.com/avoiding-wordpress-database-merging/ talks about it but the two strategies suggested aren't really viable for me as they are difficult to write and manage.

  • You're basically, well, screwed. This should have been done and planned for at the beginning of development. I would look at what exactly is new from the client's live site and write a tool to pull just that stuff, i.e. just posts and pages or something. – Andrew Bartel Apr 9 '14 at 21:04
  • well it's not realistic to tell the client 'don't do anything while I'm developing'. All he was doing is adding new posts, pages and working with existing plugins. The migrate plugin can pull specific tables but wordpress has other settings that are combined into certain tables. For example the navigation in the posts table. – Wayne Apr 9 '14 at 21:33
  • What you're looking at then is taking the live site down with a maintenance plugin, htaccess or something, pushing your new theme and plugins to the live site and then making your changes that affect the db (pages, menus, etc) by hand. – Andrew Bartel Apr 9 '14 at 22:56
1

If the only changes you have made on your development site are theme and plugin related, those are all file system changes. Pulling in the DB from the current production site would not overwrite your files.

Make a fresh backup first but unless you've modified the DB there is nothing to worry about.

  • In addition to working with files, I'm working with settings that involve the database. I've added in new plugins and worked with those plugins as well. If i pull in say the wp-options table it would overwrite every modification I've made in those new plugins. The viable solution I see if there was a way to do version control with databases. – Wayne Apr 9 '14 at 21:36
  • I see your point. Modifying settings to a plugin that exists on both servers would create a DB conflict. I read too quickly past that sentence in your question. At this point, version control would mean starting with the production server and making your settings changes again, installing your theme and new plugins. If your settings were not too extensive, that might offer the simplest route. My apologies for not fully understanding your situation. – jdm2112 Apr 9 '14 at 22:47
  • It's alright! It happens sometimes when we miss things. I might just have to go with the manual route and just pull the production database then just do manual changes one by one until my development changes are complete. I was hoping there was some way to go about this since manual process is slow and prone to errors. How do developers go about working on a redesign and allowing the client to still work on the old site?? There is going to be conflicts when merging data together. – Wayne Apr 9 '14 at 22:55
  • If you are familiar with using Git, there are a few good write-ups. Search "wp version control git". Obviously that approach isn't helpful to the current situation. – jdm2112 Apr 9 '14 at 23:27

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.