Version 1.2.0 released

Happy release day!

After 325 merged pull requests, we’re excited to bring you WP-CLI v1.2.0, chock full of enhancements, bug fixes… and a bootstrap refactor.

But first…

We have a new logo!

Coming soon to a laptop near you:

Thanks to Chris Wallace and the crew at Lift UX for their work, as well as everyone who responded to my pings about feedback.

Commands abstracted to distinct packages

We’ve split up the project!

The main wp-cli/wp-cli repository now only contains the framework itself. All of the bundled commands can be found in separate repositories. For instance, the wp cache * series of commands are now located at

This abstraction provides a few benefits:

  • While developing, the tests are only run for the specific component you’re working on, making the feedback loop much shorter.
  • Individual command packages can be controlled and set up independently, opening up the opportunity for better collaboration.
  • Hotfixes and intermediary releases can be published for individual commands, that can then be updated through the built-in package manager.
  • Tests run really fast now.
  • When you submit a pull request, you don’t have to wait two hours for the tests to run.

For those using WP-CLI via Composer, you can contribute improvements to packages as you’d normally contribute to Composer dependencies. Use composer install --prefer-source to install dependencies as Git clones.

For those using WP-CLI via Phar downloadable, you can contribute improvements by installing the package (which will override the bundled version). For instance, with the cache command, this is:

$ wp package install
$ cd $(wp package path wp-cli/cache-command)

Check out #3728 for the original history. For a better understanding of the underlying infrastructure, read Alain’s posts about the new bootstrapping mechanism, managing command dependencies and dependency resolution mechanisms.

Next up: Contribution workflow

The investments in package abstraction and the bootstrap process are a part of our larger effort to improve the contribution workflow.

Ultimately, we’d like to make contributing to the project:

  • Effortless. While understanding the WP-CLI codebase does require a certain technical knowledge, those who can contribute to the codebase should be able to do so with as little overhead as possible.
  • Enjoyable. Making improvements to WP-CLI should be fun and rewarding. For contributors, this means well-defined entry points, sufficient workflow documentation, clearly-articulated vision, roadmap, and decision-making process, and so on.

For new contributors, we now have a Good First Issues page:

For committers, we now have the beginnings of a customized dashboard:

Work on the contribution workflow is an on-going process. We’ve barely scratched the surface.

Expect to see lots efforts on some of the key areas that make up the contributor experience:

  • Articulation of the decision making process for transforming ideas into new commands. We need to identify how we can sustainably transform ideas into maintained packages.
  • Improving the onboarding of new committers through documentation, tools and processes. Read the Committers credo to better understand our expectations.

Join the conversation during our weekly office hours, Tuesday, April 25 at 16:00 UTC, or at WordCamp Europe.

New commands

