8. Staging

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 copy 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.tempurl.host. When the Staging environment is created, a hotlink to the Staging environment will be available under the Domain field.

For security purposes, the Single Sign-on state of the production site is not copied to the staging site. Hence, If you created a staging site while the SSO feature is enabled on your production site, you will see the following error when using the hotlink to navigate to your staging site dashboard:

{"code":"invalid_sso_attempt_hmac","message":"Could not validate the hmac of the SSO attempt.","data":{"status":400}}

To overcome this issue, manually type in the URL of your staging site dashboard and log in using your production site credentials. Then go to WPMU DEV > Settings and disable SSO, enable it again, then click the Save Changes button.

This section covers the three options available in the Staging module. Options include:

• Move Staging to Production
• Sync production to Staging
• Delete Staging

To the right of the Staging Options module, you will find information about your Staging site, configuration options, and settings.

Domain

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.

WordPress

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.

Last Sync

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.

PHP Version

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.

Click Apply to save your changes or click the X or Cancel to close the PHP module without switching your PHP.

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.

If you notice valid URLs on your staging site returning 404 errors, go to Settings > Permalinks and click the Save Changes button to refresh the permalinks.

Occasionally, you may get an error message in your Hub saying the staging site creation failed. This can happen from time to time if our system is overloaded with requests. Please try the process again before contacting support.

Staging Resources

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.

Object Cache, Static Server Cache and Web Application Firewall (WAF) are not enabled on Staging sites. This will make Staging sites a bit slower than your Production sites but helps make development easier.

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.

Multisite Staging

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.

Images Are Missing on the Production Site

After moving your staging site to production, you might find the images missing on the production site. To resolve this issue, try the following:

• If you are using Elementor, make sure to regenerate the page builder assets.
• If you are using Divi Builder, clear the Divi Builder cache.
• If you enabled Smush CDN on your production site, go to Smush > CDN and click the Deactivate button; then enable it again by clicking on the Get Started button.
• Clear your site’s Object Cache and the Static Server Cache.

URL Issues When Pushing Staging to Production

When pushing staging to production, our system will automatically update all URLs from the staging site name to the production site name in the following database tables:

• {DB_PREFIX}blogs
• {DB_PREFIX}sitemeta
• {DB_PREFIX}options
• {DB_PREFIX}*options

If any URLs are stored in other tables, possibly by your page builder or other plugins, they would not be automatically updated, and you would need to take care of that manually.

There are 3 ways you can ensure that all URLs are updated correctly:

• WP-CLI
• A search & replace plugin
• Adding defines in wp-config.php

Replacing URLs with WP-CLI

Running the following command will update all URLs registered with the $wpdp object:

wp search-replace 'https://example.staging.tempurl.host' 'https://example.tempurl.host'

Replacing URLs with a plugin

Using a search & replace plugin, like this one, is an easy way to get the job done if you’re not comfortable with command line stuff.

Simply enter the URL you want to search for, for example: https://example.staging.tempurl.host

Then enter the URL you want to replace that with, for example: https://example.tempurl.host

With the plugin method, you can also do a “dry run” first to check and be sure only the changes you want will be made. Then run the process.

Adding defines in wp-config.php

Add the following defines to your wp-config.php file, before the line that says “That’s all, stop editing”. Be sure to change the URLs to your actual domain name.

define( 'WP_SITEURL', 'http://example.com’ );
define( 'WP_HOME', 'http://example.com' );

This will ensure that both WordPress files and your site will load from the domain you specify.

This can be an easy way to fix the issue. However, there is a drawback to this method: it does not actually change anything in the database. So if you remove these defines from the wp-config.php file, any incorrect URLs will still be there, and you’d need to use one of the other methods to fix them anyway.

If you still have questions or need assistance after reading this document, please don’t hesitate to contact our support superheroes using the available options under the Support tab in your Hub or via the Support tab in your WPMU DEV Dashboard.