How to Setup a Staging WordPress Server

Having a staging server for WordPress is quite useful for testing new features without the worry of breaking something in production. It is also helpful when you have a multi user environment and need to test something that could impact others. In this article it is assumed that your WordPress instance has SELinux enabled as is the case on RHEL/CentOS for example. On other distros like Ubuntu or Debian you can omit the steps specific to SELinux.

Assuming a fresh staging WordPress is ready with the SSL cert and hostname taken care of, you can import server files and the database.

Exporting Production Data

On the production server with the WordPress database, you will need to copy the database with mysqldump:

mysqldump wordpress | gzip > wordpress.sql.gz

Export the server files with the selinux context:

tar --ignore-failed-read -czvf /tmp/wordpress.tar.gz /srv/wordpress --selinux

Note that we add --ignore-failed-read because sometimes a file could change on production causing the tar program to exit. This will cause it to continue running, but it will still has a return code of 2.

Importing Production Data

Extract WordPress server files to where the server files will be stored, e.g. /srv/wordpress:

tar -xzvf wordpress.tar.gz

To add system_u to the context:

chcon -R -u system_u -t httpd_sys_rw_content_t /srv/wordpress

You should verify that apache:apache is the user:group and system_u is mapped:

ls -lZ

-rw-r--r--. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 index.php
-rw-r--r--. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 license.txt
-rw-r--r--. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 out.txt
-rw-r--r--. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 readme.html
-rw-r--r--. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 wp-activate.php
drwxr-xr-x. apache apache system_u:object_r:httpd_sys_rw_content_t:s0 wp-admin
---- snip ----

SQL dump import:

gunzip wordpress.sql.gz && mysql < wordpress.sql

Final Configuration

The wp-cli tool is quite useful and can be installed from following instructions here.

Use wp search-replace to find all references to the production server and replace it with staging server:

wp search-replace https://www.example.com https://www-staging.example.com

The last thing to do is to verify that everything needed for the WordPress plugins is done.

Oxygen is one example that needs some extra configuration on migration such as css cache generation and shortcodes. The next items will be located within the wp-admin area in the browser.

Generate CSS Cache (in browser):

/wp-admin/admin.php?page=oxygen_vsb_settings&tab=security_manager OR
Oxygen -> Settings ->  Security -> Sign All Shortcodes

Generate shortcodes (in browser):

/wp-admin/admin.php?page=oxygen_vsb_settings&tab=cache OR
Oxygen -> Settings -> CSS Cache -> Regenerate

Notes

It is best to discourage your staging site from being indexed by search engines. You can disable that by:

/wp-admin/options-reading.php OR Settings -> Reading -> Discourage search engines

If only a white page loads then chances are there is a plugin needing changes. You can go through and disable the plugins one by one to find the culprit. If the website redirects you to the old server, there might be a reference in the database needing to be changed. You can use the wp search-replace tool to correct this.

Troubleshooting

The wp-cli tool cant connect to database:
Make sure the configuration in your wp-config.php is correct.

The wp-cli tool complains about php modules:
There might be other steps needed that were forgotten such as installing required packages for php components. Also, if using a specific version of php (remi), you might need to enable some environment variables to point to correct php path.