How do I push my staging changes to the live site?

Updated on August 13th, 2021

Note

When pushing changes from a staging environment to a production environment, the production site will display 476 Maintenance Mode until the push completes.

All right, you’ve made your changes to staging, confirmed that everything’s running well and looking good, and you’re ready to go live with your shiny new edits. This is the exciting part, but it’s also a little tricky. Don’t worry, we’re here to help!

When you’re ready to push the changes from your Staging site to the live production site, start by clicking the “Move staging changes to live site” button in the Staging tab of the site’s Flywheel dashboard. Don’t fret – it won’t happen right away. First you’ll see this pop-up, giving you some options and asking for confirmation:

Staging push confirmation and options

The “Copy staging database to production” checkbox is the most important (and maybe the most confusing), so we’ll go a little more in-depth on that here.

If you check this box, your live production site’s database will be completely overwritten with the staging site’s database. Otherwise, if you leave it unchecked, the database of the live production site will be left untouched and will retain all of its current data; only file changes will be copied from staging.

It can be a little tricky to understand the difference, so here’s a quick guide to what will happen in both cases:

Copy staging database to production?

Result:

No (unchecked)

The live production site’s plugins and themes will be overwritten with the staging site’s plugins and themes; new and updated uploads on the staging site will be merged with the live production site’s uploads; plus code files (like CSS, JavaScript, etc.), images, media files like audio and video, PDFs, and any other user-uploaded content will be pushed to the live production site.

Yes (checked)

All of the above still happens, plus the staging database will overwrite the live production site’s database. The database includes: all posts, pages, post and page content and revisions, navigation menus, widgets, WordPress users, comments, configuration options, store data such as products and orders, and WordPress options.

If the difference between what’s included in the site’s files and what’s included in the database is still a little confusing, maybe this will help: essentially, if it’s anything you could potentially save on your computer and/or access via FTP, it’s a file. Otherwise, if it’s something you click, check, select, or build within WordPress itself, it’s probably stored in the database. So a plugin itself is a file (or a collection of files), but the specific configuration options and settings for that plugin are stored in the database.

There’s no middle ground between overwriting the live production site’s database with staging and leaving it untouched. There is no way to simply merge the two databases automatically using staging at this time. There are, however, a number of plugins and tools available for this process, including WordPress’s built-in import/export feature.

Note

If there are any staging URLs in the code files of the staging site—including within CSS, JavaScript and/or PHP files—they will need to be manually updated! For best results with Staging, only use relative links that do not include the staging domain.

Warning

For reasons named above, it is highly inadvisable to use staging to make any database changes at all on eCommerce sites, membership sites, or in any other situation where users may be adding or editing live site content while staging changes are being made. In these cases, we recommend that staging be used only for changes and updates to files, like plugins, themes, and uploads. More on the best way to use Staging and why can be found in this help doc.

Note

Because of the complex nature and size requirements, Staging sites are not available to legacy Tiny plans or to sites that employ WordPress Multisite.