The WP-CLI v2.1.0 release was originally scheduled for November 6th, 2018. However, due to the current timeline of the WordPress 5.0 release and the additional pressure it puts on all parties involved (WP-CLI contributors & testers included), I decided to postpone the release.

The new planned release date will be Tuesday, December 18th, 2018. This will keep it away from the planned release date(s) of WordPress 5.0 and place it shortly after the contributor day at WordCamp US, allowing us to get bug fixes & improvements done that day into the release as well.

For people who are waiting on getting their hands on the v2.1.0 release because of bugs in v2.0.1 that will be fixed, please note that you can always upgrade to the latest nightly release with the command wp cli update --nightly and switch back to stable releases later on with wp cli update --stable.

A bugfix release was in order, as the new i18n make-pot command was not properly packaged in v2.0.0!

For this release, 9 contributors have produced 19 pull requests and squashed 12 bugs.

Breaking change

The only thing of note as a (potential) breaking change is “Throw error in theme fetcher on non-lowercase slugs” [#126]. It should turn scenarios that produce a success message and actually failed into error messages instead. However, given the many possible combinations of encodings and filesystem quirks, what should have failed might previously actually have worked out of sheer coincidence instead. This will now throw an error message nevertheless.

“Framework” & “Bundle” are now two separate packages

This is the main change we planned to include with version 2 of WP-CLI. From v2 onwards, the “framework” is a separate package from the “bundle” that is used to build the Phar file you can download. The framework is now contained within the wp-cli/wp-cli package, while the bundling has moved on to the wp-cli/wp-cli-bundle.

Agreed, this does not sound like such a big deal, but in terms of development experience and maintenance effort, it is a tremendous improvement, making almost every future change faster and simpler.

What does that mean for users working with the Phar version of WP-CLI ?

Nothing much, really. Apart from some of the debugging information containing different paths, you won’t see much of a difference. One of the goals was to not disrupt current usage more than necessary. If you only ever download the WP-CLI Phar and use that to control your sites, you should not need to care about this change.

What does this mean for site owners using WP-CLI through Composer ?

They will rejoice! The framework itself has gotten rid of most of its problematic dependencies. If you compare the dependencies of v1.5.1 with those of v2.0.0, you’ll see that the list is drastically shorter. Also, the most problematic set of the dependencies, the hard requirement on an old version of Symfony, is gone. The only Symfony component we still have (yet) is symfony/finder, as there’s no upper version limit for that one.

Most of the more problematic dependencies actually came from the WP-CLI package manager (wp-cli/package-command). That command is not only optional now, there’s also no valid reason to use it at all when pulling WP-CLI in via Composer directly.

This also means that you will not see WP-CLI automatically pull in all bundled commands automatically. Let’s say, you need the wp-cli/db-command for some maintenance tasks for your site. With v1.5.1, this would have pulled in the entire WP-CLI bundle as a dependency. With v2.0.0, it will only pull in the lean framework as a dependency, nothing more. You’ll end up with a WP-CLI active on your site that contains the commands cli, help (as the two “built-ins”) and db.

As a nice side-benefit, this makes WP-CLI run much faster in such scenarios, as it only loads what is effectively needed for the site. The difference might not seem like much, but depending on how you use in in your scripts, it can make a big difference.

What does this mean for developers working on third-party WP-CLI commands?

Splitting everything up has provided a few additional perks for developers (see also the next section about the testing improvements). Everything is leaner, and the dependency resolutions are less problematic, as we got rid of that one nasty circular dependency (command requires framework => framework equals bundle => bundle requires command).

However, dependency declarations need to be more explicit now. If you require wp-cli/wp-cli, this will only provide the pure framework. You cannot implicitly rely on any of the bundled commands in that case, you’ll have to explicitly require any additional command you might need.

Testing framework is now a separate package

One of the things that bothered me a lot while maintaining WP-CLI was the fact that the testing infrastructure was “scaffolded” into the individual command packages (just as it is into the third-party commands). This basically means that we copy-pasted the code in there, and if the code needs to change (because of a bug being fixed or an improvement being made), we have to create changes in every single package to overwrite the copy-pasted version of the testing code with an updated one.

Now we have the testing infrastructure abstracted away into a separate package: wp-cli/wp-cli-tests. For this first iteration, it includes out-of-the-box support for PHP linting, PHP Code Sniffer checks (including the WordPress Coding Standards and the PHP Compatibility Checks), PHPUnit unit tests and Behat functional tests. They are set up in such a way that they detect whether they should run, based on config files or test files presence.

A simple composer test will run all of the tests in order. But you can also run them individually, through composer lint|phpcs|phpunit|behat. Adding further configuration flags can be done as well, but you need to remember to prepend them with a double-dash ( --) first, otherwise the arguments will be interpreted by Composer itself.

For the most important tests, the functional Behat tests, you can also define some constants to adapt the environment in which to test. For example, testing against a specific version of WordPress can be done by providing the WP_VERSION constant: WP_VERSION=4.2 composer behat. This constant also understands latest and trunk correctly.

In general, the tests are set up in such a way that you’ll face less differences between what you get locally and what you’ll get inside of the Travis CI checks.

New command: i18n make-pot

@swissspidy has spent countless hours working on a new command that has now finally made it into the official WP-CLI bundle. We now introduce you to the i18n command family and its first usable subcommand, i18n make-pot.

This can now easily be including in whatever automated tooling you use for your site/plugin/theme development, and should make your translation work much smoother. Here’s a quick rundown of the main features:

Automatically detects plugins and themes and extracts file headers.

Allows extraction of only a specific text domain.

Supports JavaScript string extraction, even for JSX and ESNext.

Allows merging the resulting POT file with an existing one, e.g. one created by Babel.

Can warn about strings with wrong placeholders, as well as misleading or missing translator comments. This could be very useful for core but also plugin/developers to improve polyglots UX.

A big shoutout to @swissspidy for the fabulous work he did on that command!

Minor Framework enhancements

New WordPress action: 'cli_init'

We introduced a new action 'cli_init' that will be triggered by WP-CLI during the 'plugins_loaded' action. This can be used as a conditional trigger for loading WP_CLI specific code, in case you don’t want to use the constants we already provide, for whatever reason.

This being a WordPress action, it adds a bit more flexibility to the process of loading a WP-CLI command, like for example one plugin being able to unhook the commands of another plugin.

New command: config edit

Easily open your wp-config.php in your favorite editor (configured through the EDITOR environment variable). Once you save within that editor, the wp-config.php will be correctly updated.

Note: This works through SSH/vagrant/docker tunnels as well, but keep in mind that it will use the EDITOR of the remote system, which should be something like vim (=> “how to exit the vim editor” 😉).

New command: config shuffle-salts

This refreshes the salts stored in your wp-config.php file, which are cryptographic values used for authentication and other security-related functionality. Regulary refreshing these salts could be considered “security hygiene” for a site.

The command will generate the salts locally if your PHP server environment is cryptographically secure enough to do so, and falls back to the remote wordpress.org API endpoint if not.

New command: db columns

Get a tabular view of the table schema for a given table. It shows you how the individual columns of the table have been defined, which default values they use and what extra functionality might be attached to them.

New command: site meta

Oh, and while you are wondering… Yes, you are right, WordPress does not have “site meta” entities. But we didn’t lose our minds: WordPress will introduce “site meta”, together with a wp_site_meta table, with its 5.0 version. We just like to be prepared, that’s all… 😜

New command: user check-password

You can now let WordPress tell you whether a given password is valid for a specific user. This is NOT an endorsement to build your authentication layer with Bash scripts! But who knows what exotic automation needs the DevOps folks will come up with…

The command will let you know through a shell exit code whether the password was valid or not, so you can use it directly in if conditionals.

Both plugin uninstall and plugin delete can now act on --all plugins at once

cap list can now --show-grant

cap add , seeing what its list sibling had done, grew a new --grant flag

role list can now print a single --field=<field>

scaffold _s learned the new --woocommerce trick

search-replace lets you set a --regex-limit

Automated README.md updates

If you have ever contributed to WP-CLI and made a change to a command signature or documentation, you probably had me tell you that you needed to regenerate the README.md as well using the wp scaffold package-readme . --force command. No more!

We have now added a package wp-cli/regenerate-readme that automates this process. It adds both a precommit and a postcommit git hook that collaborate to transparently regenerate the README.md file behind the scenes and then amend your commit to add the required changes automatically.

This has not been deployed to all command packages yet while we still experiment with some of the finer points of its implementation, but you’ll slowly see the annoying “please regenerate README.md kthxbye” reminders from my side disappear and become forgotten artifacts of the past.

Improved debug output

The debug output was always a bit sparse for WP-CLI. This is why we took the opportunity of v2 to improve upon it and make it more useful. It will now add debug messages for the hooks that are triggered, or details about how commands are being loaded or deferred. This will be very useful for third-party command developers that ignore why their command is not properly registered.

We’ll make sure to add even more useful debugging information in the future.

Small side note: To make debugging work as early as possible, it is now smart enough to just store all messages until the logger it needs to send them to becomes available. This means you don’t need to worry about the timing here, if the WP_CLI exits for your code, the debugger is good to go!

Breaking changes

Here are a few things you need to be aware of when moving from ^v1 to ^v2:

An obvious breaking change is the bump to the minimum version of PHP. This will break for anyone trying to run WP-CLI on PHP 5.3.

The separation of the “framework” and the “bundle” into two separate packages will cause a breaking change if a third-party command is being pulled-in via Composer AND that third-party command relies on running bundled commands as well. This will seldom be the case and will be an easy fix. Installations using the Phar will not be impacted.

As many dependencies could be removed from the framework by not including the package manager automatically, any third-party command that relies on one of the removed Symfony packages or other dependencies AND hasn’t declared that requirement in its own Composer configuration will break. This will seldom be the case and will be an easy fix. Installations using the Phar will not be impacted as the package manager still comes with these requirements included.

The versions of some the dependencies will be bumped. If you happen to not lock WP-CLI into a specific version constraint, but do so for some of its dependencies, you might see a version constraint conflict when using Composer.

Any external code that relies on internal file structure, file naming or other internal details that are not part of the provided API could run the risk of breaking due to us moving things around from v1 to v2. This should hopefully not ever be the case, but you never know…

As a side-effect of adding the --all flag to plugin uninstall, a breaking change was introduced for consistency reasons. Whereas WP-CLI used to consider uninstalling a non-existent plugin as a “Success: Plugin already uninstalled”, it will now throw an error “Error: No plugin uninstalled”.

We did our best to avoid unnecessary breaking changes. But with a big structural change like we have here, the devil’s in the details. Let us know if you hit any other issues!

The upcoming WP-CLI release v2.0.0 that was originally due to be released on July 31st is being re-scheduled for Wednesday, August 8th.

This delay is due to the fact that it was much more work to disentangle the feature tests to split them up for the restructuring. I want to avoid hurrying the release, so I prefer to add some more time to let the dust settle and run further tests.

The main reason why most of these were not merged during the event was that we had trouble with our automated tests. One problem was that many tests that depended on the WordPress.org infrastructure to download Core files, plugins or themes had frequent timeouts. This seems to be caused by a recent move of the entire infrastructure, which made access to the content over CDN very spotty. Another problem was that Travis CI was acting up and was often stuck in “pending” state for prolonged time periods.

During the last two hours of the event, we did a video chat over Zoom with all participants that wanted to join. We peaked at 13 participants to that video chat. It allowed for people to make a more personal connection, which added another dimension to the act of contributing.

We had an ambitious goal of merging 20 pull requests during the event. While we were not able to achieve that number of merged pull requests, I’d consider the event a complete success nevertheless, considering the amount of pull requests that were just waiting to get through the blocking tests to get merged.

The event was also an experiment, to see whether a more direct, interactive form of contribution would attract more contributors. I think it did succeed in doing so, and I think it was a positive experience for the participants.

👉 I would love for people to provide feedback about the event in the comments below. 👈

I’d like to evaluate how well this type of contribution event was received and this will then shape a possible next iteration, where we’ll hopefully get even Travis & Co. to collaborate.

All of the small changes and bugfixes that we have been collecting since the v1.5.0 release, as most of this was skipped for v1.5.1 to keep that release “bug-fix-only”.

Anything we might get production-ready during the upcoming WP-CLI Hack Day!

With the above restructuring, you should expect some breaking changes, most notably:

#4554 will cause a breaking change for anyone trying to run WP-CLI on PHP 5.3.

#4748 will cause a breaking change if a third-party command is being pulled-in via Composer AND that third-party command relies on running bundled commands as well. This will seldom be the case and will be an easy fix. Installations using the Phar will not be impacted.

#4749 will cause a breaking change if a third-party command relies on one of the removed Symfony packages AND hasn’t declared that requirement in its own Composer configuration. This will seldom be the case and will be an easy fix. Installations using the Phar will not be impacted as the package manager still comes with these requirements included.

The versions of some the dependencies will be bumped. If you happen to not lock WP-CLI into a specific version constraint, but do so for some of its dependencies, you might see a version constraint conflict.

Any external code that relies on internal file structure, file naming or other internal details that are not part of the provided API could run the risk of breaking due to us moving things around from v1 to v2. This should hopefully not ever be the case, but you never know…

Does WP-CLI save you effort and time while working on the sites you manage?

Do you use WP-CLI to automate your infrastructure or deployments?

Do you feel positive about the WP-CLI project and its mission?

This guide will tell you about the many possibilities you have to get involved and play a role in this official WordPress team.

Introduction

First of all, thank you very much! If you’ve read this far, it must mean you are taking the initiative to contribute to WP-CLI. It’s because of you, and the community around you, that WP-CLI is such a great project. It not only makes for a fabulous tool people can use in a reliable manner, it also makes for a fun and rewarding project to collaborate on.

Contributing can take many forms, and we will discuss the most prominent ones. Before we start, though, here’s a list of what contributing is not:

Contributing is not limited to code.

Contributing does not require committing to a specific amount of time.

Contributing does not require expert knowledge in any of the areas it touches.

We encourage you to contribute in the way that best fits your interests and abilities. If at any point, you’re not sure how to proceed with whatever you are doing or feel you’re in over your head, help & support is just a chat message away! Please don’t hesitate at any point to just ask questions or let us know about the issue you’re facing.

Also, please do know that there are no expectations you need to fulfill or requirements you need to meet. This is meant to be an enjoyable, collaborative experience. So make sure you don’t put pressure on yourself and rectify your course of action if you feel that you’re not actually enjoying it anymore.

Now, with that clarification out of the way, let’s try to cover some of the most common ways of contributing to WP-CLI.

Spreading the message

Not everyone knows about WP-CLI or how it can help improve how you interact with a WordPress site.

There are multiple ways of how you can help spread the message about WP-CLI:

Post clever uses as tips to social media (tagging @wpcli on Twitter is always appreciated).

Supporting users

A great way to learn more about WP-CLI yourself and to help other people make progress is to jump into one of the support channels and try to answer questions other people have posted. Doing the detective’s work, understanding how the moving pieces work and finally getting to the bottom of a user’s problem can be very rewarding, and you learn all kinds of internal details along the way.

Any open issue/question/thread you can find in these locations are open for anyone to contribute an answer or to ask further questions to help diagnose the issue.

Improving documentation

Is documentation your strength? Take a look at the currently open documentation issues and see if you can tackle any of those, or create a new issue if you’ve read through the documentation and found it lacking in a specific area.

There are a couple different types of documentation currently part of WP-CLI:

Documentation for individual WP-CLI commands (anything underneath developer.wordpress.org/commands) is contained in the PHPDoc for each command. This means that to edit the documentation for a command, you will need to edit the file that actually provides the functionality for that command. The web documentation is generated from these files at the time of release, so you may not see your changes until the next release.

Individual documentation pages (anything under make.wordpress.org/cli/handbook) can be edited by contributing to the handbook repository on GitHub. You don’t necessarily need to navigate the Github repo though; any page that is part of this repository will have an Edit link in the top right of the page which will take you to the corresponding file on GitHub. Just clicking on that link brings you to a live editor which will generate a pull request out of your changes.

Localization

WP-CLI is in a special position when it comes to localization. Its main output is not supposed to be localized, as it is used for scripting purposes. If your scripts depend on a given string to be printed to the console, translating that string into a different language will, of course, break these scripts.

What should be translated, though, is the different types of documentation we have. Unfortunately, we are currently lacking the infrastructure support on make.wordpress.org/cli to properly support translated versions of the handbook or command reference.

What can be translated right now and is open for contributors is the README file shown as the frontpage on wp-cli.org. The different language versions can be found in subfolders in the wp-cli/wp-cli.github.com repository. Please use the English source version as the reference source, as it is the only one to be guaranteed to be up-to-date at any time.

Reporting security issues

Don’t publicly disclose a security issue you’ve just found!

The WP-CLI team and the WordPress community take security bugs seriously. We appreciate your efforts to responsibly disclose your findings and will make every effort to acknowledge your contributions.

To report a security issue in a responsible way, please visit the WordPress HackerOne program. You will be able to submit details about the security vulnerability in a confidential way, to avoid malicious users immediately exploiting the vulnerability on live sites. You will be contacted by the WordPress security team about next steps as soon as possible.

Requesting a new feature

This is the very first step that any new functionality should take. It will be further fleshed out within this issue until a decision has been made about whether the feature is a good fit for the official WP-CLI bundle and how the technical implementation should be handled. At that point, the issue will move into the repository where its code will finally reside.

Working on the code

Before you can start writing code, you need to decide what you plan on working on.

Good first issues
To get your feet wet with working on the WP-CLI codebase, you should star with one of the issues that are marked as good-first-issues. These issues usually require less historical knowledge and are very limited in scope and complexity. Often times, you’ll find the proper approach to solve the issue directly explained within the issue conversation.

Fixing a bug
Even though we spend a lot of time writing tests and reviewing code, we cannot completely avoid bugs in a codebase of this complexity.
If you want to see a list of known bugs and help fix them, you can use this GitHub search (*).

Implementing a new feature
You can find the collection of submitted feature requests in the issue tracker of the wp-cli/ideas repository. There are labels that define what the current state of a feature request is:

state:approved: This feature request has already been accepted in principle and only needs someone that can invest the time to make it happen.

state:considering: This feature request seems to be useful and a good fit for the project, but additional discussion and fleshing out is needed before a final decision can be made.

state:unlikely: This feature request was deemed not to be a good fit for the project. The reason for this is probably stated in the issue conversation. An implementation of this feature is unlikely to be accepted for bundling into an official release. Note: This might still be a useful third-party command in its own right.

In case there is no state label associated with the issue, it probably needs more extensive discussion still to find out how it relates to the official WP-CLI code.

On 🗓 Friday, 20th July 2018 we’ll officially kick off the WP-CLI Hack Day at 🕗 08:00 CEST. From that point on, I’ll be generally available in Slack #cli channel and on the GitHub wp-cli organization to onboard new contributors, help people pick issues to work on and remove hurdles that keep them from finishing their PRs. This will continue more or less without interruption during the entire event.

From 🕓 16:00-18:00 CEST we’ll have an open video chat that everyone can join, where we can discuss remaining issues live and chat about the progress we’ve made. This extended video chat session will then conclude the event. Shortly after 🕕 18:00 CEST, I will post a make/cli blog post about the progress we were able to make during the allotted time frame.

The 🎯 goal for this first WP-CLI Hack Day is both simple and ambitious:

Finish the day with 2️⃣0️⃣ pull requests that have been merged during the event ❗️

Everyone is welcome to participate! This event is supposed to be fun and inspiring, and we expect people to help each other make progress along the way.

I’m fully aware this is not ideal for everyone around the globe. Hopefully, this first try at such an event will be a big success, and we’ll try it again with more helpers and an extended time zone at a later date.

We’re excited to bring you WP-CLI v1.5.1, an intermediary bugfix release with a total of 52 merged pull requests since v1.5.0 in January 2018.

About this release

This is a bugfix release, which means that you shouldn’t expect major feature enhancements. We’re working hard on v2.0.0 which is planned for the summer, and all new features will have to wait for that big one.

Notable features

Yes, I just said not to expect any new features. However, a small number of features managed to sneak into this release nevertheless.

Edit your config files with ease

The config command now has a new config edit function that opens the wp-config.php file in your favorite editor for easy changes. You can configure the editor to be used through the EDITOR environment variable [#48].

Get better insight into your capabilities

Although WordPress is able to have a capability be set to false, to effectively mean an explicit “deny” of that capability, WP-CLI did not yet show that distinction. It only let you know that the capability was defined, but not whether it was negated, giving the false impression of it being “allowed” instead.

This has now changed, and you can get a complete picture of how the capabilities are set by adding the --show-grant to the cap list command [#19].

Breaking change: Note that the default behavior of cap list has slightly changed because of that. Whereas the previous version showed a capability set to false alongside the normal capabilities, a simple cap list without the new --show-grant flag will now hide the capabilities that are set to false, effectively returning only the capabilities that are actually “granted”.