Cloning a WordPress Site for Staging
Method 1 | Using RunCloud Backups and WP-CLI

Cloning a WordPress Site for Staging <br> Method 1 | Using RunCloud Backups and WP-CLI

Cloning a WordPress staging site is one of those necessary tasks when you’re working at a professional level in WordPress development. It is a good idea to use a workflow that includes local development, alongside online staging and production sites.

In today’s tutorial, we are going to use the RunCloud Backup System to clone a production site into a staging site. The beauty of using the backup system, is that it is incredibly easy to clone a staging site from any RunCloud managed server to any other RunCloud managed server.

If you’ve never made a backup using RunCloud, we have an easy to follow tutorial here. It’s a very handy tool, and the cost for your backups is very reasonable indeed!

To make the database changes necessary (updating the site url), we are going to use WP-CLI. Therefore, 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 another easy to follow tutorial to help install WP-CLI.

I will be logging in to my servers and issuing commands as my superuser, although I won’t need to be issuing any commands with elevated sudo privileges today. If you don’t have a superuser, but want to follow best practices you can create one easily by following this tutorial.

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 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:

View the Example WordPress Web Application summary in the DashboardMy 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.

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.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.

staging.an-example.com

Configure Staging Domain DNS 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.

Create a Staging Web Application Create a Staging 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.

/home/superuser/webapps/staging-an-example

Remember to substitute your chosen directory name and path correctly in the tutorial commands when necessary.

Configure your empty Staging site using the Web Application Manager Configure your empty Staging site using the Web Application Manager.

Create an Empty Staging Database

Next, go to Databases in the RunCloud dashboard.

Add a database for the Staging site to use.

staging_example

And add a user.

example_user

Then, attach your database user to your database:

Create a Staging Database and Database User.Create a Staging Database and Database User.

Clone the WordPress directory using a RunCloud Backup

You will need to have an existing RunCloud Backup of your Production WordPress site. At the moment RunCloud can’t make backups on demand. The waiting period for a new backup to be created after configuration, is 1 hour. If you do not have an existing backup, you will need to configure one and wait an hour.

In your RunCloud management console, go to your Web Application Backups. Click on the Web Application name of the backup you want to use:

Click on the name of your Web Application Backup to go to it's settings Click on the name of your Web Application Backup to go to it’s settings.

From within the settings page of the Web Application backup you want to use, click this icon to configure restore settings:

Click the icon to configure restoration parameters. Click this icon to configure restoration parameters.

From the Restore Backup settings, choose your Staging site web application inside the server you wish to restore to.

staging-an-example inside Server More Runcloud Tutorials

Choose to restore the backup to your Staging Site Web Application.Choose to restore the backup to your Staging Site Web Application.

Prepare the WordPress Configuration File

The entire contents of your production site on one server, have now been copied into the staging site directory on another server.

That includes the wp-config.php file, with the incorrect configuration parameters for the database and user.

We can fix this using either the RunCloud File Manager or by using WP-CLI

Edit WordPress Configuration using the RunCloud File Manager

Visit the Staging Web Application in your RunCloud server, and go to the ‘File Manager’:

Go to the Staging Site Web Application File ManagerGo to the Staging Site Web Application File Manager

Find the ‘wp-config.php’ file, click on it so that it is highlighted pink. While it is highlighted pink, click on ‘View/Edit’ in the top file manager menu bar:

Click to edit the WordPress configuration file.Click to edit the WordPress configuration file.

In the RunCloud File Editor, enter your staging site database details.

Remember to use your own staging database details

/** The name of the database for WordPress */
define( 'DB_NAME', 'staging_example' );

/** MySQL database username */
define( 'DB_USER', 'example_user' );

/** MySQL database password */
define( 'DB_PASSWORD', 'example_password' );

Enter your staging database connection parametersEnter your staging database connection parameters

Press CTRL+S to save your changes.

Edit WordPress Configuration using the WP-CLI

If you would prefer to fix the WordPress configuration file using the terminal, then WP-CLI is your friend.

Connect to staging site server by ssh as your superuser, who should also be the web application owner.

$ ssh <your-superuser>@<your-server-ip/your-staging-site-domain>

Change directory into the staging site root directory. Delete the existing WordPress configuration file, and create a new one using WP-CLI. Remember to replace the dbname, dbuser, and dbpass, with the name of the database, the database user, and the database password you created earlier.

You could edit the wp-config.php file in your favourite text editor. But if you were going to do that, you may as well use the RunCloud File Editor method above…

WP-CLI will output a success message once the new wp-config.php file has been created.

$ cd webapps/staging-an-example
$ rm wp-config.php
$ wp config create --dbname=staging_example --dbuser=example_user --dbpass=example_password

Delete the original WordPress Configuration file and create a new one with WP-CLIDelete the original WordPress Configuration file and create a new one with WP-CLI.

Whichever method you chose, your cloned WordPress directory structure and files are now ready to go.

Cloning the Database using a RunCloud Backup

You will need to have an existing RunCloud Backup of your Production WordPress database. At the moment RunCloud can’t make backups on demand. The waiting period for a new backup to be created after configuration, is 1 hour. If you do not have an existing backup, you will need to configure one and wait an hour.

In your RunCloud management console, go to your Database Backups. Click on the Database name of the backup you want to use:

