This usage guide explains the features in the Staging tool available with your WPMU DEV hosting account. Learn how to use Staging to simply pull a Production site to a Staging environment for safely developing and testing updates to plugins, themes, or your server and pushing your changes live.
Quickly navigate this usage guidance from the index.
If you haven’t set up your WPMU DEV hosting account yet, visit the hosting page, where you can explore the features, see pricing packages, and start a free trial.
9.1 Setting up a staging siteCopy chapter anchor to clipboard
You can create a Staging site by visiting the Staging tab of your Hosting Hub. Simply follow the prompts there to create and access your new Staging site, which is a full copy of your live site. Perfect for trying out new plugins or themes, proofing content changes, and other development work.
To move a website to Staging for the first time, visit the Staging module and click the Start button.
This will generate a copy of your live site with a modified URL, such as: yoursitename.staging.wpmu.host. When the Staging environment is created, a hotlink to the Staging environment will be available under the Domain field.
Staging sites do not have backups and can not be recovered after resyncing with Production. If you are working on a rewrite or long-term design project, consider local development or working from a password-protected Production environment with regular backups. For Production sites hosted with WPMU DEV, use managed backups. For sites hosted with a 3rd-party, use Snapshot.
9.2 Staging OptionsCopy chapter anchor to clipboard
This section covers the three options available in the Staging module. Options include:
- Move Staging to Production
- Reset Staging
- Delete Staging
9.2.1 Move Staging to ProductionLink to chapter 2
When you are ready to make the contents of your Staging site live, move them to Production. This will replace your live, or Production site, with the contents of the staging site.
To move your Staging site to Production, click the Go button.
This will open a module where you can select to move the Staging Files or Files & Database to Production.
- Production Files – Your site’s framework without the content, including your WordPress installation files, themes, and plugins.
- Production Database – The content and settings you add or apply to the framework stored in your Production Files.
Use the dropdown to select whether you wish to replace only your site files, or both the files and database. Click Move to Production to continue.
By moving either the Files or Files & Database from the Staging environment to Production all of the current Production changes will be lost. As a precaution, a pre-staging backup of the live site is created each time staging is moved to production.
9.2.2 Reset StagingLink to chapter 2
This option will replace the current Staging environment with a fresh copy of Production. All of the Staging files and database will be overwritten.
Click Reset to open the Reset module.
Clicking Confirm Reset will automatically reset your Staging environment. Click cancel to close the module without resetting your Staging environment.
9.2.3 Delete StagingLink to chapter 2
This option will delete the current Staging environment completely. All of the Staging files and database will be lost.
Click Delete to access the pop-up and then Continue to immediately delete the Staging environment or cancel to close without deleting.
9.3 SettingsCopy chapter anchor to clipboard
To the right of the Staging Options module, you will find information about your Staging site, configuration options, and settings.
The domain is the URL created for accessing your Staging site. The domain section will display the URL and is hotlinked so you can quickly access the site.
Note that the links shown here are already encoded with the HTTP Auth username and password you set in the Password Protection section below. So when you click on either of them, you’ll automatically bypass the HTTP Auth. Of course, if anyone enters the plain URL in a browser, they would still need to provide those credentials to access your staging site.
The current version of WordPress being run by your staging site is displayed here. If you are testing an update to core on your Staging site, and push to a different version, use the Refresh button next to the version number to verify the changes.
If you are running a different version of WordPress core on your Staging site when pushing back to your Production site, your Production site will be overwritten.
The Last Sync field is the date and time your Staging and Production sites were synced. This can be valuable if you are developing on a Staging site over a long period of time before syncing to Production and don’t want to lose changes in your Production environment.
The PHP Version is the version of PHP being used for your Staging site. This can be used to test your site when Upgrading or Downgrading your PHP version.
Click the pencil icon to switch between the list of supported versions of PHP.
We recommend using the latest available version of PHP on Production sites when possible for the fastest, most secure site.
Click Apply to save your changes or click the X or Cancel to close the PHP module without switching your PHP.
9.3.1 Password ProtectionLink to chapter 3
HTTP Auth Password Protection is required for all Staging sites to help ensure that Staging sites aren’t indexed by search engines and that your Staging site is not visited by the public. The password is not the same as any WordPress user account and can be set from your Hosting Hub.
- Username — The Username field lists the current Username. By default, this will be your admin Username. You can change the Username by clicking the pencil icon next to your Username.
Click the Save button to save your new Username or Close to close without making any changes.
- Password — A strong password is generated when the Staging site is setup. Click the copy button for storing the password to your clipboard for pasting in. Use the pencil icon to customize or change your password.
Click the Save button to save your new Password or Close to close without making any changes.
Note that the staging Domain links in your Hub are already encoded with the username & password you set here, as seen in Settings above.
9.3.2 Manage DatabaseLink to chapter 3
Get access to make changes to your Staging websites database. Click the Manage Database link to open the phpMyAdmin manager for your Staging site. This will not make changes to your Production site unless it is pushed live.
Detailed documentation for using phpMyAdmin can be found on the phpMyAdmin site.
9.3.3 Manage FilesLink to chapter 3
Click the Manage Files link to pop open the WPMU DEV File Manager for your site in a new tab.
The left panel allows you to navigate through files and logs from both the Production server and the Staging server.
9.3.4 Reset WPLink to chapter 3
Use the Reset WP option if you ever need to revert your staging site to a fresh, default WordPress installation. The option here does not affect your live site; there is a separate Reset WP option for your live site under the Tools tab.
Note that this is very different than the Reset Staging option above which pulls in a fresh copy of your existing live site.
Click Reset to pop open a modal window where you’ll be prompted to enter your WPMU DEV password, and confirm the action.
This reset will delete all files (including non-WordPress files) in the Staging directory of your staging site before the fresh re-install of WordPress. Unlike when resetting WP on your live site, a backup will not be created of your staging site.
Once you click the Continue button, you’ll be prompted to create a new WordPress administrator account for the fresh install. You can use the same email, username and password as you had for your admin user before, or create a brand-new admin user.
Click the Continue button and you’ll then see a screen indicating the reset is underway. Depending on the size of the site, it can take several minutes for this to complete.
When the reset process is complete, visit your staging site where you’ll see a brand new default install of WordPress for you to build on.
9.4 Troubleshooting & NotesCopy chapter anchor to clipboard
You can sync a new copy of your Production site to your Staging site at any time by simply clicking the Reset button.
When you push a copy of the Staging site to your Production site, we will automatically make a backup of your Production site first. This helps with fast recovery should you need it.
Staging uses an incremental clone of your Production file system. This means that it normally uses very little of your storage space. Only new/changed files on Staging or deleted files on Production will increase the amount of storage used by Staging and doing a fresh sync from Production will reset that to zero again.
Staging is given limited server resources to prevent it from adversely affecting your Production site. This too can make Staging run slightly slower, and in rare cases cause errors with some plugins that demand lots of resources.
For example, staging sites only have 2 PHP workers (the processes that run PHP on the server), regardless of the hosting plan.
Depending on how your multisite is set up, creating a staging copy may or may not work as expected.
- Subsites in a staging environment of a subdirectory-based multisite will work just fine.
- Subsites in a staging environment of a subdomain-based multisite will work with one caveat: they will not be secured by SSL. So if any processes require HTTPS, you will need to bypass or ignore SSL errors on the staging subsites.
- Subsites in a staging environment of a multisite using a plugin for domain mapping (like WP-Ultimo), will work as above as long as you deactivate the domain-mapping plugin on the staging site so the subsites are accessed at their “normal” staging URLs.
- Subsites in a staging environment of a multisite that have been natively domain-mapped will not work at all. The domain-mapped subsites on staging will still point to their mapped domains. It would require significant manual effort to make such domain-mapped subsites work on staging. You would need to run a search & replace in the staging database to change all instances of the mapped domain URLs to what they would normally be on staging, then change them back again after edits, before and/or after pushing to live.