How to Optimize Your Agency’s Workflow with WP-CLI Commands

Is your agency spending a lot of time on busy work and repeating the same efforts time and time again, from one client to the next? Is the development team wasting a lot of their focus and mental energy on menial tasks and boilerplate work? What if you could free up some or all of these resources and invest them into the added value that the client will see and evaluate instead?

WP-CLI is a command-line tool that can help you accelerate the way you interact with WordPress websites. It is also a framework you can use to formalize and automate all of the processes that are shared amongst your clients if you’re a developer or an agency. Because of its versatility and simplicity of use, WP-CLI has been part of SiteGround’s preinstalled toolkit since 2013. SiteGround has also been one of the first sponsors of the project and continues to do so for the past 3 years, 2020 including.

One of the main reasons for SiteGround’s support is the fact that WP-CLI perfectly complements their mission to provide powerful, yet simple to use tools for WordPress processes automation and optimization. In fact, together with SiteGround, we released this awesome webinar for everyone who hasn’t had the opportunity yet to find out how useful WP-CLI can be:

As one of the main co-maintainers of the WP-CLI ecosystem, I was really glad to accept this new invitation from SiteGround’s and share some practical tips on how you can make use of WP-CLI to level up your workflows and have your clients get more bang for their buck!

Accelerating administrative efforts

WP-CLI is first and foremost a direct replacement to a WordPress site’s admin dashboard. Instead of providing a graphical web interface where you click through menus to get things done, it provides a text-driven command-line interface to perform these same tasks using written wp-cli commands. What at first sounds like added effort eventually turns out to be an infinitely more expressive way of letting the site know what you need to have done, and this makes it scale so much better for complex use cases.

As a result, while it is not necessarily faster to type a command to make a change to a post than it is to click the corresponding button on that same post, the difference becomes more apparent once you deal with multiple posts instead. While you might shudder at the thought of manually making a change on the admin backend to thousands of posts on a large site, all you need for doing so with WP-CLI still happens to be a fairly simple command, usually a one-liner. Granted, it will take a bit more time to execute than it would for a single post, but you can just leave it running in the background and focus on something else in the meantime.

To show an example of this effect, let’s imagine you have a huge multisite network with thousands of sites. An existing user has proven their worth in terms of helping moderate the entire network and is to be promoted to being an administrator on all the sites. How would you go about doing this via the graphical admin backend?

It turns out that this is quite easy to do via WP-CLI:

wp site list --field=url | xargs -n1 -I {} wp --url={} user set-role <user-to-promote> administrator

The above command will retrieve the list of all site URLs for the network, and for each of these sites, set the role of the user in question to that of “administrator”. And while this might take a few minutes to complete, it is a one-liner that does the work for you. Using the web-based admin backend would probably cost you hours to do the same, or require you to write a one-off plugin to do so in a more efficient way.

For an overview of all the bundled commands that come by default with WP-CLI, you can browse the command reference at https://developer.wordpress.org/cli/commands/.

Using agency-wide defaults

WP-CLI supports configuration files at the global level as well as at the project level.

The global configuration file is best used for defining a developer’s personal preferences. The project-specific configuration file however should best be managed centrally across the agency and treated as a part of the project, just like your composer.json file.

To use a project-specific configuration file, all you need to do is create a wp-cli.yml file within the site’s root folder. It will accept a few entries that are specific to configuration files, like providing an array of commands to disable for that specific site. But it will also accept default values for any of the available commands with a unified syntax.

Let’s look at an example configuration file for a hypothetical project:

# WordPress Core is installed in a subfolder.
path: wp-core/
# Load WP-CLI-specific init code before executing a command.
require: wp-cli-init.php

# Provide default flags for the config create command.
config create:
    dbuser: root
    dbpass: 
    extra-php: |
        define( 'WP_DEBUG', true );
        define( 'WP_POST_REVISIONS', 50 );

# '_' is a special value denoting options for this wp-cli.yml.
_:
    # Inherit configuration from an arbitrary YAML file.
    inherit: agency-defaults.yml
    # Merge subcommand defaults instead of overriding.
    merge: true

As you can see, it is pretty straight-forward to provide defaults for any known command. Also, you can load centralized YAML files within such a project-specific config file as well, if you need it.

You can read more about WP-CLI configuration files at https://make.wordpress.org/cli/handbook/references/config/.