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

Two new commands: doctor and profile

Excited to experiment with a couple new WP-CLI commands? wp doctor and wp profile are now available for everyone to install.

wp doctor lets you diagnose problems within WordPress by running a series of checks for symptoms. It includes an API for defining your own diagnosis, as well as writing custom checks.

$ wp @daniel doctor check --all
Running checks  100% [============================================================================================] 0:02 / 0:09
| name                       | status  | message                                                            |
| core-verify-checksums      | success | WordPress verifies against its checksums.                          |
| file-eval                  | success | All 'php' files passed check for 'eval\(.*base64_decode\(.*'.      |
| autoload-options-size      | success | Autoloaded options size (16.25kb) is less than threshold (900kb).  |
| constant-savequeries-falsy | success | Constant 'SAVEQUERIES' is undefined.                               |
| constant-wp-debug-falsy    | success | Constant 'WP_DEBUG' is defined falsy.                              |
| core-update                | success | WordPress is at the latest version.                                |
| cron-count                 | success | Total number of cron jobs is within normal operating expectations. |
| cron-duplicates            | success | All cron job counts are within normal operating expectations.      |
| option-blog-public         | success | Site is public as expected.                                        |
| plugin-active-count        | success | Number of active plugins (2) is less than threshold (80).          |
| plugin-deactivated         | success | Less than 40 percent of plugins are deactivated.                   |
| plugin-update              | success | Plugins are up to date.                                            |
| theme-update               | warning | 1 theme has an update available.                                   |

wp profile quickly identifies what’s slow with WordPress, by giving you visibility into key I/O indicators.

$ wp @daniel profile stage --fields=stage,time,cache_ratio
| stage      | time    | cache_ratio |
| bootstrap  | 0.2643s | 80%         |
| main_query | 0.0186s | 85.71%      |
| template   | 0.0489s | 93.71%      |
| total (3)  | 0.3318s | 86.47%      |

Both packages are in early stages of development — feedback welcome!

Version 1.1.0 released

Happy release day!

Today, I’m excited to bring you WP-CLI v1.1.0, chock full of enhancements and bug fixes.

Want to get props in the next release? There are a few projects we’ll be working on:

And, in case you missed it: I’m looking for help maintaining WP-CLI (paid opportunity, commitment of 5-10 hours/week). Know someone who might fit? Email or ping ‘danielbachhuber’ on the WordPress Slack.

Everything in 1.1.0

