0

I did some searching before asking and didn't quite come across an answer.

Recently I started on a project where they were hosting the development version of WP on an internal multisite, and I was tasked to bring it to a more modern workflow.

The setup is Development (localhost) > Staging (Client Approval) > Production (World Facing)

So I got an instance up and and running on PagodaBox, which is uses Git for deployment, which is awesome, and they will be two instances running off branches of the Git repo.

For this project they used some plugins such as:

  • Aqua Page Builder
  • Royal Slider
  • Extended Text Widget
  • Cacoon (Theme)

That all seem to save their settings to a magical place I can't find (except RoyalSlider, I clearly see that in the database). So once I got the staging server set up, I used the WP Export tool, pushed the same repo (Different branch) to production, imported with the WP-Import....and basically got a wordpress site lacking all the designs they did with those plugins.

Looking at the database from staging, I don't see anywhere that holds this data (Except Royal slider which holds stuff blatantly in the database).

Where is this magical data, and how can I keep it synced between the three stages?

This also goes for things like images. Do I have to change all kinds of canonical links from one stage to the next?

I feel like I am missing something about WP development.

Any resources would be appreciated. :)

0

Native WordPress import/export file is focused very tightly on content. It is not meant and cannot (or at least no one bothers to try bend it that way) accurately represent the state of whole site.

The missing storage you are looking for is likely Options API, which is heavily used by core and third party extensions both. It persistently stores arbitrary data into options table in database.

The accurate replication of WordPress site takes complete copy of database. There still isn't any "default" solution for that in WordPress toolbox and process tends to vary a lot between developers (command line dumps, direct DB to DB copy, deployment scripts automating either, etc).

  • I appreciate the response. This sort of negates the great git based deployment flow that PagodaBox offers, since you can't just push to two different apps. :/ – Lucas Kasper Allmon Sep 13 '13 at 17:09

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.