Good issues for new and existing contributors

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

If you’ve contributed to WP-CLI before, here are some reasonably well-defined issues we’d like to see pull requests for:

Read through the contributing guide for details on how to get started. Feel free to ask questions on the specific issue, or join us in the #cli channel with any questions you might have.

Version 1.4.1 released

Gosh darn those pesky bugs.

WP-CLI v1.4.1 fixes a few annoying regressions introduced in v1.4.0:

  • Strips Composer autoload of PHPCS references to prevent PHP notices in Phar build [#4477].
  • plugin status: Colorizes and adds a legend to listed drop-ins to prevent PHP notice [#62].
  • search-replace: Uses $wpdb->remove_placeholder_escape() when exporting in WP 4.8.3 and greater [#43].

Want to help us catch these bugs earlier? Run wp cli update --nightly in your local and staging environments to use the latest and greatest.

Contributors to this release (3 total): danielbachhubergitlost, mullnerz

Daniel likes these issues

WP-CLI’s next release, v1.4.0, is just around the corner: Tuesday, October 17th. If you’ve contributed to WP-CLI before, here are a few moderately advanced issues I’d love to see fixed in the next release:

Read through the contributing guide for a refresher on the process. Feel free to ask questions on the specific issue, or join us in the #cli channel with any questions you might have.

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 you to get your feet wet:

  • Link to code review guidelines from PULL_REQUEST_TEMPLATE
    We’ve published code review guidelines that now need to be incorporated into our PULL_REQUEST_TEMPLATE scaffolding. This issue involves a one-line change to a template file.
  • List dropin plugins in wp plugin list
    For those using a db.phpobject-cache.php, or similar, it’d be helpful to display them when running wp plugin list. This issue involves writing a bit of code with Behat functional tests around the behavior.
  • Add pre-built dictionary of “did you mean…” suggestions
    When a user mistypes a command argument, WP-CLI tries to suggest the correct argument. In certain cases, the algorithm needs enhancement from a dictionary of pre-defined corrections. This issue involves reviewing WP-CLI command arguments, writing a bit of code to produce a dictionary around the most sensible corrections, and enhancing our existing PHPUnit tests for the feature.
  • Handle all cases for Utils\wp_version_compare()
    As it turns out, WordPress has some version strings that version_compare() can’t handle. Our existing utility is inadequate for all of the cases, so we should update. This issue involves tracking down all potential version strings, writing a bit of code, and enhancing our existing PHPUnit tests for the feature.
  • Explain why certain tables can be skipped when using wp search-replace
    There are a couple of cases, indicated in the issue, where tables can be skipped or “missed” entirely. This issue involves adding some explanation of these cases to the existing command documentation.

Read through the contributing guide for details on how to get started. Feel free to ask questions on the specific issue, or join us in the #cli channel with any questions you might have.

Version 1.3.0 released

Happy release day! After 210 total merged pull requests, we’re excited to bring you WP-CLI v1.3.0.

Install packages with shortened identifiers

Recently, we have been discussing the future of the WP-CLI package index. Our conclusion was to deprecate the existing package index for now and provide a new mechanism for more easily installing external commands that are hosted on GitHub.

As of WP-CLI v1.3.0, whenever you provide a package identifier in the form of <vendor>/<package>, WP-CLI will first check the deprecated package index (for backward compatibility reasons), and then check for a GitHub repository that matches this identifier. This also accepts all version qualifiers/requirements that Composer can parse.

Examples:

# Install vendor/command from GitHub (uses https://github.com/vendor/command):
$ wp package install vendor/command

# Install version 1.0.5 of vendor/command:
$ wp package install vendor/command:v1.0.5

# Install commit 95ce52b of vendor/command:
$ wp package install vendor/command:dev-master#95ce52b

New commands

Wondering whether a specific string exists in your database? Wonder no more! Use the new wp db search to search through all text columns in your database for your specified string (or regex pattern) [#29, #33]:

# Search through the database for the 'http://' regular expression, printing stats.
$ wp db search 'http:\/\/' --regex --stats
wp_comments:comment_author_url
1:https://wordpress.org/
    ...
Success: Found 99146 matches in 10.752s (10.559s searching). Searched 12 tables, 53 columns, 1358907 rows. 1 table skipped:
wp_term_relationships.

Need easy access to the database prefix for chaining into other commands? Use wp db prefix to print it out [#22]:

$ wp db prefix --url=example.com/foo
wp_3_

Everything else in v1.3.0

Command improvements

  • wp config *:
    • Errors early when no wp-config.php can be found [#22].
  • wp config create:
    • Generates keys/salts locally and use WordPress.org API as fallback [#25].
  • wp config get:
    • Adds --constant=<constant> or --global=<global> to get the value of a specific constant or global [#16].
    • Indicates files included by wp-config.php [#18].
  • wp core (multisite-install|multisite-convert):
    • Use --skip-config to avoid addition of multisite constants to wp-config.php file [#18].
  • wp import:
    • Prevents non-existent directories from ending up in the list of files to import [#8].
  • wp media *:
    • Changes media noun to ‘items’ in most cases, to reflect multi-type nature of media [#18].
  • wp media import:
    • Adds --skip-copy flag to allow import of media from local filesystem without moving on disk [#21].
  • wp package install:
    • Adds support for short package identifiers [#22].
  • wp post term delete:
    • Implements --all flag to remove all terms from a post [#23].
  • wp scaffold *:
    • Creates phpcs.xml.dist instead of custom-named phpcs.ruleset.xml [#19].
    • Better support for symbolic links [#26].
    • Changes the grunt config for addtextdomain to override all text domains by default [#28].
  • wp search-replace:
    • Includes --format=count to only show number of rows affected [#14].
  • wp term (get|update|delete):
    • Introduces --by=<type> argument to get/update/delete term by slug [#27].
  • wp user *:
    • Support fetching users with an email address in the login field [#21].
  • wp super-admin remove:
    • Allows revoking super-admin of non-existent user [#6].

Framework enhancements

  • Fixes autoload file names for $custom_vendor condition [#4147].
  • Saves runtime config so it can be passed as args to Runner::run_alias_group() invocation [#4148].
  • Manually loads comments if opcache.save_comments is disabled [#4161].
  • Allows numbers in subcommand names and arguments [#4164, #4269].
  • Fixes double slash in boot-phar.php path [#4169].
  • Allows root use of wp cli info, in addition to wp cli update [#4177].
  • Updates SSH URL parser regexp to allow for null port number [#4182].
  • Add WP_CLI\Utils\get_home_dir() helper function [#4184].
  • Reduces included files (Behat/PHPUnit in particular) in built Phar [#4185].
  • Behat: Allows test DB user + pass to be set by environment variables [#4196].
  • Fixes output in JSON format in case of error while encoding [#4199].
  • Passes WP_CLI_STRICT_ARGS_MODE on to --ssh=<ssh> if set [#4207].
  • Displays a more helpful error message when site cannot be found [#4212].
  • Fixes broken indentation on Windows systems because of line endings [#4221, #4222].
  • Adapts --ssh=<ssh> flag to work with Docker and Docker Compose [#4240].
  • Checks for availability of proc_open/close in various scenarios [#4245].

Contributors to this release (45 total): aaemnnosttv, BhargavBhandari90, chetansatasiya, chriszarate, cjhaas, colemanedwards, danielbachhuber, davetha, drrobotnik, electrokit, emgk, emirpprime, erikjoling, fjarrett, freegenie, gitlost, greatislander, iansvo, Ippey, jalavoy, jameselks, joehoyle, johnbillion, @JPry, junaidbhura, kouratoras, lucatume, @mapk, mikeschinkel, miya0001, @murtzsarialtun, nikolov-tmw, pierre-dargham, plastikdreams, rahul286, ronaksampat, schlessera, Sidsector9, soulseekah, szepeviktor, tfrommen, vbaranovskiy-plesk, westonruter, wp-make-coffee, wpbullet

Good first issues for new contributors

WP-CLI v1.3.0 is coming soon!

Want to submit your first pull request to WP-CLI? We’ve identified a few good first issues we’d love to get in the next release:

Feel free to weigh in on the corresponding issue with any questions. 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.

Version 1.2.1 released

As it turns out, refactoring can introduce bugs. Who knew?!

WP-CLI v1.2.1 fixes a few regressions introduced in v1.2.0:

  • Properly registers commands to existing namespaces when defined by plugins [#4123, #4130].
  • Restores compatibility with using WP-CLI as a dependency of a Composer-based WordPress install [#4126].
  • Only forces use of /usr/bin/mysql on *nix systems [#4132].
  • Improves wordwrapping by using total columns in terminal, instead of an arbitrary width [#4133].

Want to help us catch these bugs earlier? Run wp cli update --nightly in your local and staging environments to use the latest and greatest.

Contributors to this release (4 total): danielbachhubergitlostschlesseraszepeviktor

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.

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

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.