1

I'm trying to work version control into developing a Wordpress site, but I'm unable to solve the issue of DB synchronization.

For simplicity's sake, I will describe a scenario with just Live and Staging websites and repos:

  1. Pull down Live DB to Staging DB
  2. Do the same for code
  3. Install WP plugin on Staging. Tweak, configure and test as needed.
  4. When ready, deploy to Live <- here is the issue

The installation of the plugin could result in changes to the database. New tables and maybe even new entries in existing tables. Of course, pushing up the code part of the plugin is not an issue, but what about the DB changes? The Live DB has already changed (it's a live site after all). That means I'm stuck back at square one - installing a plugin directly on Live without proper testing and deployment workflow.

All the articles I've read that talk about putting WP under source control and proper deployment practices don't seem to say anything about this issue. Am I just missing something obvious entirely?

Thanks for any help!

  • What changes to the DB are you needing to go live? – Nathan Powell Oct 1 '16 at 3:57
  • Never mind, I see you are concerned about the changes a plugin/theme/core might make to the database. – Nathan Powell Oct 1 '16 at 3:59
2

The answer is to try and avoid relaying on configuration changes via the admin interface. Don't use plugins that you can not configure by filtering options, or better, use only those that have an official API and use the API.

For example if a plugin has an option "pl_option" with which you are happy when its value is 5, do not change the option in the DB via the admin but set it to 5 by using a filter like

add_filter('get_option_pl_option', function () {return 5;});

if in the next version of the plugin the DB structure changes to be an array, you change you code to something like

add_filter('get_option_pl_option', function () {return array('value'=>5;});

This obviously do not prevent from the plugin to make DB changes, but makes your code agnostic to them.

Anyway, having the code in a version control is a small win in any case even if following the suggestion above is not realistic for you.

  • 1
    That doesn't make sense. WordPress itself makes DB changes. Many of the best plugins available make DB changes. – Nathan Powell Oct 1 '16 at 4:31
  • It doesn't make sense because the second rate quality of most wordpress plugins and themes got you used to follow second rate development workflow. The OP asks about the proper workflow, not about the easy workflow. As for wordpress core upgrades, you have a point, but 1. this is unavoidable risk when working with wordpress and 2.you can trust core to not do breaking changes, or changes that require additional configuration. For all other plugins, even from just semi respectable authors, there will be filters and APIs you can use, just need to read the documentation. – Mark Kaplun Oct 1 '16 at 4:54
  • Sometimes plugins have to make changes to data structure to maintain code. Does that make sense? Yes! Does that make the plugin second rate? No! There is simple protocol for this to happen. What doesn't make sense is having to write your own filters for data changes. – Nathan Powell Oct 1 '16 at 5:01
  • @NathanPowell, I seriously don't understand what is it that you don't understand. If there are plugins that "have to make DB changes" then don't use them if you want to have a good workflow, use only plugins that provide official APIs. – Mark Kaplun Oct 1 '16 at 5:04
  • What don't you understand? Plugins, themes and WP core make database changes depending on the version you are using. Official (and even unofficial) APIs are how you interact with the data stored. Most themes and plugins change that too. But we aren't talking about that are we? – Nathan Powell Oct 1 '16 at 5:13

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.