Staging Environments for Your WordPress Sites

A staging server is a complete copy of your live WordPress website, which runs on an off-site isolated server. It is useful for testing updates, new plugins or themes, and any other potentially breaking changes, without affecting your live website.

Creating a Staging Server

To create a staging server with Pressjitsu simply login to your hosting control panel, select your application and the “Staging” option from the main navigation. You will be presented with a few options:

Staging Configuration
Staging Configuration

Authentication

There are currently two authentication methods available — Basic and None. Staging sites are publicly accessible, and selecting the Basic option allows you to protect your staging site with a password. Note that this password will be required to view your site, but will not get you into the admin area of your staging site.

If you select None for Authentication, your staging site will be publicly accessible by anyone who knows the URL. This option is useful if you are testing third-party services and tools which require your website to be publicly available.

Domain Mapping

The Domain Mapping section offers three options: Auto, Custom and None.

If you’re running a single WordPress site on your server, Auto is the recommended option. This setting will cause the provisioning script to replace all your base URLs in the database to their corresponding staging URLs (usually staging.application.pjtsu.com), and your staging site will be accessible by that URL only.

The Custom option allows you to customize URL replacements when provisioning your staging server. It’s useful if you’re running WordPress Multisite with multiple domains. When selecting this option you will have to explicitly provide mapping data for each domain. For example, if you’re running Multisite with two websites called example-a.org and example-b.org, your mapping data could like this:

example-a.org:staging.example-a.org
example-b.org:dev.example-b.org

This way the example-a.org staging site will be accessible via staging.example-a.org, and similarly, the example-b.org staging area will live at dev.example-b.org. Note that in order for this method to work, you will have to create CNAME records in your DNS configuration for staging.example-a.org and dev.example-b.org, to both point to staging.application.pjtsu.com.

The None option is useful for developers and advanced users, who are comfortable working with the local /etc/hosts file to temporarily map their original domain to the staging server IP address.

When you’re ready, hit the “Create Staging Server” button. The server will be provisioned, usually within 15-30 minutes depending on the data size. When provisioning, the staging server will copy all files (excluding any external storage), as well as the database from your production site, so if you’re running a heavy workload on your production server, we recommend timing this operation to when traffic is not at its peak.

Working With Your Staging Server

After the staging server is provisioned you will receive an e-mail notification. The new server will be immediately accessible via your chosen domain mapping option. You can also access this server via SSH, using the same credentials (and SSH keys) as your production server, but with a different host name, usually staging.application.pjtsu.com.

If you’ve made a mistake on your staging server or simply need to refresh your environment, you can use the Sync Staging option to re-sync all files and the database. Note that this will overwrite any changes on your staging server.

If you’re happy with your changes on your staging server, you can Push the files back to production. To prevent data loss, this option does not push database changes from your staging server to production. If you’d like some tables to be pushed from staging to production, you can do that manually using the MySQL CLI tools, or open a support request for assistance. Note that this option is not available if you’re using our Git-deploy workflow.

Pitfalls and Considerations

Some WordPress sites use third-party plugins and tools for things like posting published posts to social networks, sending e-mail notifications, newsletters and more. Please note that a staging environment mirrors your production environment, and these plugins will likely follow the same triggers on your staging server.

We recommend deactivating such plugins on your staging environment prior to making any content changes that may cause such plugins to take action. If you’re working on some custom code or a plugin, you can disable these actions in a staging environment by using the following snippet:

if ( ! is_callable( array( 'Pj_Staging', 'is_staging' ) ) || ! Pj_Staging::is_staging() ) {
    // Send notification with wp_mail() ...
}

If you’re working on anything earlier than muplugins_loaded, for example your wp-config.php file, you can find out whether you’re in a staging server by comparing the hostname, for example:

if ( gethostname() == 'staging.application.pjtsu.com' ) {
   define( 'WP_DEBUG', true );
   define( 'WP_DEBUG_DISPLAY', true );
}

Caching & CDN

Redis-based page caching and the short-term Nginx page cache are both available and enabled by default on a staging server. This allows you to test cache-related changes, such as cookie-based cache varying, etc. If you’d like to by-pass caching on your staging server, you can either login (logged in users never hit page cache), or disable page caching altogether in wp-config.php using the gethostname() method above.

The CDN integration is disabled by default for staging servers since CDN resources are configured to pull files from the production origin. If you’re working on anything related to the CDN on your staging server, you can request a new, temporary CDN resource to pull from your staging server instead. Note that this will only work with the “None” authentication option.

Staging, Git & Deploys

If you’ve enabled the Pressjitsu Git-deploy workflow for your WordPress site, after provisioning a new staging server you’ll have the option to deploy to that staging server from your Deploy screen.

Deploy to Staging Server
Deploy to Staging Server

You can also commit and push to your Git repository directly from the staging server, allowing you to then deploy these changes to production. However, please note that when deploying, regardless of the deploy target, any local uncommitted changes to files under version control will be lost, so if you are using your staging server for development, please double-check git status before deploying to staging.

Destroying Staging

When you’re done working with your staging environment, you can destroy it an any time and provision a new one later when you need it. Note that staging servers are assigned an IP address at random when provisioning, so you might need to alter your /etc/hosts file if you’re using the None option for domain mapping.

Destroy a Staging Server
Destroy a Staging Server

Also note that unlike production servers, staging servers are never backed up. If you wish to backup your staging server, you’ll have to do it manually using the available CLI tools, or via a support agent.

If you have any questions about our staging servers feature, or difficulties setting it up for your WordPress site, please feel free to reach out to us via e-mail, or by opening a support request from your Pressjitsu dashboard.