Staging: testing safely

Module 8: Backups, staging and PHP upgrades · Reading time: 9 minutes

Learning objective: After this lesson, you can create a staging site, lock it down and safely synchronise changes back to your live website.

Key concepts: staging, production, cloning, subdomain, noindex, password on the folder, mail off, payment provider in test mode, synchronising, overwriting the database, local development environment

What staging is

A staging site (or test site) is a copy of your real website, on its own address, where you try out changes. Your real website is then called production. On staging, things are allowed to go wrong: a new theme, a major update, a PHP upgrade (lesson 8.4), a new plugin. Only once it works do you carry it over to production.

You use staging for changes with risk: major versions of WordPress or a webshop plugin, a different theme, a PHP upgrade, tidying up plugins (lesson 5.4), a redesign. For a text change or a small plugin update, it isn't necessary.

Ways to create a staging site

A staging site on a subdomain (staging.example.com) is usually better than in a subfolder (example.com/staging): it behaves more like your real website, and cookies and rules in .htaccess don't get mixed up. Create the subdomain first, with a certificate.

Locking down: three things to sort out straight away

A copy of your website is a fully functional website with all your content, and sometimes with all your customer data. So arrange straight away:

1. Keep search engines out

Without protection, Google can find and index your staging site. Then you have duplicate content, and searchers end up on your test site. Do at least one, preferably two of these:

• A password on the whole staging site (basic authentication via your hosting panel, a "protected folder"). Then no one sees the website without a password, not even search engines. This is the strongest option.
• Discourage search engines in Settings > Reading (lesson 2.4). This sets noindex on every page. Search engines usually respect this, but it's a request, not a lock.

Watch out for the reverse: if you later synchronise the staging site back to production, make sure not to carry over the noindex tickbox. A production website that disappears from Google after a "successful" synchronisation is a classic mistake. The exercise in this lesson checks both.

2. No mail to real people

A copy of a webshop or membership website can send mail: confirmations, reminders, newsletters, password links. Customers then get confusing emails from your test site. Turn off outgoing mail on staging or redirect it to your own address (with a plugin for intercepting mail, or by turning off the SMTP plugin on staging, lesson 9.1). Also turn off scheduled tasks that send mail.

3. Payments and integrations in test mode

A webshop on staging should work with the payment provider's test mode, not with real payments. Turn off other integrations (accounting, stock, CRM) or set them to a test environment, otherwise they receive test orders as if they were real.

If you work with real customer data on staging, the GDPR applies there just as much (lesson 9.3): don't keep it longer than necessary, and delete the staging site once you're done.

Back to production: the database pitfall

The hardest step is restoring your changes to production. Installers and staging plugins have a function for this (with Installatron "Synch", with others "Push to live"). The risk:

• You create a staging site on Monday. From Tuesday to Thursday you test a new theme.
• Meanwhile, on production, twenty orders, three new posts and fifty comments come in.
• On Friday you synchronise the database from staging to production. The staging database is from Monday: the orders, posts and comments from Tuesday to Friday are gone.

So:

1. Make a backup of production first (lesson 8.1), right before synchronising.
2. Only synchronise what's needed. Updating a theme or plugin is a matter of files; the database often doesn't need to come along. Many synchronisation functions let you choose: files only, or only certain tables.
3. For a webshop or busy website: it's better to make the change again directly on production (the same steps as on staging, now that you know they work) rather than transferring the database. Or plan a quiet moment with a brief pause of the shop.
4. Afterwards, check production: the checklist from lesson 8.2, and the noindex tickbox.

Staging is a place to learn what happens. The change itself is safest when carried out again directly on production.

Tidying up

A staging site that stays up for months becomes a forgotten website: not updated, with old plugins and real data. Exactly the weak spot from lesson 7.1. Delete the staging site once you're done, or maintain it as a fully-fledged website (updates, password). A clone also takes up just as much space as the original and has its own database.

Summary

• Staging is a copy of your website on its own address to test risky changes.
• Create it with your installer, your host, a plugin or by hand, preferably on a subdomain with a certificate.
• Lock it down straight away: password and/or noindex, no mail to real people, payments in test mode.
• Don't synchronise back blindly: the staging database overwrites what was added on production. Back up first, synchronise only what's needed, or redo the change.
• Delete the staging site once you're done, and don't carry the noindex tickbox over to production.

Quiz

Exercise

Exercise A8.3: Is your staging site locked down? Fill in the address of your staging site (a subdomain of your own domain, for example from exercise D8.2) and of your real website. Prove with the exercise code that the domain is yours. The program checks the staging site: does it respond via https, and is it locked down (a password prompt, or noindex in the HTML or in the X-Robots-Tag header)? Does the REST reference (wp-json) point to the staging site itself and not to your real website? And on your real website: is there no noindex there?

Further reading

These articles describe the steps in WebOké's panels; in other panels they work similarly.

• DirectAdmin guide 13.7: Cloning and creating a staging environment
• Creating a WordPress staging environment
• DirectAdmin guide 15.9: Password Protected Directories
• DirectAdmin guide 4.5: Creating and deleting subdomains
• DirectAdmin guide 13.8: Deleting an installation