Command improvements:

  • wp cache *:
    • Explicitly sets default cache group as ‘default’ to replicate WordPress’ behavior [#3714]
  • wp cache type:
    • Detects W3 Total Cache object cache [#3637]
  • wp (comment|post|user) list:
    • Magically parses CSV values for any argument with double underscore [#3726, #3744]
  • wp core config:
    • Introduces --force parameter for overwriting existing wp-config.php file [#3706]
  • wp core is-installed:
    • Prevents error notice from wp_guess_url() when core isn’t installed [#3711]
  • wp core language install:
    • Passes $wp_version through to translations_api() so that WordPress reports the correct language download file [#3748]
  • wp core update:
    • Supports --version=(nightly|trunk), which will download the latest nightly build [#3645]
  • wp core update-db:
    • Updates wpmu_upgrade_site option for all networks, not just current, to ensure the admin notice is dismissed [#3659]
  • wp db *:
    • Runs help at the same point as the command, to enable wp help db import to be run when WordPress has been downloaded, a wp-config.php has been created, but WordPress hasn’t yet been installed [#3780]
  • wp db cli:
    • Makes it possible to pass arguments through to the mysql executable [#3745]
  • wp db export:
    • Appends a random hash to generated SQL file to help mitigate database files from being accessible at predictable URLs [#3765]
  • wp media regenerate:
    • Support generating thumbnails for ‘application/pdf’ for WordPress 4.7+ [#3768]
  • wp plugin install:
    • Correctly installs ZIPs uploaded to the GitHub release page for a project [#3776]
    • Displays error message when a plugin cannot be installed due to write permissions [#3764]
  • wp scaffold plugin:
    • Ignores multisite.xml.dist in scaffolded .distignore [#3677]
  • wp scaffold plugin-tests:
    • Opts-in to container-based infrastructure on Travis [#3739]
    • Supports PHP 7.1 and PHPUnit 5.7 when scaffolding .travis.yml [#3758]
    • Updates GitLab template to run WPCS tests [#3772]
  • wp scaffold (plugin-tests|theme-tests):
    • Validates plugin/theme slug to prevent you from scaffolding tests into an unexpected directory [#3666]
  • wp scaffold _s:
    • Validates theme slug earlier to provide a more understandable error [#3724]
  • wp search-replace:
    • Supports passing regex modifiers [#3639]
    • Only skips replacement when array is a reference to an existing array [#3708, #3713]
  • wp server:
    • Sets the path global parameter as docroot [#3700]
  • wp site create:
    • Replicates core logic for creating $newdomain and $path to form proper path then global $base isn’t ‘/’ [#3688]
  • wp site option list:
    • Adds --site_id=<id> filter [#3769]
  • wp theme install:
    • Uses http cacher when automatically installing a parent theme [#3689]
  • wp theme mod get:
    • Introduces --field=<field> argument for fetching a particular field [#3644]

Framework enhancements:

  • Updates Composer-based dependencies to latest [#3638, #3676#3678, #3698, #3720, #3786]
  • Ensures passed positionals take precedent over defaults defined in wp-cli.yml [#3648]
  • WP_CLI::runcommand() correctly persists current process’ environment variables [#3683, #3730]
  • Removes backslashes from display of path when destination folder already exists [#3691]
  • Globalizes wp-config.php variables to local scope too, enabling WordPress to properly change $table_prefix in multisite [#3695]
  • Adds global parameters to bash completion [#3697]
  • Permits dots to be used in aliases [#3705]
  • Introduce a Behat step for replacing a string in a file [#3712]

Contributors to this release (pull requests, documentation, and package authors): amqbgeihsgt, danielbachhuberedpittol, ernilambargreatislanderinderpreet99, louisremilwhmetodiew, migueldemoura, miya0001mmcev106, nikschavan, ntwbnylenocean90ramoonusrosswintleszepeviktortrepmalwestonruter

You can browse the full list of resolved issues on Github.

New home for WP-CLI docs

WP-CLI’s long-form documentation has a new shiny home:

2017-01-26 at 3.47 PM

Want to suggest an edit?

Click on the “Edit” next to the title to submit your changes via pull request workflow. The documents are tracked in a GitHub repo for easy collaboration. Just like with code changes, documentation contributors receive credit in every WP-CLI release.

Have five minutes to make the documentation better?

Read through the handbook and open an issue with ideas on how we can improve or expand upon our documentation.

Happy scripting!

What do you wish you had a WP-CLI command for?

At the heart of it, WP-CLI commands enable you to do anything you want with WordPress, faster. Performing some task at the command line almost always yields some (often huge) amount of efficiency gain over the alternative.

For instance, consider the following (from #2523):

Using the theme list command without url parameter shows if a theme is enabled for the network and active in the default site.

If you pass the url of a site of the network, this command shows if a theme is active in that site.

But i can’t find a way to list which themes are inactive in every site of the network so i can safely disable and delete them, and i’d love to have this feature

Without WP-CLI, you’d need to:

  1. Find an intern.
  2. Prepare a spreadsheet of all sites and themes.
  3. Have the intern go through each site to log the active theme on your spreadsheet.
  4. Evaluate the spreadsheet to determine with themes can safely be deleted.

With WP-CLI, you can simply run wp find-unused-themes. Pretty much infinity time savings.

So, what do you wish you had a WP-CLI command for?

Now you have a place to request them. Head over to the new wp-cli/ideas GitHub repo and file issues to your heart’s content.

There’s no such thing as a bad idea. We’ll implement the best, and maintain them as canonical WP-CLI community packages.

But wait, how will you pick which ideas to build?

That’s a great question — I’d love your input on how to decide.

The end goal for the WP-CLI package index is to be a directory of well-maintained, canonical features. Packages will be considered community projects shepherded by one or more maintainers, instead of the domain of a specific author. There’s a two-fold benefit in taking this approach:

  • You (as a WP-CLI package author) will feel less burdened in maintaining your package, because you have supporting resources to help you out.
  • You (as a WP-CLI user) will have greater confidence in using the packages in the package index because you know there’s a small community of maintainers around each of them.

But, we need to work out how we get from 0 to 1 (idea to initial implementation), and then 1 to n (ongoing development and maintenance).

But wait, who’s “we”?

That’s a great question too.

I’m now actively looking for someone to help me run with this vision. They’ll focus on facilitating great community packages: soliciting and vetting ideas, establishing best practices and standards, and supporting package maintainers. The best candidate sweats the little details, and commitment is already a part of their track record.

In the near future, we’ll be looking for people to maintain packages in the directory. Our goal is for maintainership to be a rewarding, enjoyable experience — and for maintainers to extend the same to contributors.

Know anyone who might fit either of these roles? I’d love to hear from you. Email or ping ‘danielbachhuber’ on the WordPress Slack.

Let’s do this!

As announced last week, WP-CLI is now an official project. I consider this the best possible outcome of my efforts trying to identify sustainability for the project over the last year. Frankly, it’s hard to communicate how relieved I am.

But wait, what does that actually mean?

Most of the details are still to be worked out. On a high-level, these are the big changes:

  • The website will be migrated to some part of, shape and form TBD.
  • Development will continue on Github, and could possibly move to (see below).
  • At the end of the day, I am no longer solely responsible for the project. If I were to be hit by a bus, there’s a more recognizable continuation plan for someone else to step in. Eventually, I hope to onboard a couple more maintainers who regularly invest significant time in the project.

The decision to make WP-CLI an official WordPress project also means there’s a clear path forward for me to invest more of my own time into the WP-CLI roadmap. Concurrent with the transition process over the next couple of months, I want to move forward the conversation of how we realize a future where WP-CLI is the fastest way to do anything with WordPress. If that’s something you’re interested in, stay tuned!

Migrating the website

In order to successfully and completely migrate the website to (and WordPress), it’s important to understand its current form:

  • is a Jekyll-based website hosted on Github / Github Pages.
  • Much of the reference documentation is generated by a series of WP-CLI commands from the WP-CLI codebase. These commands take structured data about the codebase and transform it into a series of Markdown files served by Jekyll. This documentation is typically regenerated for every major release.
  • The rest of the documentation is a series of user-editable files. It would be nice to be able to replicate the pull request workflow for editing the docs, because it’s a good source of contributions.
  • The WP-CLI package index ( is built from a separate Github repository. It uses Satis to build the HTML and JSON representations of the package index. Satis is running on one of my personal servers.

These are the core functions needing to be replicated on Ideally, the work done would be the foundation of where I’d love to see the WP-CLI website go in the future:

  • Produce command pages for the packages listed in the package index.
  • Proxy Github API requests for new WP-CLI versions (from 3426).
  • Display download / installation counts for each package.
  • Display number of Github stars for each package.
  • Highlight packages in the index that are regularly updated, have multiple maintainers, or reflect some other quality we hold to be important.
  • Create distribution releases for packages in the package index to speed up installation (from 2566).
  • Run test suite for each package on a weekly basis (from 3197).
  • Validate packages submitted to the package index (from 3177).

Migrating the Github repo

Fortunately, Github makes it easy to transfer repositories between organizations. Before we make the switch, we need to dot the i’s and cross the t’s on these core functions:

  • Travis is used to run the test suite. Travis also commits a build artifact to the builds repo.
  • WP-CLI’s update check uses the Github releases API. If Github doesn’t transform the request URI for migrated repos, then users will experience a cryptic error. Now that I write this, this dependency might be a large-ish problem.
  • Similarly, some users have build systems dependent on a consistent URL pattern for the release Phar file. See the releases page for examples.

It’s also worth noting there will be more WP-CLI repositories in the future. Each new feature will be developed as an independent package. In fact, existing features (e.g. search-replace) are going to be split out into separate packages too. We’ll need an organizational structure that can accommodate this growth (let it be or

Anything I’ve missed? Have a question about something I didn’t cover? Hit me up with a comment!

cc @pento

Hello world!

Supporting the Future of wp-cli

How much is WP-CLI worth to you?

Update 3 12/28: WP-CLI is now an official WordPress project. Fundraising will continue into 2017.

Update 2 12/15: Undecided on how much WP-CLI is worth to you? The experiment ends Dec 28th — please make a decision by then 🙂

Update 1 (12/13): Up to 17 subscribers so far. If we can get to 50, I’ll launch a members-only forum.

Last week, I tweeted:

At a decision point with @wpcli: it’s too large for me to voluntarily maintain. Have an opinion on its future? I’d love to chat.

Last February, I started a business, runcommand, as an indirect way of being able to invest my time into WP-CLI. The business is doing alright, not great but not horrible. What I’ve come to realize, though, is that my time is zero-sum. I’m incentivized to spend time on runcommand, when I’d rather spend it on WP-CLI.

Ultimately, the challenge I’m running into is opportunity cost. I’d love to be able to invest more into WP-CLI, but doing so comes at the cost of other business pursuits. Because WP-CLI is such a large project, the several hours I volunteer each week are basically enough to fight entropy — not make headway on larger initiatives.

The response to my tweet has been overwhelmingly supportive. One future I’m considering is directly commercializing WP-CLI, through patreon-esque membership, advertising on the website, and other ideas to be determined.

So, dear reader, a question: how much is WP-CLI worth to you?

Or, phrased another way, how much time does WP-CLI save you?

If the experiment goes well, then we’re in business! Your purchase will support ongoing maintenance of WP-CLI, as well as development of new commands like wp doctor and wp profile, improvements to the website and package index, and so on.

If the experiment doesn’t go well, then at least I can say I tried 🙂 To avoid any risk with the investment above, a full refund will be made available to you should the campaign not reach its goal, before we look at other approaches to help with maintaining the project.

Happy to take any questions you might have: I’ll keep the list below updated as new questions come in.

Have you tried crowdfunding?

Yep! See the post I wrote, “Using Kickstarter to fund open source“. Nadia Eghbal has a series of great articles on open source sustainability as well.

How much money do you want to see to consider this a success?

I have a number, but I’m not going to share it. I want to see if this is a viable approach for funding a for-profit business.

What if I want to pay a different amount?

Email me, and I’ll create a purchase link for you.

Do I get anything special for paying the amount I paid?

Potentially, but nothing to announce at this point.

I do have some ideas in mind for offerings at different levels (e.g. members-only support forum, feature prioritization, etc.).

Do I need to keep paying after I pay the first time?

Well, if everyone cancels, then the business will tank 🙂

All levels are billed annually unless you disable automatic renewal.

What if I’m an existing runcommand customer?

If the experiment goes well, then wp doctor and wp profile will become completely open source. I’ll reach out about the other aspects of your purchase.

What about scribu and Andreas?

I’ve been talking with them a bit. We’re all very interested to see how this plays out.

Version 1.0.0 released


Over the course of 5+ years, hundreds of contributors have worked to bring you WP-CLI v1.0.0, which I’m proud to announce today.

This release represents a level of maturity few open source projects achieve. It also marks a moment of transition. The WP-CLI project will shift its focus to the WP-CLI package ecosystem, where it will enable innovation by building and encouraging new features as standalone packages. We hope this approach will promote faster iteration and more creativity, and more sustainably distribute the maintenance burden. As these community packages find success, we’ll bring their learnings back into WP-CLI, alongside bug fixes and minor enhancements.

Now that the issue backlog is down to zero, I’m personally looking forward to getting more ideas cooking for runcommand, my own WP-CLI innovation studio.

Headed to Philly this week? I’ll be at Post Status Publish and WCUS (although only until mid-afternoon Friday). Say hello – I’m @danielbachhuber on Twitter.

On with the show…

Introducing WP_CLI::runcommand()

WP_CLI::runcommand() (doc) is the new best way to run WP-CLI commands from within your WP-CLI command. It’s as though WP_CLI::run_command() and WP_CLI::launch_self() grew up, married, and had the perfect child.

With WP_CLI::runcommand(), you can:

  • Launch a new child process (default), or reuse the existing process.
  • Optionally prevent the process from exiting on error.
  • Return STDOUT generated by the command, or all command execution details (STDOUT, STDERR, return_code) as an object.
  • Optionally parse captured STDOUT as JSON.

Relevant pull requests include: #3605, #3619, #3621.

Breaking change: Uses return code 1 when batch operation partially fails

Some commands support performing the same operation against multiple resources (e.g. updating two or more plugins with wp plugin update akismet hello). Previously, if one of the operations failed (e.g. a plugin update failed to be downloaded), WP-CLI would display a warning, continue on, and exit with return code 0. Beginning in v1.0.0, WP-CLI uses return code 1 when one or more operations fails.

See this issue for more background and rationale.

Affected commands include:

  • wp media (regenerate|import)
  • wp menu delete
  • wp menu item delete
  • wp plugin (install|activate|update|toggle|deactivate|uninstall|delete)
  • wp super-admin add
  • wp theme (install|update)
  • wp term delete
  • wp widget (delete|deactivate|reset)

Use WP_CLIUtilsreport_batch_operation_results() (doc) in your custom WP-CLI commands to more easily support this behavior.

Relevant pull requests include: #3584, #3583, #3582, #3585, #3586, #3588.

Everything else in 1.0.0

New commands:

  • wp package update – Update all installed WP-CLI packages to their latest version.
  • wp scaffold theme-tests – Scaffold PHPUnit tests for themes.

Command improvements:

  • wp cache type:
    • Supports WP LCache as a cache type [#3504].
  • wp cli aliases:
    • Adds alias to subcommand for easier access [#3512].
  • wp cli update:
    • Verifies release hash when updating [#3515].
    • No longer requires --allow--root flag when running as root [#3576].
  • wp core config:
    • Ensures WordPress Coding Standards are applied to the generated wp-config [#3496].
  • wp core (install|multisite-install)
    • Defaults to a randomly generated password for --admin_password=<password>, which is now optional [#3535, #3573].
  • wp core language (install|update):
    • Caches language pack downloads [#3595].
  • wp core update:
    • Uses global namespace for WP_Error in CoreUpgrader class [#3593].
  • wp core update-db:
    • Sets the WP_INSTALLING constant for the update process [#3503].
  • wp package install:
    • Uses supplied version in package composer.json, instead of “dev-master” [#3519].
    • Adds WP-CLI version to package manager’s composer.json, to gracefully handle WP-CLI version constraints [#3603].
  • wp package list:
    • Indicates when a package has an update available [#3611, #3612].
  • wp post delete:
    • Correctly indicates revisions are deleted immediately in success message [#3524].
  • wp scaffold plugin:
    • Ignores distribution archive files in .gitignore and .distignore [#3520].
    • Ignores circle.yml, .gitlab-ci.yml and behat.yml in .distignore [#3599].
  • wp scaffold plugin-tests:
    • Checks out the data directory in to prevent notices in WP 4.7 [#3571].

Framework enhancements:

  • Updates Composer-based dependencies to latest [#3498, #3525].
  • Introduces --prompt=<assoc> to prompt for specific associative args, which lets users avoid exposing secure data in bash history [#3531].
  • Adds support for the version of PHP that comes with Cygwin [#3591].

Contributors to this release (pull requests, documentation, and package authors): abea, anttiviljami, cobyan, danielbachhuber, diggy, ernilambar, franz-josef-kaiser, greatislander, itspriddle, miya0001, mmcev106, mopquill, ocean90, pj-dave, pkarjala, richardbuff, sommarnatt, szepeviktor, torounit

You can browse the full list of resolved issues on Github.

Version 0.25.0 released

Happy release day!

Today, I’m excited to bring you WP-CLI v0.25.0. Check out the newly published roadmap for details on upcoming releases and product focus (hint: there’s a future where WP-CLI no longer supports PHP 5.3).

Let’s dive in.

Compatibility with WordPress 4.7

WordPress 4.7 introduces a new WP_Hook implementation for registering and executing actions and filters. Because WP-CLI has its own WP_CLI::add_wp_hook() that was erroneously accessing the $wp_filter global even when the add_filter() function was available, WP-CLI could fatal in certain circumstances. WP-CLI now appropriately calls add_filter() when it’s available.

Importantly, due to the nature of these changes, WP-CLI versions prior to 0.25.0 will be incompatible with WordPress 4.7.

Inspect the change in this pull request.

New packages in the Package Index

The WP-CLI community has been quite active in creating new tools for you to use (and contribute back to):

Install any one of these with wp package install <package-name> (where <package-name> is typically the <user>/<repo>). When you do, go say thanks to the author!

More ways to install WP-CLI packages

Although we’d love to see your package listed in the Package Index, we realize there are reasons you might not be able to do so. wp package install now supports installing an arbitrary Git URL [#3482], .zip file [#3485], or directory path [#3484] as a package.

$ wp package install
$ wp package install
$ wp package install doctor

(doctor is the second premium WP-CLI command from runcommand)

It’s worth noting Composer’s behavior is slightly different for each package type:

  • Git URLs are treated as VCS repositories, and cloned to ~/.wp-cli/packages/vendor.
  • ZIP archives (remote and local) are extracted to ~/.wp-cli/packages/local, and added as path repositories.
  • Local directory paths are added as path repositories, which means Composer creates a symlink to the existing directory path. If the directory you’ve provided is removed, then the installation will break.

Everything else in 0.25.0

New commands:

  • wp db check – Runs mysqlcheck with the default --check option [#3332].
  • wp site option * – CRUD commands for managing WordPress site options [#3386].
  • wp user session * – CRUD commands for managing user sessions [#3307].

Command improvements:

  • wp cli update:
    • Introduces --stable to install or reinstall the latest stable version [#3430].
  • wp core config:
    • Adds comments to generated wp-config.php to better match the one provided by WordPress core [#3312].
  • wp core download:
    • Preserves case for --version argument to properly handle release candidates [#3283].
    • Ensures wp core download --version=latest produces correctly-versioned cache key [#3467].
  • wp core language update:
    • Fixes strict standard error about variable reference [#3380].
    • Permits updating language packs even when en_US is set as locale [#3397].
  • wp core multisite-(install|convert):
    • Warns when multisite constants can’t be inserted into wp-config.php, instead of erroneously inserting at the end [#3272].
    • Includes adequate vertical spacing around inserted constants [#3267].
  • wp core update-db:
    • Ensures wp core update-db --network --dry-run is actually dry [#3347].
  • wp core version:
    • Displays default core language in wp core version --extra [#3221].
  • wp import:
    • Indicates current file in WXR import progress indicator to communicate the total count is of the current file, not all files [#3270].
  • wp media regenerate:
    • Adds a simple progress indicator [#3407].
  • wp option list:
    • Adds --no-transients flag to ignore transients [#3452].
    • Adds --exclude=<exclude> argument to list options excluding a specific pattern [#3455].
  • wp package install
    • Displays package dependency details when installing a package with a dependency [#3418, #3425].
  • wp package uninstall
    • Removes a package’s dependencies when the package is removed [#3343].
    • Properly assigns $composer_backup when uninstalling [#3399].
  • wp plugin install:
    • Removes branch names from directories created for Github-based ZIPs [#3314, #3451].
  • wp scaffold plugin-tests:
    • Uses PHP version specific to Trusty on CircleCI [#3359].
    • Uses correct default user for MySQL on CircleCI [#3457].
    • Uses the latest version of PHPUnit on Travis, depending on PHP version [#3463].
    • Adds WordPress Coding Standards to newly-scaffolded plugins [#3472].
  • wp search-replace:
    • Ensures tables are quoted to support all permitted characters [#3318].
    • Prevents error notice when export_insert_size isn’t defined [#3357].
    • Fails back to PHP if SQL triggers an error for some reason [#3387].
  • wp server:
    • Supports passing a custom .ini file to configure the server [#3330].
  • wp site create:
    • Use get_blog_details() for the site URL when creating a new site to ensure the correct URL is displayed [#3416].
  • wp site empty:
    • Ensures the entire uploads directory is empty [#3400].
  • wp theme install:
    • Correctly installs parent theme when installing a child theme [#3301].
  • wp transient:
    • Consolidates wp transient delete-all and wp transient delete-expired to flags of wp transient delete [#3389].
  • wp user create:
    • Prevents email notifications when users are created because email notifications should only be sent when --send-email is provided [#3331].

Framework enhancements:

  • Updates Composer-based dependencies to latest [#3257, #3429, #3460, #3468].
  • Properly handles registering an instantiated object as a command [#3269].
  • Splits the ProcessRun class out to its own file [#3377, #3422].
  • Permits running test suite with WP_VERSION env variable [#3383, #3392].
  • Prevents error notice when using Utilsget_named_sem_ver() with WP versions [#3404].
  • Fixes fatal error for failed early database connection by handling dead_db() error on nocache_headers filter [#3440].
  • Assigns a default $_SERVER['SERVER_NAME'] to prevent uncaught exception when wp_mail() is used [#3449].
  • Ignores url: in wp-cli.yml when alias is used, because aliases completely override user, url, path, ssh, and http [#3450].
  • Warns when WP_CLI::launch() ends up with return_code=-1, which could be caused by a custom compiled version of PHP that uses the --enable-sigchild option [#3458].
  • Provides more verbosity in wp_die() handler to give the end user more detail when a database connection fails [#3459].
  • Supports passing arguments to WP_CLI::do_hook() [#3470].
  • Logs the current alias when executing an alias group [#3471].
  • Only checks options for a positional argument when a value is present [#3481].
  • Variety of bash completion improvements [#3490, #3491, #3492].

Bug fixes across the board:

  • Defines all requisite dependencies for PHP 7 on Debian-based systems [#3208].
  • Ensures site --site_id= -> site --network_id= backwards compat shim only affects wp site create [#3227].
  • Catches exceptions thrown by RecursiveDirectoryIterator when verifying core checksums [#3266].
  • Passes slashed data in meta commands [#3274].
  • Ensures appropriate WP-CLI package index URL is used in the composer.json [#3276].
  • Corrects reference of WP_CLI to use global namespace in WP_CLIUtilsget_temp_dir() [#3369].

Contributors to this release (pull requests, documentation, and package authors): 2ndkauboy, aaemnnosttv, alessandrotesoro, anhskohbo, balbuf, BeAPI, binarygary, bradp, brightoak, danielbachhuber, danilomaccioni, diggy, getshifter, eriktorsner, ernilambar, fisele, grappler, guillaumemolter, iandunn, johnbillion, jorgeatorres, kouratoras, markri, mattgrshaw, miya0001, mustafauysal, nyordanov, ocean90, petenelson, polevaultweb, pressbooks, rahulsprajapati, runcommand, rxnlabs, shulard, swissspidy, szepeviktor, taianunes, tnorthcutt, trendwerk, trepmal, veganista, welaika

You can browse the full list of resolved issues on Github.