It is broadly accepted that developers should test updates through a staging site before releasing them to the live server, however once the development updates require modifications in Wordpress DB, things get complicated, as users in the live site will update the DB too.

The only (muddled) flow I can imagine is the following:

  1. Test on a local server (WAMP, XAMP, etc)
  2. Once ready to deploy, put the live site in maintenance mode
  3. Backup live site (Duplicator, sqldump, etc)
  4. Create a clone of locked live site to the staging site
  5. Upload modifications from local environment to the staging site
  6. Test the staging site
  7. Push the staging site to live.
  8. Remove maintenance mode

Drawbacks of the flow above:

  • downtimes may be longer than expected for users while the developer is carefully testing updates in the staging site;
  • may require manual management of modifications: for instance, siteorigin pagebuilder layouts are stored in the db, so once a layout is modified, it must be imported manually in the staging site; in this case it could be adequate to simply drop & import pages into the staging site, and if working, importing them in the live site

I wonder if is there a better and more automated way to achieve this.

What do you think?

EDIT, as requested, some solutions have been proposed in the past but none offers a definitive solution:

  • @Dan9, I thought it would ba safer to minimize access to the live site. Is it a common habit to edit layouts on the live site? Maybe I am worrying too much!
    – Riccardo
    Sep 6, 2016 at 8:21
  • Well, you can create, update, delete, restore them. What're you worrying about?
    – Minh Tri
    Sep 6, 2016 at 8:37
  • So it is usual to upload layouts without testing in the staging site? What is your typical workflow (local/staging/live)?
    – Riccardo
    Sep 6, 2016 at 8:39
  • Take a look at wp-sync-db plugin.
    – Minh Tri
    Sep 6, 2016 at 9:05
  • Is it reliable? Are you using this tool?
    – Riccardo
    Sep 6, 2016 at 9:08

2 Answers 2


Newer hosting providers that cater specifically to WordPress usually have tools in place to ease this pain. I put my clients on Pantheon which has this neat Git-enabled workflow, where code only moves up (from dev to staging to production) and DB stuff only moves down (vice versa from the code). Copying a database from production to staging is one click with their interface. Provided this workflow is respected, this pretty much eliminates the issue of ever messing up the production database, enabling me to always test my changes on a fresh clone of production DB data in either staging on development.

One doesn't have to use Pantheon - you can adopt a similar approach in your process using your own tools (Git + a DB cloning plugin like WP Migrate DB). I just find this way works well for me.

Question: why would you put your production site in maintenance mode while testing staging? There shouldn't be a need for that in a majority of cases. The only case I can think of is having some sort of very brittle system highly sensitive to additional user data being fed into it, with a catastrophic bug to boot - but that would likely be indicative of a different, larger, problem where one would need to rethink their product's entire architecture.

  • My provider allows creating one-click staging sites and push-to-live with a granular selection on tables being rewritten, nevertheless I still need locking users while the final test is run because part of the deployment is injecting developer-side data in the DB (sitebuilder page layouts for example are stored in the DB), requiring users to stop updating during this phase. If you have a better idea how to achieve this step I would be glad to share with you!
    – Riccardo
    Sep 5, 2016 at 12:27
  • BTW, do you go through the dev/staging/live flow each time a little modification has been made? For example, slightly changing the layout of a page within the editor, or modifying a menu
    – Riccardo
    Sep 5, 2016 at 14:37
  • Yep - files go through dev -> staging -> prod every time (perhaps you can disable staging or dev - don't remember). Dev is for the dev team, staging is for QA or designer/client approval before pushing to prod. Sep 6, 2016 at 13:37

Have a look at VersionPress which brings GIT versioning to the whole process (files and database)

As described on their site:

VersionPress provides painless staging. This means that you can easily create a safe testing environment for your changes and only merge them back when they are ready. Merge is the key word here – VersionPress handles situations where your live site had new content in the meantime seamlessly.

  • 2
    How can I verify reliability of this tool?
    – Riccardo
    Sep 14, 2016 at 15:02

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.