Click on the Database Name of the backup you wish to use, to go to its settingsClick on the Database Name of the backup you wish to use, to go to its settings

From within the settings page of the Database backup you want to use, click this icon to configure restore settings:

Click this icon to configure restoration parameters.Click this icon to configure restoration parameters.

From the Restore Backup settings, choose your Staging site web application inside the server you wish to restore to.

staging_example inside Server More Runcloud Tutorials

Choose to restore the backup to your Staging Site DatabaseChoose to restore the backup to your Staging Site Database.

Update the Cloned Database

Our production database has now been cloned into the staging database. However we still need to update the database, to replace all entries of our production domain with our staging domain.

No need to mention that there are several methods to do this (but I just did), as we are going to use the power of WP-CLI once again.

WP-CLI wp search-replace is truly a thing of beauty.

Make sure you are in your Staging Site root directory

$ cd ~/webapps/staging-an-example

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 Search-Replace to update your database entries with the staging domain.Use WP-CLI Search-Replace to update your database entries with the staging domain.[/caption]

At this point we have a staging site up and running. Nothing is stopping us from visiting it at our staging domain. However, let’s use WP-CLI to make a few more tweaks, just like last time.

A few more tweaks…

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 'Example Staging'
$ wp option update blogdescription 'This is the staging site'

Update your Staging Site TItle with WP-CLIUpdate your Staging Site Title with WP-CLI[/caption]

Your Cloned WordPress Staging Site

And we are done. Go ahead and visit your staging site:

http://staging.an-example.com

And enjoy the fruits of your labour, a perfectly cloned staging site:

A Cloned WordPress Staging Site using RunCloud BackupsA Cloned WordPress Staging Site using RunCloud Backups[/caption]

What next?

Well, really we should incorporate our Staging site into a version controlled deployment workflow. We might even set up WP-CLI Aliased to be able to manage our Staging site from our local machine, as part of a remote management workflow.

And we will…

But that’s enough for now.

With a RunCloud managed server for WordPress you are in control. You can use utilities like WPCLI to really supercharge your development and deployment. Discover all the other features of the RunCloud platform by signing up for a free account today! Don’t miss out.

Ready to get started?

Start your free trial today.

Start My 5-Days Free Trial no credit card required

5 responses to “Cloning a WordPress Site for Staging
Method 1 | Using RunCloud Backups and WP-CLI”

  1. Vyse Gonzo says:

    This would be a lot easier if there is an on-demand backup since. Last time I try using runcloud backup I needed to wait for atleast 2hrs to get a backup.

    • Jeff Cleverly says:

      @Vyse

      I agree, The addition of on demand backup would make this less of a hassle. I raised this a feature request to make this a much more immediate process. I generally have backups running, but for those using alternative backup solutions this isn’t ideal.

      The RunCloud guys are good though, I am sure this will be coming once they have finished their work on the API.

      In the meantime, if timing is a problem, I also wrote a partner article about achieving the same thing just using WP-CLI and the terminal, here:
      https://blog.runcloud.io/2018/02/15/cloning-wordpress-staging-site-wpcli.html

  2. Nice tutorial, but that is a f’ton of steps just to get a staging site. Really, that is way too hard, not on a technical level as anyone can learn – and a lot – from these instructions, but… I think RunCloud should just implement one-click duplication/staging like one of their competitors.

    And in case anyone is interested in a way simpler solution, there is a WordPress plugin called Duplicator. It can be used to backup, migrate or simply duplicate your site – it will take care of creating a nice little package with a custom installer, and it will also replace paths and URLs on the database while installing. Plus it’s free.

    So with Duplicator the procedure would be:
    1. Create the package using the plugin
    2. Download the main package and the installer
    3. Upload to your new host/another server/wherever
    4. Set up user/database permissions
    5. Set up DNS if you want to use a subdomain (eg. staging.mainsite.com)
    5. Run the PHP installer from the new domain/staging URL
    6. Congratulate yourself on a job well done

    • Jeff Cleverly says:

      Hey Denis,

      I used Duplicator for many years prior to using tools like WP-CLI, and I think you will find this (or the following article where you just use SCP and WP-CLI) is much quicker (especially if you are using RunCloud backups and have them extant).

      Several of the steps you mentioned are the same steps here, for example all the domain stuff.

      Running duplicator is sometimes not so easy or straightforward as you are suggesting, for example if you want to run Duplicator on RunCloud you are going to have to go into the PHP settings and make several changes (open_basedir, executiion times etc – not always necessary, but if you don’t cover your bases you might regret it, especially for larger sites).

      You also have to deal with SFTP which is really tedious.

      In addition Duplicator has several problematic limitations for larger file sizes and directories etc, so often you need to configure your archives to exclude certain files, and then copy those folders over separately.

      I personally prefer using wp-cli myself (following the second tutorial), but this tutorial uses RunCloud backups to do the heavy lifting which means there is none of the setting changes required, no downloading and uploading and everything else is from within your dashboard.

      YMMV though.

  3. […] a previous article we showed you how to easily clone a RunCloud deployed WordPress staging site from a production site using the RunCloud integrated backups feature. Whilst this showed just how easy it is to clone a […]

Leave a Reply

Your email address will not be published. Required fields are marked *