Whether you’re a developer or an admin overseeing multiple WordPress sites, I’m sure you’ve thought to yourself: “I wish I could do this faster.” From creating a fresh install for testing to updating the same plugin on multiple sites, there are so many tasks you’ll find yourself doing over and over again.
WP-CLI is the answer to your woes and one of my favorite time-saving tools for web development.
This is the final post in our six-part series focusing on WordPress for advanced developers. This series follows on from our popular WordPress Development for Intermediate Users, which introduced you to some meaty coding topics, including theme development in detail, making themes customizer-ready, building plugins, custom post types and taxonomies, queries and loops, custom fields and metadata, and localization.
WP-CLI is a command-line utility (hence the CLI part) that gives you control over many aspects of WordPress. In this tutorial, I’ll show you how to use WP-CLI, how to create powerful bash scripts for even more powerful automation, and how to manage multiple WordPress sites at once.
That’s a tall order; we’d better get started!
Note: It’s important that you have a working knowledge of PHP as this is the foundational language of WordPress for this series, which covers advanced topics aimed at developers. I’ll be referring to code snippets throughout this series.
- 1 Installing WP-CLI
- 2 Basic WP-CLI Usage
- 3 Global Parameters
- 4 Configuring WP-CLI
- 5 Using SSH With WP-CLI to Automate WordPress Tasks
- 6 Further Automation With Bash Scripts
- 7 Streamlining Your Web Development Workflow With WP-CLI
Installing WP-CLI is super-easy. Just issue the following commands, which can also be found on the WP-CLI home page:
Regretfully, Windows has limited support; you get the most mileage out of WP-CLI on Unix-like environments. You can find some additional notes on Windows installation in the documentation. If you’re having trouble, use what we learned in the terminal tutorial and SSH into a remote server, which is most likely to be a Unix environment, and practice there.
Basic WP-CLI Usage
The use of WP-CLI is easy and intuitive once you’ve used a few commands. It always starts with the base
wp command, followed by one or more subcommands. Subcommands are used for grouping, which makes things logical. For example, here are commands to get and update a specific option in the database:
One of my favorite – and most frequently used – commands is
search-replace. This enables you to search-replace a term within the WordPress database. It handles serialized strings properly; unserializing them, making the replacement and then re-serializing them.
As you can see, using WP-CLI is not difficult. Take a look at the WP-CLI commands documentation for more information. I’ll be going through some more commands shortly, but first I want to show you some advanced setup and options.
WP-CLI has a bunch of global parameters that can be added to any command. You can read about them on any documentation page in the right-hand sidebar block. I’ll go through the most useful ones.
This parameter will suppress info messages that are normally displayed when executing a command. I use this when creating bash scripts that execute a bunch of WP-CLI commands at once. More on this later.
By adding this parameter, you can execute the WP-CLI command on a remote server instead of locally. This is what we’ll be using to control multiple WordPress instances by issuing local commands.
You can explicitly set the path of the WordPress installation. Normally, WP-CLI is run from within the root directory of the WP installation. If this isn’t the case, you can use
--path to tell WP-CLI where WP is.
This will prompt you to fill out all parameters. Useful if you don’t know the parameters off the top of your head or if you add WP-CLI as part of a larger script that others will use.
Not a global parameter per se because it doesn’t apply to all commands, but I use it sometimes on remote servers where I must use sudo for some reason. If you use sudo, you must use this parameter to make sure WP-CLI performs this action. That said: try to avoid using sudo for commands when possible.
If you use these parameters a lot, you can set them in a configuration file. There are three configuration files that are parsed and used (if found) in the following order:
wp-cli.local.ymlinside the current directory or above
wp-cli.ymlinside the current directory or above
Use the first two for project-specific configuration. The final file can be used to configure global options that you want to use on every project. The config file can also include defaults for sub-commands. Let’s look at an example:
Note how I’ve used the global parameters. There are a couple of global parameters like
disabled_commands which can not be set inline with commands; you must use the yml file.
I’ve added some defaults for the
wp core config command which sets up the
wp-config.php file. This is a setup I’d use for development; I’ve added my database username/password and additional PHP constants to define which can be useful while developing.
Using SSH With WP-CLI to Automate WordPress Tasks
As of version 0.24.0, WP-CLI natively supports SSH. Previously you needed a third party command to get things done. WP-CLI has implemented SSH usage extremely efficiently. Let’s see how it works.
Let’s think like a WordPress agency that hosts websites for clients might think for a minute. Our websites all have a common “agency” plugin, which gives our users some useful information and a common control panel. We now have three client websites and a local test site, which we use to test the agency plugin. Let’s see how we can manage all of these sites at once.
Our first task is to make sure WP-CLI is available on all servers. Once that’s done, let’s go into the
wp-cli.yml file within the local WordPress installation.
I’ve added aliases for each website, followed by another alias that groups all websites together. I could update all plugins on all sites using the following command:
Just replace “@all” with the alias for a specific site to execute a command against that single site.
Further Automation With Bash Scripts
Bash scripts are available in Unix environments and are like bat files in windows. I use them frequently to bundle together commands that can then be run at once using a single command.
BASH Scripts: The Basics
Navigate to one directory above your WordPress root folder and create a file named
test.sh. Edit this file, adding the following content:
You should be familiar with both lines. The first one creates a directory named “test” and navigates into it. The second line downloads the core files needed for WordPress using WP-CLI.
To execute both commands at once simply run
Creating a New Installation
When testing plugins and themes it’s always a good idea to see what happens using a fresh installation of WordPress. You might have already added some options that your product relies on but doesn’t check for – all sorts of things could go wrong.
Here’s a little script that you can use to create or remove-and-recreate a WordPress installation in a given folder:
It takes one parameter: the name of the directory you want your WordPress installation in. If it doesn’t exist it creates the directory, goes into it and configures and installs WordPress. If it already exists it just resets the database and reinstalls WordPress.
You can run it using
bash install.sh mydir. Super simple and super helpful. You can add all the bells and whistles in there like adding PHP constants.
Streamlining Your Web Development Workflow With WP-CLI
WP-CLI is a worthy addition to any WordPress power user’s toolbox. As a site manager, it allows you to perform common tasks across multiple sites. And as a developer, it provides you with automation tools to lessen your workload.
When combined with bash scripts it becomes even more powerful allowing you to define your own workflow, creating shortcuts that can shave hours off your day.
Why 100 is NOT a Perfect Google PageSpeed Score (*5 Min Watch)
Learn how to use Google PageSpeed Insights to set realistic goals, improve site speed, and why aiming for a perfect 100 is the WRONG goal.