2

I am facing this issue: we have one developers environment, one test environment, then the production.

I would like to restrict the plugin additions, menu changes, any other changes not related to actual blog writing to the lower environment set up process and then propagation to production.

Say I am adding a plugin:

  1. In development environment I have added a plugin and checked into the source control.
  2. Then I [SOMEHOW] deployed that to test environment hopefully in automated fashion and QA have tested it.
  3. Then [SOMEHOW] it get's deployed to production without affecting the content and comments written in production. Right now it's manual set up on each environment and they constantly get desynched. CSS guys have to replicate the configuration of say MegaMenu 3 times :/

The challenge I am facing is that many configuration changes and plugin settings reside in WP database, but because plugins can define new tables and update settings table, I have no idea how to separate content from settings :/

Any help would be appreciated.

1 Answer 1

1

I'm also using a Deployment process including 3 environments. This is an issue we can't really address automatically unless you check the difference between 2 sql dumps I guess.

The way to go would be to create a bit of PHP to populate your settings on deployment (or on plugin activation). It'll obviously involve to check the plugin source code and/or the database for the options table.

Unfortunately I'm not aware of any solution which would help with that otherwise.

(Considering you are already using something like WP_Skeleton & WP_Stack)

Hope that helps

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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