More than 60 per cent of all websites worldwide use the WordPress content man­age­ment system (CMS). It is free, easy to install and use, and continues to be developed by a large and active community. In principle, editors can maintain content with only MS Word skills. Almost any con­ceiv­able website task can be handled by the around 60,000 plugins that are available.

But even ex­per­i­enced pro­gram­mers have had a website suddenly stop working after in­stalling WordPress or updating a plugin: a blank screen, a login area missing, or a broken website. This doesn’t have to happen. You can create a test en­vir­on­ment that lets you test any possible changes to your heart’s content, without fear of errors or time pressure, and without the risk of breaking a me­tic­u­lously crafted website. We show you how to create such a test en­vir­on­ment in our WordPress staging tutorial.

Manually setting up a WordPress test en­vir­on­ment

When a WordPress website runs smoothly, it’s generally a good idea to create two backup files. This is also re­com­men­ded before carrying out any kind of update.

Back up all the files of your in­stall­a­tion in a local directory. This typically en­com­passes three folders as well as around 20 files, the .htaccess file, and a WordPress favicon you may have set. The data can be trans­ferred using a FTP client such as FileZilla or in your webspace admin area with your provider or via web FTP.

Then log into your provider’s ad­min­is­tra­tion interface and export the WordPress database as a backup file. The file name usually comprises the database name, and sometimes a date, with the ending ‘.sql’.

Image: WordPress staging – first step: Back up the existing database
You can find the export function for the database in your provider’s interface in the customer section under databases. There you need to start MySQL or open the database.

These two backups will allow you to restore your website in the event of a crash caused by WordPress version updates or the installed plugins. At the same time, you have all you need for a WordPress test en­vir­on­ment. Now follow the steps below:

  1. Create a sub­dir­ect­ory for your WordPress staging en­vir­on­ment on the web server. You can do this in your provider’s ad­min­is­tra­tion area under ‘Use webspace’ or by using an FTP client like FileZilla. Here, for example, the directory is called www.ex­ample­do­main.com/test-stage.
Image: Subdirectory for a WordPress test environment
All the data of the locally backed-up WordPress in­stall­a­tion is copied into the newly created directory ‘test-stage’.
  1. Then, you’ll need a new (empty) database for the cloned website. After this has been created by your provider, note down the access data shown.
  2. Open the locally stored file wp-config-sample.php in an editor and enter the access data for the newly created database:
Image: WordPress test environment: setting up a database access
The access data are entered into the fields as shown.

When working in the WordPress staging en­vir­on­ment, it’s also strongly re­com­men­ded that you activate debug mode:

define( 'WP_DEBUG', true );

The WordPress staging site has a different address than the live website. This has to be noted by using the following two code lines in the file wp-config.php:

define('WP_SITEURL', 'https://exampledomain.com/test-stage');
define('WP_HOME', 'https://exampledomain.com/test-stage');

Anyone familiar with MySQL can manually change these two entries at a later stage directly in the newly created database. If a subdomain has been chosen, it replaces this entry.

The file wp-config-sample.php is saved as wp-config-test.php, so that the wp-config.php of the backup file is not over­writ­ten. Next, the wp-config-test.php file is uploaded to the ‘\test-stage’ directory via FTP and renamed as wp-config-php, allowing WordPress to integrate this file with the correct name into the test en­vir­on­ment.

  1. The new database now has to be populated with content. This can take a little while.
Image: WordPress test environment: uploading the backup file
The saved SQL file is now uploaded into the newly created database.
  1. The manually con­figured WordPress staging en­vir­on­ment can be accessed by the ad­min­is­trat­or or developer by visiting ex­ample­do­main.co.uk/test-stage/wp-admin.

You can also decide whether a subdomain like ‘test-stage.ex­ample­do­main.com’ makes sense. The subdomain then needs to refer to the newly created directory.

Con­fig­ur­ing a WordPress test en­vir­on­ment with a plugin