Want to sanity check your wp-config.php? Use wp config get list constants and globals defined in wp-config.php [#9]

$ wp config get --fields=key,value
| key                | value           |
| table_prefix       | wp_             |

Don’t want to remember where wp-config.php is on your filesystem? Use wp config path to get the path to wp-config.php [#7]

# Edit wp-config.php in your editor.
$ vim $(wp config path)

Curious how much your database weighs? Run wp db size to get the size of the database and its tables [#16]

$ wp db size --tables
| Name                  | Size   |
| wp_users              | 64 KB  |
| wp_usermeta           | 48 KB  |
| wp_posts              | 4 MB   |
| wp_comments           | 2 MB   |
| wp_links              | 32 KB  |
| wp_options            | 1 MB   |
| wp_postmeta           | 8 MB   |
| wp_terms              | 416 KB |
| wp_term_taxonomy      | 336 KB |
| wp_term_relationships | 736 KB |
| wp_termmeta           | 48 KB  |
| wp_commentmeta        | 2 MB   |

Everything else in v1.2.0

Command improvements

  • wp core install:
    • Generates 18 character password for admin user [#4002].
  • wp cron event run:
    • Only runs specified events when $args are passed with --due-now [#11].
  • wp db *:
    • Uses /usr/bin/env mysql instead of mysql when calling MySQL executable [#14].
  • wp db (drop|reset):
    • Presents database name to confirmation prompts for wp db drop and wp db reset commands [#12].
  • wp db export:
    • Adds --exclude_tables=<tables> option when exporting a database [#20].
  • wp db import:
    • Speeds up import process by disabling auto-commit and (unique and foreign) key checks [#3829].
  • wp language core install:
    • Processes --activate flag even when language is already installed [#3851].
  • wp language core (install|uninstall)
    • Permits multiple languages to be installed or uninstalled at the same time [#4, #5].
  • wp media import:
    • Error handling is improved in a variety of ways [#3755].
  • wp media regenerate:
    • Deletes existing PDF preview images upon regeneration [#3824].
    • Fixes media regeneration when an image has a dimension smaller than a registered image size [#5].
    • Adds --image_size=<size> to regenerate a specific image size [#9].
  • wp menu location assign:
    • Increases verbosity and error reporting [#3852].
  • wp package *:
    • Fixes path returned from get_composer_json_path() under Windows [#11].
  • wp plugin install:
    • Disables renaming behavior when installing from GitHub raw ZIP URLs [#3823].
  • wp plugin update:
    • Introduces --minor and --patch flags for limiting updates based on semantic versioning [#13].
    • Displays correct error when plugin fails to update [#3803].
  • wp (plugin|theme) update:
    • Adds --exclude=<name> argument to exclude plugins or themes from updating [#16].
  • wp post term *:
    • Introduces --by=id argument to explicitly handle terms as ids [#3896].
    • Pluralizes messages based on term count [#3898].
  • wp rewrite *:
    • Warns user when managing rewrites with --skip-plugins or --skip-themes, because rewrites may be missing [#3917].
  • wp scaffold (child-theme|_s):
    • Includes a default .editorconfig based on WordPress coding standards [#3902].
  • wp scaffold plugin-tests
    • Variety of improvements to scaffolded .travis.yml and circle.yml [#3919].
    • Caches Composer in scaffolded .travis.yml [#3816].
    • Installs PHPUnit 4.8.* for PHP 5.*, and PHPUnit 5.7.* for everything else [#6].
    • Tests PHP 7 versions in scaffolded circle.yml [#16].
  • wp server:
    • Permits environment variables to define a specific PHP binary [#3868].
  • wp user create:
    • Generates 24 character password for new users [#7].
  • wp user import-csv:
    • Disables core’s email notifications when updating a user [#3904].

Framework enhancements

  • Symfony 3.x components can be used with WP-CLI. We didn’t even need to break backwards-compatibility [#4067].
  • New hooks:
    • before_add_command:<parent command> lets you check runtime requirements before adding a command
    • after_add_command:<parent command> lets you depend on a specific parent command before triggering a given functionality [#4033]
  • Automatic command dependency resolution. If a sub-command depends on a parent command not yet registered, the addition of this sub-command is deferred until the parent is available [#4094].
  • Spelling suggestions. If you mistype a command, WP-CLI will now be smart enough to make suggestions about what you probably wanted to type, and suggest these corrected spellings. This helps with discovery and error resolution. Suggestions are provided for commands, parameters and aliases [#4004, #4008, #4109]
  • Help documentation wordwraps to 80 characters by default. It wordwrapped previously, but inconsistently so it was often broken [#4105].
  • Variety of testing framework improvements:
    • Variables are replaced in subdirectory paths [#4085].
    • Forces RUN_DIR deletion, safely, to ensure Behat doesn’t hang on cleanup [#4112].
    • Terminates all launched background processes in a cross-platform compatible manner [#4074].
    • Only applies @require-wp tags when WP_VERSION isn’t ‘latest’ or ‘nightly’ to ensure full test suite is run in these contexts [#4055].

Contributors to this release (43 total): 1naveengiri, aaemnnosttv, afragen, balbuf, behzod, carl-alberto, CodeProKid, danielbachhuber, davgothic, diablodale, diggy, dnmvisser, fjarrett, flaskboy, geekoun, gitlost, hason, JayWood, jeremyfrady, ka7, kcarwilemiller, lichtscheu, mbovel, MiteshShah, miya0001, Nikschavan, ntwb, petenelson, rahul3883, raquelmsmith, Rarst, ryanshoover, schlessera, Sidsector9, SosyalAlkolik, ssnepenthe, Steveorevo, tfrommen, tillkruss, timdream, trepmal, wp-make-coffee, zacksheppard

Command dependencies revisited

As I already described in Managing command dependencies, we have added two hooks that allow developers to explicitly state what type of requirements need to be fulfilled before loading their custom command.

This works just fine when you know about these hooks and make proper use of them.

But there’s a large number of third-party commands out there already that are not yet making use of these new hooks, obviously. As we want to provide a safe update path, we had to look into providing a mechanism for the commands that might break due to the bootstrapping and package distribution changes.

Automatic dependency resolution to the rescue

As it turns out, having these hooks available makes it very easy to solve the dependency resolution in a fully automated way.

If a sub-command depends on a parent command that is already registered, or if a command does not have a dependency at all, we add the command immediately, just as before. This is the standard behavior.

If a sub-command depends on a parent command that is not yet registered, adding the sub-command immediately would just break. Imagine wanting to add a scaffold my-plugin sub-command, when the scaffold command has not yet been registered. In this case, we hook up the sub-command addition to the after_add_command:<parent command> hook, and add the command to the list of deferred command additions.

Once we add a deferred command when its hook has been triggered, we remove that command from the list of deferred command additions.

If we processed all commands, any remaining additions on the list of deferred command additions are executed as a final step. This is needed for sub-commands like network meta, where the parent does not actually exist (and thus, the after_add_command:<parent command> hook is never called).

Backward compatibility and ease of use

With the above mechanism, all current commands that relied on the fact that bundled commands were always loaded first will still work, even if the bundled commands might now be loaded later, due to the fact that all bundled commands have been split out into their own packages.

What’s more, any command depending on any other command will now just work, no matter what the loading order is, as long as both commands are loaded eventually.

X-posting Proposal: WordPress Community Conduct Project

Please read + comment on the original post.

Proposal: WordPress Community Conduct Project

New bootstrapping mechanism to load the WP-CLI framework

The upcoming 1.2.0 release of WP-CLI will include a refactored bootstrapping flow that provides a more flexible way of loading the framework itself and setting everything up. This refactoring is needed to allow for some of the expected functionality to work in conjunction with bundled commands being provided through external packages and the general use of autoloading (Issue #3850 | Pull Request #3872).

What does the term “bootstrapping” mean?

In general terms, bootstrapping code is code that is not part of the actual logic meant to solve the problem, but rather code that is needed to prepare the environment so that the actual logic is able to run.

This usually means locating files and folders, setting constants, reading configuration, etc…

What problem does this change solve?

The current stable release has all bundled commands be part of the wp-cli/wp-cli repository as a big monolithic package. This has several drawbacks, like having a huge testsuite be run for every single change to the framework (and waiting for 2 hours on feedback from the tests), and coupling the update frequency of these commands to the framework itself (making a quick hotfix to one single command difficult).

To get around these problems, we’ve extracted all of the commands into separate repositories that exist on their own, come with their own testsuites and have their own release cycles. To be able to profit from these decoupled release cycles, though, you need to be able to update a bundled command independently of the framework. This means that the act of loading the framework needs to be strictly separate to the act of loading the bundled commands.

The new bootstrapping mechanism separates the procedural list of load operations into a set of isolated steps for which the order can be freely defined.

General flow

After defining some constants to locate the needed files, WP-CLI will load the bootstrap component and call the WP_CLI\bootstrap() function (source).

This function defines a list of bootstrapping steps that will then be loaded and processed in the provided order (source).

The list of bootstrapping steps is a basic array of fully qualified class names (source). Each of the classes implements the WP_CLI\Bootstrap\BootstrapStep interface, meaning that it provides a process( BootstrapState $state ) method (source).

Bootstrap steps

When the process( BootstrapState $state ) method of a WP_CLI\Bootstrap\BootstrapStep object is being called, that object will execute its tasks to take care of its responsibilities and then return the (potentially modified) $state.

Each step works in isolation, so that they can be added/removed/rearranged as needed.

The current code does not allow for the list of steps to be modified from outside code yet, while we collect data and feedback about this new mechanism. However, if we feel confident about the reliability and usefulness, we might open up the array of steps for modification with a later release. If you feel you have a valid use case for such modifications to the bootstrapping process, please let us know!

Bootstrap state

The WP_CLI\Bootstrap\BootstrapState object that is being passed from one step to the next is a very basic key-value store. It currently only knows about one key, BootstrapState::IS_PROTECTED_COMMAND, which is used to skip certain steps when dealing with protected commands (source).

The only protected command right now is wp cli info (source). This protection means that loading of external command packages and --required files is skipped, so that the command can not be overridden. In this way, you can always be sure that the wp cli info command is indeed the one provided by the framework.

Split autoloader

The current implementation uses a custom Composer plugin to split the Composer autoloader provided by the wp-cli/wp-cli package into two separate autoloaders (source). This is needed to allow autoloaders from external command packages to take precedence over the bundled commands. Otherwise, you would not be able to update bundled commands through the built-in package manager.

This is only a workaround to get around the fact that the “WP-CLI Framework” would actually need to be a separate repository from the “bundled WP-CLI”. If the repositories themselves should be split at a later date, this custom Composer plugin will not be needed and removed again. So don’t rely on this plugin or the functionality it provides to be available.

Managing command dependencies

A combination of changes we are currently working on – putting all commands into external packages as well as making the WP-CLI bootstrapping process more flexible – made it obvious that we need to deal with command dependencies in one way or another. As an example, the scaffold package command depends on the scaffold command to be already registered. Both are provided through external packages, though. If they are loaded in the wrong order, adding the scaffold package command will not work as expected.

Therefore, the current nightly includes a new mechanism for dealing with these command dependencies. This is achieved through a pair of new hooks:

Before adding a command – check requirements


The main purpose of this hook is to allow you to check runtime requirements at the moment the command would be added.

The callback you provide will have a WP_CLI\Dispatcher\CommandAddition object be provided as the first argument. This object has a method abort( $reason ) that you can use to prevent the command from being added. The reason that you provide is not yet being used, but the plan is to display this reason in the help screen so that users have feedback about why certain commands are unavailable.

Usage example:

WP_CLI::add_hook( 'before_add_command:db', function ( $addition ) {
    if ( ! $this->database_is_available() ) {
            'The db command needs a working connection to the database.'
} );

After adding a command – load dependent commands


This hook is used to have one command depend on a different command being loaded first. The main use case is when you add a new sub-command to a parent command located in a different package. As you cannot simply depend on loading order, you can wrap the addition of this sub-command in the after_add_command:<command>  hook.

Usage example:

WP_CLI::add_hook( 'after_add_command:scaffold', function () {
    WP_CLI::add_command( 'scaffold package', 'WP_CLI\ScaffoldPackageCommand' );
} );

Future considerations

These two hooks allow commands to be built in a more robust way and open up new possibilities for the future.

One of the goals we currently discuss is to have the help screen display unavailable commands together with the reason why the command has been disabled. This provides valuable feedback to the user and might even point to the next action for resolving the issue.

Also, getting rid of some of the run-time errors that let WP-CLI fail without even showing a help screen can potentially be defused through these hooks as well. A simple requirements check before adding a command can then display a warning, and avoid adding the command that would throw an error.

Good first issues for new contributors

Want to submit your first pull request to WP-CLI? We’ve identified a few good first issues for new contributors to get their feet wet:

Read through the contributing guide for details on how to get started, or join us in the #cli channel with any questions you might have. Office hours are today, Tuesday, April 25 at 16:00 UTC

New co-maintainer, Alain — thanks 2017 sponsors

WP-CLI welcomes its second maintainer, thanks to the support of our 2017 sponsors.

New co-maintainer: Alain Schlesser

First, I’d like to formally welcome Alain Schlesser as WP-CLI’s newest co-maintainer. If you’ve been following the project over the last month, you may have noticed him diving deep into WP-CLI’s internals. We’re excited about the infrastructural improvements coming in the next release, and the new features they’ll enable.

Alain is new to the WordPress community, and brings years of experience developing for other platforms, from hobby game development to large enterprise projects in a government environment.

I’m wildly excited about the opportunity to join Daniel and work on WP-CLI. This project represents a special facet of the WordPress ecosystem and comes with a unique set of requirements and challenges. I can’t wait to explore the possibilities!
— Alain

With Alain joining the project as a co-maintainer, the WP-CLI project is restoring capacity to meet current demands (e.g. support), and ramping up on new feature development and evangelization. We’ve already improved the build time by 33%!

Come say hello to Alain at our new office hours every Tuesday. Office hours start tomorrow, Tuesday, April 4 at 16:00 UTC

Thanks 2017 sponsors

Maintaining an open source project requires a substantial, ongoing commitment of time and energy. WP-CLI is a dependable tool loved by thousands because it’s actively maintained, which is made possible by the generosity of its sponsors.

Premier Sponsors

Individual Sponsors

Aaron Jorbin, Anant Shrivastava, Andy Fragen, Austin Ginder, Barry van Someren, Ben Meredith, Ben Welch-Bolen, Bill Christensen, Birgit Pauli-Haack, Bjørn Johansen, Boone Gorges, Carl Hancock, Chuck Reynolds, Craig Martin, Daniel Hüsken, David Herrera, David McDonald, Doruk Fisek, Drew Linsalata, Dwayne McDaniel, Erik Joling, Full Name, Hidetaka Okamoto, Hugh McGuire, Ian Johnson, Jared Atchison, Jason Conroy, Javi, Javier Arnáez, Jeremiah J Terhark, Joel Gaeddert, John Speed, Jonathan Bossenger, Jonathan Daggerhart, Joost de Valk, Joshua Koenig, Kevin Cristiano, Knight Tan, Matt Gross, Matthew Lawrence, Mike Garrett, Miya0001, Ned Zimmerman, Nicholas Duncan, Nick Cernis, Patrick Garman, Per Søderlind, Pippin Williamson, Rachel Baker, Rahul Bansal, Ralf Hortt, required gmbh, Richard Aber, Rick Wiggins, Robert Mathews, Rocket Lift In., Ross Wintle, Ryan Sullivan, Sean Hayes, Simon Blackbourn, Steph Gray, Tadpole Collective, Tanner, Thiana Kitrilakis, Thorsten Ott, Vlad Olaru, WP Bullet, Yash Chandra

RFC: Usage analytics and WP-CLI v2.0.0

There are two issues in the backlog we’d love your input on:

  • Capture and report anonymized usage statistics (scheduled for v1.3.0) – In addition to the data points listed, what others might be worthwhile to capture? And, are there other aspects to the project we should consider?
  • WP-CLI 2.0.0 (scheduled for late 2017) – What breaking changes should we consider and why?

Feel free to weigh in as you see fit.


New support venue: support forum

Have a question about something related to WP-CLI? There are now two places you can go for general help:

  • Join the #cli channel in the Slack to chat with whomever might be available at the time. This option is best for quick questions.
  • Post a new thread in the support forum and tag it with ‘WP-CLI‘ so it’s seen by the community.

Want to help others with their use of WP-CLI? Click “Subscribe to this topic tag” to receive email notifications of new forum discussion:

GitHub issues are meant for tracking enhancements to and bugs of existing commands, not general support. Use the wp-cli/ideas repository to up vote existing ideas or share your own.

Planning for Community Summit 2017

In preparation for the 2017 WordPress Community Summit (“CS”) on June 13th-14th before WordCamp Europe in Paris, France we’ve been asked to provide the following (in summary):

  1. A list of topics for the CS
  2. A list of representatives to attend the CS
  3. One or two contributors who are willing to help with the organization of the CS

This post serves as a request for input for the above three areas. Note that these three requests are detailed further with some clarifying notes on Make/Summit.

Feel free to ping me privately in Slack if you prefer. I will send a summary of the responses with the Community Summit team on Wednesday, March 1st (as I’ll be offline on Thursday and Friday).