Making a test environment

A test environment — usually called staging — is a complete second copy of your website on an address of its own, where you can break things. Try the new theme, update the plugin you do not trust, rewrite the checkout page. Nobody is looking, and your live site does not notice.

When you are happy with it, you push the parts you want back to the live site. That last step is the one with the sharp edge, and most of this page is about it, because the honest version is not the version most tools tell you.

Making the copy

You give it a name — nearly always a subdomain of your own site, like staging.yoursite.com — and the panel does the rest:

1. The address is created, with its own certificate, so the copy is on https:// like the original.
2. Your files are copied. Everything: WordPress, your theme, your plugins, your images.
3. A second database is made and filled with a copy of your data.
4. Every web address inside the copy is rewritten from yoursite.com to staging.yoursite.com, in a way that does not damage your settings. More on that below, because this is where the cheap tools go wrong.
5. Four things are changed to make it a test site rather than a second live site — see the next section.

A big site takes a few minutes. On some servers the file copy is instant, because the filesystem can share the data between the two until one of them is written to.

You can make the copy again whenever you like: "refresh from live" throws the copy away and takes a fresh one. Anything you had on the copy is gone, so a restore point of the copy is taken first, just in case.

What makes it a test site and not a second live site

The first three are done for you. There is a fourth thing worth knowing: only scheduled mail is switched off. A plugin that sends an email while you are clicking around the copy still sends it. If that would matter — a shop, a membership site — put a password on the copy as well. That asks for a name and password before WordPress even starts, so nothing reaches it that you did not do yourself.

"Ask search engines to stay away" is a request, not a wall. The password is the wall.

Why the addresses cannot just be search-and-replaced

Your database is full of your own web address: in settings, in menus, in widgets, in the theme options, in every plugin that stores a link.

WordPress stores a lot of that in a packed format that records how long each piece of text is. Replace yoursite.com with staging.yoursite.com with a plain search-and-replace and the text gets longer while the recorded length does not — and WordPress can no longer read it back. The result is a site whose front page looks perfectly fine and whose widgets, theme settings and plugin configuration are quietly gone. You find out weeks later.

The panel uses WordPress's own tool for this, which unpacks each value, changes it, and packs it back up correctly. It also deliberately does not touch the bare yoursite.com on its own — only full web addresses — because your email addresses contain it too, and info@yoursite.com must not become info@staging.yoursite.com.

Pushing back to the live site

Two halves, and you choose them separately.

The files

Your theme, your plugins, WordPress itself. This is the safe half: nothing your visitors wrote lives in a file. A theme change, a template change, a plugin you installed and configured — files.

Not copied, whatever you choose:

• Your configuration file. It holds the copy's database details. Pushing it would point your live site at the test database, which is the worst thing this button could possibly do.
• Your .htaccess. It carries the security rules and any password you put on the copy. Pushing it would put your live site behind the copy's password.
• Your uploads folder. Photographs you added to the live site since you made the copy are not on the copy, so overwriting the folder would delete them. There is a switch if you really want it.

The data

Posts, pages, orders, customers, comments, settings — everything in the database. Here is the part you should read twice:

A database push is an overwrite, not a merge. Nothing merges two WordPress databases. Not this panel, not Plesk, not the paid tools. Both sides have their own numbering, both keep whole settings screens in one packed value, and nothing anywhere records which of two versions of a row is the newer intention rather than merely the later save. Anything that calls itself a "sync" is picking a side per table and hoping.

So you choose which parts to overwrite:

Three sentences the panel puts on the screen, and they are worth repeating:

• Changed a theme or a template? Push the files only.
• Does your site take comments, sign-ups or orders? Do not push the database.
• Do you have a webshop? Never push a database that is older than your last order. Orders, stock and customer accounts all live in it.

"These things changed on your live site"

This is the part that most tools do not do at all.

At the moment the copy is made, the panel takes a fingerprint of every part of your live database. Before you push anything back it takes the fingerprints again and compares them. So instead of "are you sure?", you get:

These tables changed on yoursite.com since you made the copy: your posts, your settings.

And if one of them is a part you are about to overwrite, the push stops and says which. You can go ahead anyway if you know what you are doing, or — nearly always the cheaper answer — refresh the copy from the live site and redo your work on top of what is there now.

Something that changed and that you are not overwriting is mentioned and does not stop anything. A warning that stops everything is a warning people learn to click through.

Going back

Every push takes a restore point of your live site first, and it is not optional. Files and database, before a single byte is overwritten. If a push was not able to take one, the push does not happen.

So if something is wrong afterwards, you put it back — the whole site, in one action — from the same list of restore points you use for updates. The record of the push says exactly which one it took.

Testing an update on the copy first

Once a copy exists, updates get a safer route. The panel can:

1. refresh the copy from your live site, so it is testing today's site;
2. run the update on the copy, with all the usual checks;
3. and only if the copy is still healthy, run the same update on the live site.

If the copy breaks, your live site is never touched — and the broken copy is left as it is, so you or your hosting provider can look at what went wrong.

Ordinary updates already put themselves back when they break something, within about a minute. This is for the case where even a minute is too long: a shop during the sales, a site that is being demoed tomorrow.

Getting rid of it

A test environment is a whole second website: it uses disk space and a database. When you no longer need it, remove it like any other site. Removing the copy changes nothing about your live site — the connection between the two is a note the panel keeps, not a link inside WordPress.

From the command line

If you have SSH access:

# See what would happen, without doing any of it.
corectl wp clone yoursite.com --to staging.yoursite.com --dry-run on

# Make the copy. --protect on puts a password on it as well.
corectl wp clone yoursite.com --to staging.yoursite.com --protect on

# Refresh it from the live site.
corectl wp clone yoursite.com --to staging.yoursite.com --replace on

corectl wp clones                             # which copies exist, and of what
corectl wp drift staging.yoursite.com         # what changed on the live site since

Pushing back:

# Always first: the plan, what changed on the live site, and the advice.
corectl wp push staging.yoursite.com --tables settings --dry-run on

# Files only. Your live data is not touched.
corectl wp push staging.yoursite.com

# Settings, keeping your posts and your customers.
corectl wp push staging.yoursite.com --tables settings

corectl wp snapshots --site yoursite.com      # including the one taken before the push

Testing an update on the copy first:

corectl wp safe-update yoursite.com --mode clone --policy on

See also

• Your WordPress sites
• What you can do yourself
• Where a website is served