In the previous tutorial we mentioned that cloning a WordPress staging site is one of those necessary tasks when you’re working in WordPress development. We then used the RunCloud Backup system, alongside the RunCloud File Manager and WP-CLI, to clone our staging site from production. If you haven’t seen that tutorial yet, you can find it here.
Using a staging site, alongside local development and our production site, means we can test WordPress core, plugin and theme updates on an exact duplicate of our live environment, risk free.
In this tutorial we are going to go through the same process of cloning a WordPress site for staging or testing purposes on a subdomain. However today, we will create a staging clone using only the WordPress Command Line Interface (WP-CLI) alongside other terminal commands.
In these tutorials, I will be logging in to my server and issuing commands as my superuser with root privileges using the sudo program command if necessary. If you don’t have a superuser, but want to follow best practices you can create one easily by following this tutorial.
You will also need to have WP-CLI installed on your servers to complete this tutorial. If haven’t installed that yet, then not to worry, as we have an easy to follow tutorial to help you out. You will need to have it installed on both the production server and the staging server, if they are different servers.
It should be mentioned, the basic principles of this tutorial could be replicated for any other Web Application with just a few changes. Namely, replacing the WP-CLI commands with SQL commands issued directly in the database. The principle of using RunCloud Backups remains the same.
This article contains preformatted codeblocks containing code examples that can be easily cut and paste. However if you are viewing the tutorial as a Facebook Instant Article these will not be visible, due to Facebook’s policy of not supporting preformatted text. I have endeavored to include Terminal screenshots illustrating each code example for those users.
The WordPress Web Application to be Cloned
You should have a WordPress web application up and running on a RunCloud managed server. In my case I have my example site running:
A WordPress site to be cloned in this RunCloud Tutorial
I created it using the foolproof RunCloud web application creation method, more details on that can be found here. I then added just a sprinkling of dummy content.
The Web Application summary in the RunCloud dashboard looks like this:
My Example WordPress Web Application summary in the Dashboard
Configure Staging Site DNS
If your staging site is on the same server as the production site, then you do not need to make any DNS changes. Please just skip to the next step to Create an Empty Staging Web Application.
If the staging site is on a different server to the production site, then we need to make a few DNS changes. We need to configure our Staging site subdomain DNS record to point to the IP address of the staging site server.
If your staging site is on the same server as the production site, then just skip to the next step.
In my RunCloud servers dashboard panel, I can get the IP addresses for the server hosting the Staging site:
Copy the IP address from the server that will be hosting the Staging site.
Now login to wherever you are managing your DNS records from, either your VPS provider, your domain registrar, or a third party DNS provider.
Add a record for your staging subdomain. My staging subdomain is staging.an-example.com, so in my (Vultr) DNS records I added an A record, with a host name of staging and the value of my second server’s IP address.
Configure your Staging Subdomains DNS records.
I’ve also added my servers IPv6 address, you should too if you have it
Create an Empty Staging Web Application
Now we will use the RunCloud Web Application manager to create the Virtual Host configuration, and web application directory structure required for the staging site.
In the Web Application manager, on the server you wish to host your staging site, click ‘Create’ to add a new Web Application. Then configure yous staging site as follows:
Add your Staging Site Web Application.
For the domain name, use the subdomain that we just configured our DNS to serve.
Choose your web application user, in my case that is my superuser.
RunCloud provides you an option to install the web application in an amended path. I would stick with the path provided.
Remember to substitute your chosen directory name and path correctly in the tutorial commands when necessary.
Staging & Production Web Application on the Same Server
If you are creating the Staging Site on the same server, you will see both web applications in the Web Application Manager list:
Your Production and Staging Sites on the same server.[/caption]
Staging Web Application on a Different Server
If you are creating the Staging Site on a different server, you will only see the staging site web applications on the other server:
Staging Site Web Application on Staging Server.
Create an Empty Staging Database
Next, go to Databases in the RunCloud dashboard.
Add a database for the Staging site to use.
And add a user.
Then, attach your database user to your database.
If your staging site is on the same server, you will see both the production database and the staging database listed, alongside the user:
Create a Staging Database and attach a User on the production server.[/caption]
If your staging site is on a different server, you will only see the staging database and user listed:
Create a Staging Database and Database User on a separate server to production.[/caption]
Export your Production Database with WP-CLI
If you haven’t already, Log in to your production server as your superuser by ssh, and change into your Production site root folder.
$ ssh <your-superuser>@<your-production-server-ip> $ cd webapps/an-example
Use the WP-CLI wp db export command to export your production database to a file called ‘production.sql’ in your home directory. Change into your home directory and list out the contents to ensure everything went according to plan. Assuming the commands were issued correctly, you should see your ‘production.sql’ database export in your home directory.
$ wp db export ~/production.sql $ cd ~/ && ls
Export your Production database into your home directory.[/caption]
Cloning the WordPress Directory
How we will clone the WordPress directory will depend on which server we are creating the staging site on. We can create the staging site on the same server as production, or a different server.
Staging & Production on the same server – Just copy the Production Directory
Open your terminal and log in to your server as your superuser using ssh. Then change directory to your production webapps directory cd webapps, and list out the contents to ensure the application directory structure has been created.
$ ssh <your-superuser>@<your-server-ip> $ cd webapps ls -l
List the Webapps directory to make sure your Staging Site directory has been created.
If you don’t see both your staging site directory and live directory, then return to the RunCloud dashboard. Go to your Staging Site Web Application settings and click ‘Rebuild’. Now the Staging Site directory should be there when you list out the ‘webapps’ directory contents.
From within the ‘webapps’ directory, copy everything from your live site directory into the staging site directory. Change into the staging site directory, and list the contents to make sure everything copied correctly. All being well, you should see the familiar WordPress file and directory structure within.
remember to change my directory names in the commands to your directory names
$ cp -R an-example/* staging-an-example/ $ cd staging-an-example-domain && ls
Copy the contents of the Production site directory into the Staging site directory.
Staging on a different server to production – Copy the Production Directory and Database to the Staging Server
If you are not already logged into your production server, do so now, and change directory into the webapps directory.
$ ssh <your-superuser>@<your-production-server-ip> $ cd webapps
Copy the Production Directory
Now we need to compress up our Production site root directory, and save it into a ZIP archive in our home directory. Issue the zip command using your superuser privileges like so, sudo zip -r ~/production.zip an-example/.
$ sudo zip -r ~/production.zip an-example/
Change directory into your home directory, and list out the directory contents. You should now see both the production.zip alongside the production.sql:
$ cd ~/ $ ls
Your home directory with the production.sql and the production.zip
Download the Copied Production Directory and Database to your Local Machine
SCP is a file transfer command we can use on *NIX systems to transfer files between machines using SSH. If you are using a Windows machine you will need to install PSCP by PuTTy, and replace all SCP commands with PSCP
Download the files to your local machine’s desktop using SCP.
$ scp <your-superuser>@<production-server-ip>:/home/superuser/production.zip ~/Desktop $ scp <your-superuser>@<production-server-ip>:/home/superuser/production.sql ~/Desktop
Download the Production Directory and Database Export to your local machine.
Upload the Copied Production Directory and Database to your Staging Server
Upload the files from your local machine’s desktop, to your user directory on the staging server using SCP.
$ scp ~/Desktop/production.zip <your-superuser>@<staging-server-ip>:/home/superuser/ $ scp ~/Desktop/production.sql <your-superuser>@<staging-server-ip>:/home/superuser/
Upload the Production Directory and Database Export to your staging server.
You could use SCP to tranfer files directly between your production server and staging server. However, to do that you would need your production and staging servers to have an SSH Key pairing established
Login to your staging server, and list out your home directory to ensure both files have been uploaded properly:
$ ssh <your-superuser>@<your-staging-server-ip> $ ls
Make sure the production.zip and production.sql are in your staging home directory.
Prepare the Staging Site WordPress Directory
Delete the existing Staging Site WordPress Directory with sudo rm -rf webapps/staging-an-example.
$ sudo rm -rf webapps/staging-an-example
Now change into the Webapps directory, and unzip the Production Site Directory archive, using sudo unzip /home/superuser/production.zip.
$ cd webapps $ sudo unzip /home/superuser/production.zip
After the archive has been unzipped list out the contents of the webapps directory using ls. You will see we have created a new directory, named after the production directory. We need to change that directory name, into the correct staging site directory name using mv. After that, If we list out the Webapps directory using ls -l, we can see our new Staging directory has the wrong ownership.
We need to give ownership of the new staging site directory, and its subdirectories and files, to our superuser. We can do that with the chown command used recursively -R. Once we have done that, list of the contents again to make sure the ownership change has taken effect.
$ ls $ sudo mv an-example staging-an-example && ls -l $ sudo chown -R superuser:superuser staging-an-example && ls -l
We should see the following in our terminal, with the directory set up correctly:
Create the staging directory with the contents of the production.zip.
Prepare the WordPress Configuration File
Whether you have created your staging site on the same server as production, or on another server, we have now succesfully copied the production directory.
However, our staging directory has a wp-config.php file with the wrong database parameter definitions.
We could open the wp-config.php file in our favourite text editor to make the necessary changes. But it is much easier to use WP-CLI to generate a new file quickly and easily.
From within your staging site root directory, delete the extant configuration file and then create a new wp-config.php file with the correct Database parameters using WP-CLI. As ever, WP-CLI will respond with a success message, assuming everything has been configured properly.
remember to use your own database name, user and password
$ sudo rm wp-config.php $ wp config create --dbname=staging_example --dbuser=an_example_user --dbpass=example_password
Delete the existing WordPress configuration file and use WP-CLI to create a new one.
Import the Production Database into the Staging Database
We have an exported copy of our production database in our home directory, named production.sql. From within our staging directory, issue the following command to import its data into the staging database. Once complete, WP-CLI should output a success message.
$ wp db import ~/production.sql
Import your production database into your staging database with WP-CLI.
Update the Cloned Database
Our production database has now been cloned into the staging database. However we still need to update the database entries to replace our production domain with our staging domain.
There are several methods to do this, from using plugins, to running SQL queries directly in the database. But we are going to use the power of WP-CLI once again.
From your staging site root directory, issue the WP-CLI wp search-replace command to replace all entries for your production site url with the staging site url. Your terminal will print out you database tables and columns, with a column showing replacements made. It will also give you a summary message like so:
To be safe, since this is your database, you could issue this command with the –dry-run option first. This will display all the same information as if the search-replace had been issued, but will not execute the changes.
$ wp search-replace 'http://an-example.com' 'http://staging.an-example.com'
Use WP-CLI to udpate your staging database with the correct staging domain.
With this done, we could visit our staging site directly. But let’s tweak it a little…
A few more tweaks…
I like to tweak my staging site title, to make sure it is apparent that this is not the production site. I find this lessens the risk of confusing the two, and effecting changes on the wrong one.
Let’s Use WP-CLI to update the site name and description. From within the staging site root domain, we can issue some wp option update commands to update the site title and description. As usual, each command will be greeted with a success message.
$ wp option update blogname 'RunCloud Staging Different Server' $ wp option update blogdescription 'Now this is a staging demo on a different server'
Update your Staging Site Title with WP-CLI
Your Cloned WordPress Staging Site
And we are done with this method. Visit your staging site at it’s domain, and you should be greeted with your perfectly cloned WordPress staging site:
A Cloned WordPress Staging Site
And that is it, we are done…
Now we have our staging site set up, we should look at a workflow that includes local, staging and production, and incorporates a version controlled deployment method.
It would make sense to further integrate WP-CLI Aliases, so we can manage all our remote sites and development branches from our local machine.