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