As already mentioned, there are thousands of plugins for WordPress, including plugins for du­plic­at­ing or cloning a website. The ‘WP Staging – DB & File Du­plic­at­or & Migration’ plugin is par­tic­u­larly popular. This automates the process to a large extent. Du­plic­at­ing an existing WordPress in­stall­a­tion into a test en­vir­on­ment is no problem at all with the free version of the plugin. For those who want more – such as carrying suc­cess­ful changes over to the live site or cloning to other domains or databases – the paid Pro version can be purchased. At the time of writing this tutorial, the plugin was tested up to WordPress 5.5.1. It is available in English, German, and Spanish.

Image: Creating the WordPress test environment with the plugin WP Staging
After com­plet­ing the du­plic­a­tion process, a link to the staging site will be provided in the plugin window in the WordPress backend, allowing you to log in.

The entire cloning process for a complete test website (without a shop function) takes 2.5 minutes. As a result, the user receives a link that they can use to log in with their usual admin data. With the free version of the plugin, all existing database tables are newly created in the same database with another table prefix. When working in the WordPress staging en­vir­on­ment, only these new tables are changed. The database tables of the actual WordPress in­stall­a­tion remain un­af­fected. An advantage of this method is that web tariffs for only one database do not require an upgrade.

Pro­tect­ing the WordPress test en­vir­on­ment

To protect the WordPress test en­vir­on­ment against undesired visitors, dir­ect­or­ies can be protected in your provider’s ad­min­is­tra­tion area, including the directory for WordPress staging. With IONOS, you can find this section under ‘Hosting’ in ‘Webspace’. There you’ll find the menu item ‘Protected dir­ect­or­ies’ via the cog symbol. Setup is easy. But remember to note down your password in a secure place!

Another way to protect the directory is offered by the .htaccess file in the root directory of the WordPress test en­vir­on­ment. Here, open the locally saved .htaccess file with an editor and insert the following lines:

AuthType Basic
AuthName ‘Testsite’
# Store the password file with the absolute server path #
AuthUserFile /homepages/99/d1234567890/htdocs/test-stage/.htpasswd 
Require valid-user

To create the .htpasswd file, there are many online gen­er­at­ors that produce character strings using an en­cryp­tion process, such as:

Testsite:$1$xyUaMnyQ$AbkfDta7T876ObPNYaoj1.

This line is likewise saved as .htpasswd with a text editor. If a test editor allocated file endings, you can change this manually after uploading it to the root directory of the WordPress test en­vir­on­ment. When accessing the WordPress staging site, a request will now appear for the username and password.

Local WordPress test en­vir­on­ment

A local staging en­vir­on­ment is also useful for (further) de­vel­op­ing a WordPress site. This keeps the de­vel­op­ment process protected against any external attacks, since there is no con­nec­tion to the internet. To work in this way, the computer needs to be able to run as a server and requires special server software. Why? The script language PHP, for instance, can’t be in­ter­preted by a browser. It needs the services of a server.

Software that can implement this locally include MAMP or XAMPP. The latter is open source and works on Linux, Windows, and macOS. It was developed by ‘Apache Friends’ – a non-profit project for sup­port­ing the Apache web server and home of the XAMPP project. This type of WordPress staging is primarily used by pro­fes­sion­al developer teams.

Ad­vant­ages and dis­ad­vant­ages of both variants: local vs. online WordPress staging

Let’s conclude by comparing the ad­vant­ages and dis­ad­vant­ages of both types of WordPress staging.

Local WordPress test en­vir­on­ment Online WordPress test en­vir­on­ment
Ad­vant­ages - No internet con­nec­tion required- De­vel­op­ment and troubleshoot­ing without jeop­ard­ising the live website- Secure against attack attempts - Automated with a plugin and quickly created- Changes can be pushed to the live website with a suitable plugin
Dis­ad­vant­ages - Requires the local in­stall­a­tion of server software- Changes to the live website have to be im­ple­men­ted manually - Test en­vir­on­ment is vul­ner­able to attack like the website itself- Con­veni­ent work requires a paid plugin- Can cause extra hosting costs for added necessary database
Summary

WordPress staging is an elegant and secure way to further develop and troubleshoot WordPress websites. Using a plugin for this work offers con­sid­er­able con­veni­ence benefits. A WordPress test en­vir­on­ment is in­dis­pens­able for anyone who develops WordPress plugins or themes them­selves.

Go to Main Menu