Deploying Updated or New Plugins That Modify the wp_options Table

by

I have a WordPress site under local version control with Git. I deploy it to the production server using Capistrano.

For the initial deployment, I manually import the SQL database to the production server, and change all the local references by hand. Any content changes are made on the production server from then on.

This is for the most part okay, but I’m having a problem when it comes to testing/configuring new or updated plugins, since many plugins make changes to the wp_options table. I need a way to add/remove/update/configure plugins locally, do all my testing and then seamlessly deploy the updated site to the production server without breaking anything.

How are others dealing with this?

1 Answer
1

Not very well. There are issues with not only WordPress but plugins in general when moving databases on the fly, as for as I know, there is no seemless (or effortless) way to do this, it’s hacky at best, for that reason most people still use database dumps.

If you just care about preserving db urls, you can mimic the live url on your localhost machine using a vhost file.

If you want to preserve all data (id’s, content, and such) then you can sync the databases, just use precaution or a staging server as this can cause a disaster if a local change or mistake is made. This is not common because any local database stored changes will effect the live site’s database, so it’s really only good for altering code.

The alternatives would be a combination of the above with a server script that automates the migrations and sifts through the db, there are a few on github and elsewhere.

Some helpful links:

  • How to: Easily Move a WordPress Install from Development to Production?
  • Database synchronization between dev/staging and production
  • http://snarfed.org/sync_wordpress (did not know about this, sounds cool).

I also believe there are some 3rd party services (hosts) that now do this.

Leave a Comment