WP-CLI is amazing tools for WordPress developers. I’ve heard about it thousand times, but today is the first day I used it. After trying some methods to create staging environment for my WordPress website, I found that using WP-CLI has big advantages and saves me a lot of time. In this post, I will demonstrate steps that I took to replicate a production environment to a staging environment.

Staging environment

What is a staging environment?

To work on a WordPress site, we recommend our users to install WordPress locally on their Windows or Mac computers. Once you are done and satisfied with your website, then you can upload it from localhost to live server.

There is one problem with this approach. What if something that worked on your localhost does not work on the live server? This would cause errors which can be a problem for established sites because it can affect search engine rankings, sales, first impression on users, etc.

Instead of uploading your changes to the live site, you can upload them to a staging site on the same server. A staging site is a separate development area on your site (usually a sub-domain) with restricted access. This is where you can test your changes or use it for all your development. Once you have thoroughly tested your site, you can then upload it to your live site.

Quoted from WPBeginner.

Some methods to create a staging environment

There are some ways to create a staging environment, each has advantage and disadvantage:

Manually copying files and database

  • Download all files from the production site to localhost and upload them to staging site
  • Use a tool like phpMyAdmin to export database from the production site and import to staging site
  • Use a script like Search and Replace to replace old URLs and paths with new URLs and paths.

This method works just fine, however, it has a big disadvantage: it takes a lot of time. And because of that, I would not recommend using this method.

Using backup plugins

There are some backup plugins that you can use to duplicate your production environment to staging environment (both files and database):

These plugins automatically create a .zip for all your files and database so you can upload/download much faster than the method above. Another big advantage of them is they also can help you to change your old URLs to new URLs.

This is my favourite way to create a staging environment. It’s quick and works like a charm.

However, it’s suitable when we create a staging environment on a different host from the production environment. This problem can be solved better using WP-CLI as we see later.

Other tools to migrate files and database

Migrate files

You can use cPanel to copy files if the staging and production sites are on the same host. It’s much faster than manual copy or using backup plugins.

For developers who are familiar with Git, setting up a WordPress website with Git (you can put the whole site inside a repo, or better – only your plugins and themes) and use pull/push commands to get changes. You can also use a helper tool like DeployBot to automate the process.

Migrate database

To migrate a database, a very powerful plugin WP Migrate DB can help. It can search and replace URLs, paths and export to .sql file, then you can use phpMyAdmin to import it.

Create staging environment with WP-CLI

All the method describes above are working fine. But in a specific case, they might not fit us. That’s where WP-CLI can help.

Current inputs:

  • The production website has a lot of data and it often stops PHP scripts to backup the database (phpMyAdmin, BackupBuddy, Duplicator, WP Migrate DB).
  • The staging site is on the same host with production site
  • I don’t use cPanel, I setup a server my own

Note:

WP-CLI is a command line tool, it can’t work on a shared host where you don’t have access via SSH to install software. You need a VPS or a server to continue this tutorial. If you don’t have one, you can get a VPS at DigitalOcean. I’m using a DigitalOcean for this tutorial.

Let’s copy files and database first:

Copying files

Copying files on a VPS is super easy and fast. Just run the commands:


cd /etc/nginx/html

cp -rf domain.com dev.domain.com

Here domain.com is the root folder for your production site. We will use dev.domain.com as the root folder for the staging site.

Create a new database

Run the following commands:


mysql -u Username -pPassword

mysql > create database dev;

A new database name dev is created.

Copying database

So fast:

mysqldump -u Username -pPassword orignal_db_name | mysql -u Username -pPassword dev;

Even when my database is huge, this command run in less than a minute!

Install WP-CLI

It’s very easy to install WP-CLI, just follow the steps on its homepage. Nothing more.

Create a config file for WP-CLI

We need to create a config file to tell WP-CLI where the WordPress staging site is, what URL is, etc. Run the following commands:


cd /etc/nginx/html/dev.domain.com

nano wp-cli.local.yml

And add the following content to wp-cli.local.yml (this file is located in your dev.domain.com folder):


path: .

url: http://dev.domain.com

There are more settings that you can add to the configuration file. But that’s enough for our tutorial.

Using WP-CLI to search and replace database

The feature I love most from WP-CLI is it supports searching and replacing in the database. It works exactly the same as the Search and Replace script that I mentioned above but in command line mode.

This command is all we need:


wp search-replace 'http://domain.com' 'http://dev.domain.com'

While all PHP scripts can’t perform this task because of a huge database, this command runs very fast and finishes in less than half a minute!

Done! Your files and database migrated! You just need to add dev.domain.com to your nginx (or Apache) vhost configuration and start using the staging environment.

The staging environment is exactly the same as the production environment and we can do development on it and test all new features before moving them to the production one.

After setting up, you can use Git to push/pull changes of files (plugins, themes) automatically (using web hook to run git pull on the server, I will write about this in another post) and use WP-CLI to migrate database (manually run the commands). This way you can keep your staging environment updated with the production environment. Happy development!

3 Comments

  1. And how would you update production after testing on staging? you only show one way (to set it up and clone production to staging) but entirely miss the dev->staging->production lifecycle

    1. The inverse process is similar. But I would recommend migrating only files from dev -> staging -> production, as the DB can be changed a lot when developing.

Leave a Reply