Title: WP-CLI – Page 9 – The command line interface for WordPress

---

 [  ](https://profiles.wordpress.org/danielbachhuber/) [Daniel Bachhuber](https://profiles.wordpress.org/danielbachhuber/)
3:54 pm _on_ October 4, 2017      

# 󠀁[Daniel likes these issues](https://make.wordpress.org/cli/2017/10/04/daniel-likes-these-issues/)󠁿

WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative
and development tasks in a programmatic way. The project page is [http://wp-cli.org/](http://wp-cli.org/)
[https://make.wordpress.org/cli/](https://make.wordpress.org/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:

 * [Introduce `--version=beta` argument for updating to latest WordPress beta](https://github.com/wp-cli/core-command/issues/17)
   
   Adding this flag to `wp core update` will make it much easier for users to test
   the latest build during the betaBeta A pre-release of software that is given 
   out to a large group of users to trial under real conditions. Beta versions have
   gone through alpha testing in-house and are generally fairly close in look, feel
   and function to the final product; however, design changes often occur as part
   of the process. segment of the release cycle. Once this flag is implemented, 
   we can also [use `WP_VERSION=beta` in `wp scaffold plugin-tests`](https://github.com/wp-cli/scaffold-command/issues/20).
 * [Remove wordwrapping from command docs](https://github.com/wp-cli/wp-cli/issues/4284)
   
   Regex your jam? This shouldn’t be too difficult 😉
 * [Fail build when scaffolded README is out of date](https://github.com/wp-cli/scaffold-package-command/issues/116)
   
   The README for every WP-CLI repository is dynamically generated from its corresponding
   codebase. It currently has the problem of always being out of date. To better
   ensure it’s kept up to date, we should add some checking in the pull request 
   workflow.

[Read through the contributing guide](https://make.wordpress.org/cli/handbook/contributing/)
for a refresher on the process. Feel free to ask questions on the specific issue,
or join us in the [#cli channel](https://wordpress.slack.com/messages/C02RP4T41/)
with any questions you might have.

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F10%2F04%2Fdaniel-likes-these-issues%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/danielbachhuber/) [Daniel Bachhuber](https://profiles.wordpress.org/danielbachhuber/)
1:52 pm _on_ September 27, 2017      

# 󠀁[Good first issues for new contributors](https://make.wordpress.org/cli/2017/09/27/good-first-issues-for-new-contributors-4/)󠁿

Want to submit your first pull request to WP-CLIWP-CLI WP-CLI is the Command Line
Interface for WordPress, used to do administrative and development tasks in a programmatic
way. The project page is [http://wp-cli.org/](http://wp-cli.org/) [https://make.wordpress.org/cli/](https://make.wordpress.org/cli/)?
We’ve identified a few [good first issues](https://make.wordpress.org/cli/good-first-issues/)
for you to get your feet wet:

 * [Link to code review guidelines from PULL_REQUEST_TEMPLATE](https://github.com/wp-cli/scaffold-package-command/issues/132)
   
   We’ve published [code review guidelines](https://make.wordpress.org/cli/handbook/code-review/)
   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`](https://github.com/wp-cli/extension-command/issues/18)
   
   For those using a `db.php`, `object-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](https://github.com/wp-cli/wp-cli/issues/4379)
   
   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()`](https://github.com/wp-cli/wp-cli/issues/4380)
   
   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`](https://github.com/wp-cli/search-replace-command/issues/10)
   
   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](https://make.wordpress.org/cli/handbook/contributing/)
for details on how to get started. Feel free to ask questions on the specific issue,
or join us in the [#cli channel](https://wordpress.slack.com/messages/C02RP4T41/)
with any questions you might have.

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F09%2F27%2Fgood-first-issues-for-new-contributors-4%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/schlessera/) [Alain Schlesser](https://profiles.wordpress.org/schlessera/)
5:57 pm _on_ September 26, 2017      

# 󠀁[WordPress Plugin and Theme Checksums Project – Announcement](https://make.wordpress.org/cli/2017/09/26/wordpress-plugin-and-theme-checksums-project-announcement/)󠁿

## Overview

WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative
and development tasks in a programmatic way. The project page is [http://wp-cli.org/](http://wp-cli.org/)
[https://make.wordpress.org/cli/](https://make.wordpress.org/cli/) provides a way
for system administrators to verify the integrity of the WordPress coreCore Core
is the set of software required to run WordPress. The Core Development Team builds
WordPress. files. Through `wp checksum core`, you can easily verify that a given
installation has not been tampered with. It not only checks whether the correct 
files are in place, but also that their content has not been changed. This is possible
because WordPress provides an official APIAPI An API or Application Programming 
Interface is a software intermediary that allows programs to interact with each 
other and share data in limited, clearly defined ways. to check the expected core
file checksums at `https://api.wordpress.org/core/checksums/`.

Having this kind of functionality for plugins and themes as well would be a huge
security benefit. It would allow you to check the file integrity of an entire site,
possibly in an automated fashion. However, there is no centralized way of retrieving
the file checksums for plugins or themes yet, and the alternative of downloading
the plugins and themes from the official servers first just to check against them
is wasteful in terms of resources and bandwidth.

The aim of this project is to extend the checksum verification and its underlying
infrastructure so that it can reliably and efficiently check the integrity of plugins
and themes as well.

## Project Stages

The project will be structured into four stages. Each stage will be followed by 
a detailed report, containing a summary of the stage’s efforts as well as a clear
enumeration of decisions and results.

### A. Initiation (← we are here)

During this initial project stage, we raise awareness of the project and discuss
it with key stakeholders, sponsors, and volunteers.

We’ll evaluate the alternative approaches with all involved parties to distill the
most viable path to a maintainable solution.

Finally, we’ll define a clear scope for the project, and the metrics that define
its success. We plan for a working betaBeta A pre-release of software that is given
out to a large group of users to trial under real conditions. Beta versions have
gone through alpha testing in-house and are generally fairly close in look, feel
and function to the final product; however, design changes often occur as part of
the process. version by end of November, so we will want to keep the scope tight
for this first iteration.

### B. Planning

After we’ve decided on a specific route to follow, we can start planning the details
of the solution we want to implement.

This stage will result in a project roadmap with milestones and their respective
deliverables. It will also produce a list of requirements, like the provisional 
budget for infrastructure, the decisions needed or the estimated workload for each
milestone.

### C. Implementation

After we’ve planned all the technical details and broke down the work involved, 
we’ll start with building the infrastructure and implementing the client and server
software.

The specifics of how this stage will be handled should have been laid out during
the planning stage already, so this stage is all about execution and monitoring 
progress.

### D. Integration

During the final project stage, we will move all code and infrastructure to reside
under the official `wordpress.org` domain and complete the integration with the 
WordPress Core and the WP-CLI tool.

## Get Involved!

This project will have a huge impact on the perceived and effective security of 
WordPress installations. It can greatly reduce the amount of malware-infested sites
plaguing the internet, and through the substantial market share of WordPress, improve
the general browsing experience for all net citizens.

If you want to get involved, you’d ideally meet the following criteria:

 * You have a vested interest in security and/or system administration in a WordPress
   context.
 * You can spare a consistent average of ~5+ hours/week (hopefully on your employer’s
   time).
 * You have experience with one or more of the types of components this project 
   requires.

If this is you, please get in touch with us, either by commenting on this post or
by joining the discussion in the following GitHubGitHub GitHub is a website that
offers online implementation of git repositories that can easily be shared, copied
and modified by other developers. Public repositories are free to host, private 
repositories require a paid subscription. GitHub introduced the concept of the ‘
pull request’ where code changes done in branches by contributors can be reviewed
and discussed before being merged by the repository owner. [https://github.com/](https://github.com/)
issue: [https://github.com/wp-cli/ideas/issues/6](https://github.com/wp-cli/ideas/issues/6).

We will have a formal kickoff during the next WP-CLI office hours in the [#cli](https://wordpress.slack.com/messages/C02RP4T41)
channel on [October 3rd, 2017 at 16:00 UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20171003T1600).
Feel free to join the discussion and help us get this ball rolling.

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F09%2F26%2Fwordpress-plugin-and-theme-checksums-project-announcement%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/danielbachhuber/) [Daniel Bachhuber](https://profiles.wordpress.org/danielbachhuber/)
5:12 pm _on_ August 16, 2017      

# 󠀁[Free WP-CLI stickers for your event!](https://make.wordpress.org/cli/2017/08/16/free-wp-cli-stickers-for-your-event/)󠁿

> So good. [pic.twitter.com/s1K5PQRAHK](https://t.co/s1K5PQRAHK)
> — Daniel Bachhuber (@danielbachhuber) [June 9, 2017](https://twitter.com/danielbachhuber/status/873002418115444737)

Want to share your love of WP-CLIWP-CLI WP-CLI is the Command Line Interface for
WordPress, used to do administrative and development tasks in a programmatic way.
The project page is [http://wp-cli.org/](http://wp-cli.org/) [https://make.wordpress.org/cli/](https://make.wordpress.org/cli/)
with your community?

Starting today, you can [fill out this form to request stickers (free of charge)](https://docs.google.com/forms/d/e/1FAIpQLSdVbIFGUBMobqDnvzOw-4jV5tNuhZxIyXnU_wqt2TNooU3vfA/viewform?usp=sf_link)
to distribute at your WP-CLI-related event (WordCampWordCamp WordCamps are casual,
locally-organized conferences covering everything related to WordPress. They're 
one of the places where the WordPress community comes together to teach one another
what they’ve learned throughout the year and share the joy. [Learn more](https://central.wordcamp.org/about/).,
meetupMeetup All local/regional gatherings that are officially a part of the WordPress
world but are not WordCamps are organized through [https://www.meetup.com/](https://www.meetup.com/).
A meetup is typically a chance for local WordPress users to get together and share
new ideas and seek help from one another. Searching for ‘WordPress’ on meetup.com
will help you find options in your area., or otherwise).

Some fine print to be aware of:

 * Requests must be made at least four weeks in advance of the event by an official
   organizer of the event.
 * Offer is for up to 50 stickers to any geographic region [Stickermule](https://www.stickermule.com/)
   can ship to.
 * Stickers must be made available in a public common area and announced at the 
   beginning or end of the WP-CLI session.

Feel free to reach out to `danielbachhuber` on SlackSlack Slack is a Collaborative
Group Chat Platform [https://slack.com/](https://slack.com/). The WordPress community
has its own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/)
with any questions. Happy scripting!

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F08%2F16%2Ffree-wp-cli-stickers-for-your-event%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/danielbachhuber/) [Daniel Bachhuber](https://profiles.wordpress.org/danielbachhuber/)
6:27 pm _on_ August 15, 2017     
Tags: [make.wordpress.org/updates ( 10 )](https://make.wordpress.org/cli/tag/make-wordpress-orgupdates/),
[p2-xpost ( 31 )](https://make.wordpress.org/cli/tag/p2-xpost/)   

# 󠀁[X-post: Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017](https://make.wordpress.org/cli/2017/08/15/xpost-community-conduct-project-kick-off-meeting-scheduled-for-1700-utc-on-the-5th-september-2017/)󠁿

X-comment from [+make.wordpress.org/updates](https://make.wordpress.org/updates/):
Comment on [Community Conduct Project – Kick off meeting scheduled for 17:00 UTC on the 5th September 2017](https://make.wordpress.org/updates/2017/08/15/community-conduct-project-kick-off-meeting-scheduled-for-1700-utc-on-the-5th-september-2017/#comment-4135)

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F08%2F15%2Fxpost-community-conduct-project-kick-off-meeting-scheduled-for-1700-utc-on-the-5th-september-2017%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/danielbachhuber/) [Daniel Bachhuber](https://profiles.wordpress.org/danielbachhuber/)
4:16 pm _on_ August 8, 2017      

# 󠀁[Version 1.3.0 released](https://make.wordpress.org/cli/2017/08/08/version-1-3-0-released/)󠁿

Happy release day! After 210 total merged pull requests, we’re excited to bring 
you WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do 
administrative and development tasks in a programmatic way. The project page is 
[http://wp-cli.org/](http://wp-cli.org/) [https://make.wordpress.org/cli/](https://make.wordpress.org/cli/)
v1.3.0.

## Install packages with shortened identifiers

Recently, we have been [discussing the future of the WP-CLI package index](https://make.wordpress.org/cli/2017/07/05/how-should-we-embark-upon-new-feature-development/).
Our conclusion was to [deprecate the existing package index](https://make.wordpress.org/cli/2017/07/18/feature-development-discussion-recap/)
for now and provide a new mechanism for more easily installing external commands
that are hosted on GitHubGitHub GitHub is a website that offers online implementation
of git repositories that can easily be shared, copied and modified by other developers.
Public repositories are free to host, private repositories require a paid subscription.
GitHub introduced the concept of the ‘pull request’ where code changes done in branches
by contributors can be reviewed and discussed before being merged by the repository
owner. [https://github.com/](https://github.com/).

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](https://getcomposer.org/doc/articles/versions.md).

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](https://github.com/wp-cli/db-command/pull/29),
[#33](https://github.com/wp-cli/db-command/pull/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](https://github.com/wp-cli/db-command/pull/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](https://github.com/wp-cli/config-command/pull/22)].
 * `wp config create`:
    - Generates keys/salts locally and use WordPress.orgWordPress.org The community
      site where WordPress code is created and shared by the users. This is where
      you can download the source code for WordPress core, plugins and themes as
      well as the central location for community conversations and organization.
      [https://wordpress.org/](https://wordpress.org/) APIAPI An API or Application
      Programming Interface is a software intermediary that allows programs to interact
      with each other and share data in limited, clearly defined ways. as fallback[
      [#25](https://github.com/wp-cli/config-command/pull/25)].
 * `wp config get`:
    - Adds `--constant=<constant>` or `--global=<global>` to get the value of a 
      specific constant or global [[#16](https://github.com/wp-cli/config-command/pull/16)].
    - Indicates files included by `wp-config.php` [[#18](https://github.com/wp-cli/config-command/pull/18)].
 * `wp core (multisite-install|multisite-convert)`:
    - Use `--skip-config` to avoid addition of multisiteMultisite Multisite is a
      WordPress feature which allows users to create a network of sites on a single
      WordPress installation. Available since WordPress version 3.0, Multisite is
      a continuation of WPMU or WordPress Multiuser project. WordPress MultiUser
      project was discontinued and its features were included into WordPress core.
      [Advanced Administration Handbook -> Create A Network.](https://developer.wordpress.org/advanced-administration/multisite/create-network/)
      constants to `wp-config.php` file [[#18](https://github.com/wp-cli/core-command/pull/18)].
 * `wp import`:
    - Prevents non-existent directories from ending up in the list of files to import[
      [#8](https://github.com/wp-cli/import-command/pull/8)].
 * `wp media *`:
    - Changes media noun to ‘items’ in most cases, to reflect multi-type nature 
      of media [[#18](https://github.com/wp-cli/media-command/pull/18)].
 * `wp media import`:
    - Adds `--skip-copy` flag to allow import of media from local filesystem without
      moving on disk [[#21](https://github.com/wp-cli/media-command/pull/21)].
 * `wp package install`:
    - Adds support for short package identifiers [[#22](https://github.com/wp-cli/package-command/pull/22)].
 * `wp post term delete`:
    - Implements `--all` flag to remove all terms from a post [[#23](https://github.com/wp-cli/entity-command/pull/23)].
 * `wp scaffold *`:
    - Creates `phpcs.xml.dist` instead of custom-named `phpcs.ruleset.xml` [[#19](https://github.com/wp-cli/scaffold-command/pull/19)].
    - Better support for symbolic links [[#26](https://github.com/wp-cli/scaffold-command/pull/26)].
    - Changes the grunt config for `addtextdomain` to override all text domains 
      by default [[#28](https://github.com/wp-cli/scaffold-command/pull/28)].
 * `wp search-replace`:
    - Includes `--format=count` to only show number of rows affected [[#14](https://github.com/wp-cli/search-replace-command/pull/14)].
 * `wp term (get|update|delete)`:
    - Introduces `--by=<type>` argument to get/update/delete term by slug [[#27](https://github.com/wp-cli/entity-command/pull/27)].
 * `wp user *`:
    - Support fetching users with an email address in the login field [[#21](https://github.com/wp-cli/entity-command/pull/21)].
 * `wp super-admin remove`:
    - Allows revoking super-admin of non-existent user [[#6](https://github.com/wp-cli/super-admin-command/pull/6)].

**Framework enhancements**

 * Fixes autoload file names for `$custom_vendor` condition [[#4147](https://github.com/wp-cli/wp-cli/pull/4147)].
 * Saves runtime config so it can be passed as args to `Runner::run_alias_group()`
   invocation [[#4148](https://github.com/wp-cli/wp-cli/pull/4148)].
 * Manually loads comments if `opcache.save_comments` is disabled [[#4161](https://github.com/wp-cli/wp-cli/pull/4161)].
 * Allows numbers in subcommand names and arguments [[#4164](https://github.com/wp-cli/wp-cli/pull/4164),
   [#4269](https://github.com/wp-cli/wp-cli/pull/4269)].
 * Fixes double slash in `boot-phar.php` path [[#4169](https://github.com/wp-cli/wp-cli/pull/4169)].
 * Allows root use of `wp cli info`, in addition to `wp cli update` [[#4177](https://github.com/wp-cli/wp-cli/pull/4177)].
 * Updates SSHSSH Secure SHell - a protocol for securely connecting to a remote 
   system in addition to or in place of a password. URLURL A specific web address
   of a website or web page on the Internet, such as a website’s URL www.wordpress.
   org parser regexp to allow for null port number [[#4182](https://github.com/wp-cli/wp-cli/pull/4182)].
 * Add `WP_CLI\Utils\get_home_dir()` helper function [[#4184](https://github.com/wp-cli/wp-cli/pull/4184)].
 * Reduces included files (Behat/PHPUnit in particular) in built Phar [[#4185](https://github.com/wp-cli/wp-cli/pull/4185)].
 * Behat: Allows test DB user + pass to be set by environment variables [[#4196](https://github.com/wp-cli/wp-cli/pull/4196)].
 * Fixes output in JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable
   format for structuring data. It is used primarily to transmit data between a 
   server and web application, as an alternative to XML. format in case of error
   while encoding [[#4199](https://github.com/wp-cli/wp-cli/pull/4199)].
 * Passes `WP_CLI_STRICT_ARGS_MODE` on to `--ssh=<ssh>` if set [[#4207](https://github.com/wp-cli/wp-cli/pull/4207)].
 * Displays a more helpful error message when site cannot be found [[#4212](https://github.com/wp-cli/wp-cli/pull/4212)].
 * Fixes broken indentation on Windows systems because of line endings [[#4221](https://github.com/wp-cli/wp-cli/pull/4221),
   [#4222](https://github.com/wp-cli/wp-cli/pull/4222)].
 * Adapts `--ssh=<ssh>` flag to work with Docker and Docker Compose [[#4240](https://github.com/wp-cli/wp-cli/pull/4240)].
 * Checks for availability of `proc_open/close` in various scenarios [[#4245](https://github.com/wp-cli/wp-cli/pull/4245)].

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

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F08%2F08%2Fversion-1-3-0-released%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/danielbachhuber/) [Daniel Bachhuber](https://profiles.wordpress.org/danielbachhuber/)
10:42 am _on_ August 3, 2017      

# 󠀁[Good first issues for new contributors](https://make.wordpress.org/cli/2017/08/03/good-first-issues-for-new-contributors-3/)󠁿

WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative
and development tasks in a programmatic way. The project page is [http://wp-cli.org/](http://wp-cli.org/)
[https://make.wordpress.org/cli/](https://make.wordpress.org/cli/) v1.3.0 is [coming soon](https://twitter.com/wpcli/status/889893450635661312)!

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:

 * [Define known allowed fields for `wp user (create|update)`](https://github.com/wp-cli/entity-command/issues/19)
   
   To better communicate which arguments can be passed, define known accepted fields(
   e.g. `--user_login=<login>`) for each command.
 * [List common options and link to remaining available options](https://github.com/wp-cli/entity-command/issues/16)
   
   To better communicate which options are available for getting, setting or updating,
   we should list the most common and then link to some list on WordPress.orgWordPress.
   org The community site where WordPress code is created and shared by the users.
   This is where you can download the source code for WordPress core, plugins and
   themes as well as the central location for community conversations and organization.
   [https://wordpress.org/](https://wordpress.org/) with the remainder.
 * [Clarify “please flush object cache” message in multisite](https://github.com/wp-cli/search-replace-command/issues/12)
   
   On multisiteMultisite Multisite is a WordPress feature which allows users to 
   create a network of sites on a single WordPress installation. Available since
   WordPress version 3.0, Multisite is a continuation of WPMU or WordPress Multiuser
   project. WordPress MultiUser project was discontinued and its features were included
   into WordPress core. [Advanced Administration Handbook -> Create A Network.](https://developer.wordpress.org/advanced-administration/multisite/create-network/),
   we need to clarify you may need to flush cache against the old URLURL A specific
   web address of a website or web page on the Internet, such as a website’s URL
   www.wordpress.org after running `wp search-replace` before WP-CLI works against
   the new URL.
 * [Explain why certain tables can be skipped](https://github.com/wp-cli/search-replace-command/issues/10)
   
   We should add a concise description of why certain tables can be skipped (the
   full description is on the issue).

Feel free to weigh in on the corresponding issue with any questions. [Read through the contributing guide](https://make.wordpress.org/cli/handbook/contributing/)
for details on how to get started, or join us in the [#cli channel](https://wordpress.slack.com/messages/C02RP4T41/)
with any questions you might have.

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F08%2F03%2Fgood-first-issues-for-new-contributors-3%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/danielbachhuber/) [Daniel Bachhuber](https://profiles.wordpress.org/danielbachhuber/)
12:38 pm _on_ July 25, 2017      

# 󠀁[Community Summit: Contributing to WP-CLI](https://make.wordpress.org/cli/2017/07/25/community-summit-contributing-to-wp-cli/)󠁿

“Contributing to WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress,
used to do administrative and development tasks in a programmatic way. The project
page is [http://wp-cli.org/](http://wp-cli.org/) [https://make.wordpress.org/cli/](https://make.wordpress.org/cli/)”
was the second of two discussions we held at the Community Summit. For notes from
the first, [see details embedded in the feature development post](https://make.wordpress.org/cli/2017/07/05/how-should-we-embark-upon-new-feature-development/).

We began the conversation by giving an overview to the current contribution process.
Notably:

 * We have a primary [Contributing](https://make.wordpress.org/cli/handbook/contributing/)
   document that links to further detail on [submitting a bug report](https://make.wordpress.org/cli/handbook/bug-reports/)
   and [creating a pull request](https://make.wordpress.org/cli/handbook/pull-requests/).
 * Our documentation is produced in the [wp-cli/handbook](https://github.com/wp-cli/handbook/)
   repo and [pulled into WordPress.org](https://make.wordpress.org/cli/handbook/)
   site with a [WordPress plugin](https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/wporg-cli).
 * Command and internal APIAPI An API or Application Programming Interface is a 
   software intermediary that allows programs to interact with each other and share
   data in limited, clearly defined ways. documentation are [dynamically generated from the codebase with a WP-CLI command](https://github.com/wp-cli/handbook/blob/master/bin/command.php)
   and rendered into standalone markdown files.

From the introduction, the conversation turned more free-form. In no particular 
order, some highlights:

 * One big challenge is that WP-CLI is a rather complex project and assumes a lot
   of knowledge from a contributor. When onboarding new contributors, they have 
   to learn two things: the process for contributing, and how everything works (
   without reading the code). Although the internals page is reasonably helpful,
   it doesn’t cover the command execution flow. Having a flow document would be 
   useful.
 * One observation is that potential contributors can enter the project in different
   ways (e.g. GitHubGitHub GitHub is a website that offers online implementation
   of git repositories that can easily be shared, copied and modified by other developers.
   Public repositories are free to host, private repositories require a paid subscription.
   GitHub introduced the concept of the ‘pull request’ where code changes done in
   branches by contributors can be reviewed and discussed before being merged by
   the repository owner. [https://github.com/](https://github.com/) repo for a custom
   command vs. a third-party tutorial on how to use WP-CLI). Documentation primarily
   provides a linear path.
 * We’re seeing some contributors submit documentation but not a ton. It’s unclear
   whether this indicates the documentation is good enough, or whether the path 
   to contributing documentation is too confusing. It’d be helpful to see more users
   open questions about the documentation, as a way of validating/improving the 
   content.
 * Another challenge is that generally of WP-CLI tools is that the user knows the
   abstract problem, but not which command addresses the problem. Related to this:
    - It would be useful if a help command also included the URLURL A specific web
      address of a website or web page on the Internet, such as a website’s URL 
      www.wordpress.org for more information.
    - It’d be nice if you could easily see a tree of all commands.

Thanks to everyone who participated!

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F07%2F25%2Fcommunity-summit-contributing-to-wp-cli%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/schlessera/) [Alain Schlesser](https://profiles.wordpress.org/schlessera/)
9:58 pm _on_ July 18, 2017      

# 󠀁[Feature Development Discussion Recap](https://make.wordpress.org/cli/2017/07/18/feature-development-discussion-recap/)󠁿

This week’s WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used
to do administrative and development tasks in a programmatic way. The project page
is [http://wp-cli.org/](http://wp-cli.org/) [https://make.wordpress.org/cli/](https://make.wordpress.org/cli/)
office hours had been a special “_feature development and the package index_” edition,
as was announced in the previous post: [How should we embark upon new feature development?](https://make.wordpress.org/cli/2017/07/05/how-should-we-embark-upon-new-feature-development/)

Here’s a link to the [chat log](https://wordpress.slack.com/archives/C02RP4T41/p1500393700577255).
The attendees were: [@danielbachhuber](https://profiles.wordpress.org/danielbachhuber/),
[@dave_navarro](https://profiles.wordpress.org/dnavarrojr/), [@grapplerulrich](https://profiles.wordpress.org/grapplerulrich/),
[@miyauchi](https://profiles.wordpress.org/miyauchi/), [@modernnerd](https://profiles.wordpress.org/modernnerd/),
[@nerrad](https://profiles.wordpress.org/nerrad/), [@schlessera](https://profiles.wordpress.org/schlessera/).

#### Chat summary:

We started with a quick recap of what **the different approaches** were that we 
already presented in the previous post:

 a. No package index, but community-driven feature development
 b. Submission proposal that is coupled to precise quality and maintenance requirements
 c. Two-tiered system with both an “official” index and a “community” index

Most of the discussion that immediately followed revolved around **approach C**,
and what the best technical implementation of such a system would be.

It is clear that this involves a lot of work on the **infrastructure** that supports
these different tiers. Some existing package indexes/managers were mentioned as 
a comparison: `npm`/`packagist` in terms of being a similar CLICLI Command Line 
Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress.
tool, but also `rpm` as a package system that allows arbitrary repositories to be
added as a package source.

When I told the group that we were considering **going with approach A for now**,
while targeting some form of **C as a longer-term goal**, people seemed to agree
in principle. The discussion that followed then made it rather clear that we are
discussing **two distinct problem**s and trying to find a solution for both at the
same time:

 1. A mechanism to **install** external packages that allows to differentiate between“
    official” and “third-party” packages.
 2. A mechanism for **discovery** of new packages, that allows searching and/or browsing
    some type of collected index.

This lead the group to reason about these two problems separately, and ultimately
allowed us to **formulate the following plan**:

 * For installing packages, we won’t have an actual “index” in place, we accept 
   any Composer source (git repository, zip file, path to folder, …) as a package,
   with the added detail that a package identifier of `vendor/package` will **default
   to the corresponding GitHubGitHub GitHub is a website that offers online implementation
   of git repositories that can easily be shared, copied and modified by other developers.
   Public repositories are free to host, private repositories require a paid subscription.
   GitHub introduced the concept of the ‘pull request’ where code changes done in
   branches by contributors can be reviewed and discussed before being merged by
   the repository owner. [https://github.com/](https://github.com/) repository**.
 * This makes it obvious what an **“official” package** is: any package under the
   [`wp-cli`](https://github.com/wp-cli) GitHub organization.
 * This also allows all **third-party packages** that are hosted on GitHub to be
   easily installed via such a shortened package identifier, without the need to
   add them to any sort of index.
 * In case this is needed, we will provide a backward compatibility mapping to make
   sure the packages from the current package index still work as expected.
 * The current package index will be retired. It will not be deleted, though, to
   keep legacy versions of WP-CLI working as expected.
 * “Discovery” is then an entirely different problem and will be solved through 
   a separate (potentially third-party) project.

We will now start work on investigating this specific approach. Expect several issues
to pop up on GitHub related to this.

This also means that the **actual feature development** will now be handled as was
described for approach **A**. Ideas are collected within the [`wp-cli/ideas`](https://github.com/wp-cli/ideas/issues)
repository. The ones that get the most traction get included in the roadmap to build
as new official packages, which means they will be part of the `wp-cli` GitHub organization.
We will more clearly define our policies surrounding this process and include them
in the contributor’s documentation.

We are still very grateful about any feedback we can get about this important aspect
of WP-CLI, so don’t hesitate to **share your thoughts in the comments below!**

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F07%2F18%2Ffeature-development-discussion-recap%2F%23respond&locale=en_US)

 [  ](https://profiles.wordpress.org/danielbachhuber/) [Daniel Bachhuber](https://profiles.wordpress.org/danielbachhuber/)
1:21 pm _on_ July 5, 2017     
Tags: [cli ( 2 )](https://make.wordpress.org/cli/tag/cli/)

# 󠀁[How should we embark upon new feature development?](https://make.wordpress.org/cli/2017/07/05/how-should-we-embark-upon-new-feature-development/)󠁿

**Update July 11th:**  We’re having a follow-up discussion in SlackSlack Slack is
a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/). The
WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/)(
[#cli channel](https://wordpress.slack.com/messages/C02RP4T41/)) next Tuesday, July
18th at 16:00 UTC (9 am PT, 12 pm ET). Our goal is to get to the point where we 
have a rough sense of the path forward.

The WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do 
administrative and development tasks in a programmatic way. The project page is 
[http://wp-cli.org/](http://wp-cli.org/) [https://make.wordpress.org/cli/](https://make.wordpress.org/cli/)
package index is a [directory of user-maintained commands](http://wp-cli.org/package-index/).
For a long while now, submissions have been put on hold. I’d like to unblock new
feature development, but we first need to address the conundrum before us.

Originally, the package index was created as space for developers to share custom
WP-CLI commands. A developer would write a new command, submit it to the index, 
and the command would be [displayed on the website](http://wp-cli.org/package-index/)
for others to discover. The command would also become installable through `wp package
install`.

However, the package index suffered from the same problems that plague the WordPress
pluginPlugin A plugin is a piece of software containing a group of functions that
can be added to a WordPress website. They can extend functionality or add new features
to your WordPress websites. WordPress plugins are written in the PHP programming
language and integrate seamlessly with WordPress. These can be free in the WordPress.
org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/)
or can be cost-based plugin from a third-party. directory:

 * After a while, submitted packages are no longer actively maintained. Eventually,
   they become abandoned. Maintaining packages is commonly a solo-author activity
   when it needs to be a multi-author activity to be sustainable.
 * Over time, different implementations are submitted of the same feature. I actually
   ended up pausing acceptance of new packages when four of five submissions were
   near duplicates of existing packages.

Just like WordPress, **the end-user experience is the priority for the WP-CLI project**.
It’s a bad user experience to have to choose from multiple poorly-maintained implementations
of the same feature. It’s a much better user experience to have one high-quality,
well-documented solution to a specific problem.

Not only that, but we’d much rather focus contributor effort towards maintaining
common packages, rather than have spread amongst a number of one-off individual 
implementations. The maintenance burden of the command ecosystem is much easier 
to manage when somewhat centralized, than spread amongst numerous small projects.

Given what we know at the moment, **our priorities** are the following:

 * Provide an outstanding user experience.
 * Have a streamlined pipeline for adding needed functionality.
 * Be able to maintain and adopt packages to keep them available for the community.
 * Keep maintenance effort in check.
 * Encourage contributions in many forms.

What **we want to avoid** is any of the following:

 * Outdated / abandoned packages being endorsed to users.
 * Duplicated functionality causing confusion.
 * Maintainers being a bottleneck.

We were fortunate enough to be able to discuss this problem during the WordPress
Community Summit. Brainstorming with other community members, we were able to identify
three possible approaches so far:

**A. No package index, but community-driven feature development.**

Ideas are collected within the wp-cli/ideas repository or a similar tool. The ones
that get the most traction or votes get included in the roadmap to build as new 
official packages.

Observations from the discussion:

 * Solves problems noted above by having WP-CLI be the sole source of endorsed packages.
 * Not practically feasible in terms of team effort.
 * Too slow to make progress and act on requirements.

**B. Submission proposal that is coupled to precise quality and maintenance requirements.**

To get included in the package index, you need not only ensure high quality but 
also commit to regular maintenance.

Observations from the discussion:

 * Adds strict procedures and requirements to the current package index.
 * Could include the provision that abandoning a package will cause it to be adopted
   by the WP-CLI project itself.
 * Growing team effort that will become problematic over time.

**C. Two-tiered system with both an “official” index and a “community” index.**

The “official” index is controlled and endorsed by the WP-CLI team, while the free-
for-all “community” index will include a notice that use of these packages is at
everyone’s own risk.

Observations from the discussion:

 * Completely open directory is valuable for innovation.
 * Submissions could default to the “community” index, and packages then need to
   submit a proposal to get “promoted” to the “official” one if they meet the requirements.
 * Adds cognitive overhead by having two sources of packages, with potentially two
   different mechanisms of installation.

None of these three approaches is a perfect fit for our priorities above, they just
provide differing sets of benefits and drawbacks. In addition, we are quite sure
there are other models out there that can potentially be adapted to meet our needs.

**This is where we are hoping for valuable input from the community.** There are
some specific decisions we need to make:

 * What process should we follow for new feature development?
 * Is it possible to adapt the existing package index to help us achieve our priorities?
 * If yes, what form should it take?
 * If no, is there another mechanism might we employ?
 * What should we do with the pending submitted packages?

Have some perspective to share or process to suggest? Know of other projects that
we can model our approach on? We’d appreciate your comment on this post, especially
if it also includes pros, cons, expected maintenance burden effort, etc.

Please keep in mind that we may make a decision you don’t agree with. Our decision
will be biased to reflect the priorities of the project.

We greatly welcome your input to the decision-making process, though, particularly
to the degree that it’s respectful, introduces perspective we may not have considered,
and represents a great deal of thought and consideration.

[#cli](https://make.wordpress.org/cli/tag/cli/)

 * [Login to Reply](https://login.wordpress.org/?redirect_to=https%3A%2F%2Fmake.wordpress.org%2Fcli%2F2017%2F07%2F05%2Fhow-should-we-embark-upon-new-feature-development%2F%23respond&locale=en_US)

## Post navigation

[← Older posts](https://make.wordpress.org/cli/page/10/?output_format=md)

[Newer posts →](https://make.wordpress.org/cli/page/8/?output_format=md)