Contributions Contributions Bug reports - Help ensure your issue is resolved in a timely manner. Contributing - An introduction to the contributing process. WordCamp Contributor Day - Quick-start guide for WordCamp Contributor Days. Ideas - Up-vote existing ideas or submit your own. Governance - Summary of those behind WP-CLI. Licensing - License requirements for third-party code and dependencies. Implementation details - Catalog of historical design decisions. Philosophy - Guidelines which inform project scope, command organization, and behavior. Pull requests - Submit your first bug fix or new feature. Release checklist - Tasks performed during the process of tagging a release. Roadmap - Where WP-CLI is going in the future. Security Vulnerability Reporting - How we accept and evaluate vulnerability reports. Code Review - Quality Assurance on WP-CLI Committers credo - Product quality, Stellar judgement, Consistent participation Repository Management - Naming, Versions, Milestones, Labels Bug Reports Think you've found a bug? We'd love for you to help us get it fixed. Before you create a new issue, you should: Search existing issues to see if there's an existing resolution to it, or if it's already been fixed in a newer version. Check our documentation on common issues and their fixes. It's worth reading through the GitHub issues linked on the page, as the error listed may not be exactly the error you're experiencing. Reproduce the issue in a fresh installation of WordPress (e.g. Twenty Sixteen or similar, with no plugins active). If the issue only reproduces in a custom environment, then the issue is a bug in your environment, not WP-CLI (make sure WP_DEBUG is enabled, which will often give you more visibility into the issue). You may be able to track down the error to a specific plugin or theme. Once you've done a bit of searching and discovered there isn't prior art for your bug, please create a new GitHub issue in the appropriate repository. Providing the summary, steps to reproduce, environmental details, and other specifics identified below will help guarantee you are submitting a full bug report. Summary In narrative form, such as “While testing feature x, I encountered z.” Summary: After installing the following package on newest nightly version of the WP-CLI, I receive "is not a registered wp command error" Steps to reproduce the bug Please be as detailed and specific as possible. It's a good idea to go back and follow your steps a second time to make sure another user can recreate the issue by following the steps directly without assuming any actions. Steps to reproduce: Run command 'wp package install wp-cli/scaffold-package-command:@stable' Allow installation process to complete 'Success: Package installed.' is displayed Run 'wp help scaffold package' Observe 'Error: 'scaffold package' is not a registered wp command.' If you have a great deal of output to share, please create a GitHub gist and link to it in the issue. Environment Your bug may also be environment-specific. Because WP-CLI is a tool whose behavior is different from system to system, please include some environmental details in your issue if you think they're relevant. # What PHP environment does WP-CLI run in? wp cli info # Are you running suhosin? If so, make sure you've added `suhosin.executor.include.whitelist = phar` to your php.ini php -m | grep -i suhosin # Can you share the results of which wp ? which -a wp stat $(which wp) # Are you running any packages? If one is causing a problem, you can use `--skip-packages` to skip loading them wp package list Results and impacts Explain how the bug affects your usage, including severity level (what were the expected results, what were the actual results? who, how and to what degree affected?). Severity - High Expected Results: Running wp help scaffold package displays help information for installed command. Actual Results: 'Error: 'scaffold package' is not a registered wp command' is displayed. This command is crucial for the daily function of our business. 1.2k other users also have installed this package and will be affected. The installed package works without issue using WP-CLI 1.2.0-alpha-3182ac4 Workarounds Do any workarounds exist? If so, what are they? Workaround: Rollback to working version of WP-CLI Relevant diagnostics Include any crash reports, stack traces or debug output relevant to the issue. Any screenshots or gifs of issue are helpful too! Have a lot of output? Make your issue easier to understand by creating a GitHub gist and linking to it in the issue. If you include the --debug flag when executing WP-CLI (e.g. wp post list --debug), you may get more verbosity into the source of the error to include in the report. $ wp package install wp-cli/scaffold-package-command:@stable Installing package wp-cli/scaffold-package-command (@stable) Updating /root/.wp-cli/packages/composer.json to require the package... Using Composer to install the package... --- Loading composer repositories with package information Updating dependencies Resolving dependencies through SAT Dependency resolution completed in 0.001 seconds Analyzed 421 packages to resolve dependencies Analyzed 96 rules to resolve dependencies Package operations: 1 install, 0 updates, 0 removals Installs: wp-cli/scaffold-package-command:1.2.0 - Installing wp-cli/scaffold-package-command (1.2.0) Writing lock file Generating autoload files --- Success: Package installed. $ wp help scaffold package --debug Debug (bootstrap): Loading packages from: /root/.wp-cli/packages/vendor/autoload.php (0.044s) Debug (bootstrap): No readable global config found (0.193s) Debug (bootstrap): No project config found (0.194s) Debug (bootstrap): argv: /usr/local/bin/wp help scaffold package --debug (0.194s) Debug (bootstrap): ABSPATH defined: /home/fu/public_html/ (0.195s) Debug (bootstrap): Begin WordPress load (0.195s) Debug (bootstrap): wp-config.php path: /home/fu/public_html/wp-config.php (0.196s) Debug (bootstrap): Loaded WordPress (1.323s) Debug (bootstrap): Running command: help (1.323s) Error: 'scaffold package' is not a registered wp command. wp scaffold package does not work either: $ wp scaffold package Error: 'scaffold package' is not a registered subcommand of 'scaffold'. See 'wp help scaffold'. Code Review Code review is a core part of the WP-CLI project's software development workflow. Code review and pairing on code are necessary to maintain quality output, as well as build cohesive styles in our work. Having a well-understood and cohesive style can make all our work easier to approach and maintain for new as well as established developers. If done right, code review can also be a learning process for all involved. Here's a typical code review workflow: What code review is How to review code How to receive code review A typical code review workflow We're currently using GitHub for everything. Read up on our GitHub workflow for details of process, naming, usage of issues and pull requests. A moderately complex issue will typically be addressed across multiple pull requests, each tackling a distinct part of the issue. This makes review simpler because each review stage will be looking at a small code. On every commit pushed to a GitHub branch, our CI automated tests -- linting for all code, unit tests for functional code, and ideally, behavioral and automated acceptance testing -- are run through GitHub Actions. If the build passes, the PR can be reviewed. If not, the original developer is responsible for getting the build to the point where it passes. When the original developer is satisfied with their work, they can request a review from the committers team by assigning @wp-cli/committers for review. Simple pull requests can often be merged by the developer who reviews them. More complex changesets will often require conversations back and forth between reviewer and developer, and should have secondary reviewers. GitHub's "Files Changed" tab is a good place to leave inline comments on specific parts of the changeset. More general comments can be left on the pull request's "Conversation" tab. The reviewer may suggest changes in the form of a pull request off of the branch being reviewed, or in comments. The developer will make changes suggested, discuss the issue for clarity, and may mention the reviewer when they are satisfied with their work. If a pull request needs final cleanup before merging or has been abandoned, the reviewer can commit directly to the branch. However, avoid rewriting code without consultation. When the reviewer is satisfied with the changes, they can either merge or assign the pull request to a second reviewer for merge. The original developer (and ideally the reviewer) should both be available for a couple of days post-merge to address any issues that arise. What code review is A good way to visualize the objectives of code review is this analogy to Maslow's "Hierarchy of Needs" pyramid. From the most basic to the highest level, a reviewer checks that code is Correct, Secure, Readable, Elegant, and Altruistic. It's important to keep this sense of priorities: if a change introduces unhandled edge cases, bugs, or security vulnerabilities, those issues need to be addressed before coding style guidelines or beautification practices preferences will matter. How to review code As a reviewer, your first job is to get an understanding of what the proposed change does and why it's essential. There's no point in critiquing anything until you understand what it does, why it's necessary, and what decisions went into the way this was built. Next, look it over for correctness. Are all functions that take parameters and produce output covered by functional unit tests? Do they actually do what they're supposed to? Can you picture an edge case where a function would error unexpectedly or return something other than the expected result? If this command has output, does it render properly in all situations? Are all global flags handled? Does it have unsurprising fallbacks for uncommon situations? Does it handle errors with clear output messages? If it addresses the business and UX requirements, the next thing to check for is security. Does it follow basic sanitization and escaping practices for all untrusted input? If it interacts with other aspects of the codebase, is it liberal in the inputs it accepts and conservative in its output, making sure to only pass expected values? Think like an attacker. If there's any way a malicious agent could exploit this code, or an unlucky user could trigger a bug that fatals or looks bad, it's your job to find it. Next, check for readability. Functions, variables, and files should be named clearly according to their meaning. Everything should adhere to the surrounding code style. All code in any code-base should look like a single person typed it, no matter how many people contributed. -- Principles of writing Idiomatic JavaScript As readability is inherently subjective, this requires the ability to look back from the immediate code changes to the bigger picture. Think of someone months down the road trying to trace a given code path through the current changeset. Are there unnecessary steps that could be simplified? Are code comments and inline documentation robust enough to recreate the thought process behind the code? Finally, check for elegance and overall quality. Code should follow existing and known patterns so that others can understand it at a glance. If a change introduces a chance to refactor surrounding functionality, to abstract and standardize old code into new patterns, suggest those opportunities. How to receive code review As the person receiving the code review, your job is to learn from suggestions. Defensiveness, stubbornness, or impatience can prevent you from getting the most out of suggestions. It's OK to explain yourself if you feel the reviewer seemed to misunderstand your intent. Arguing semantics or insisting on the correctness of one approach is almost always a bad habit and distracts from the team process. If something isn't clear to someone familiar with the codebase who's reviewing your work today, it will definitely be unclear to a new developer being on-boarded six months from now. It's best to respond to the issues addressed by the reviewer as quickly as possible. Keep in mind that the review process requires context switching on the part of the reviewer as well as on your part, and the more immediate that process is, the less disruptive that context switch will be. Additional readings Glen Sanford: On code review - "Pending code reviews represent blocked threads of execution[, code review should always be your top priority]" The Ten Commandments of Egoless Programming - "Understand and accept that you will make mistakes. The point is to find them early before they make it into production." Committers Credo Some people have write access to WP-CLI repositories. These people are identified in the following teams: maintainers - Project leadership committers - Trusted contributors This “Committers credo” is a living document. It’s meant to establish generally agreed upon standards for committers, and will continue to evolve over time. Product quality WP-CLI is a project depended upon by the entire WordPress ecosystem. This trust is earned by producing a consistent, dependable, and high quality product. WP-CLI committers hold product and code quality in the highest regard. Practically-speaking: Given a choice between Good, Fast, and Cheap, we pick Good and Slow. Creating great software is a journey, not a destination. Product decisions are made in alignment with our core philosophy. Code review is an integral part of our development workflow. Pull requests need approval of at least one other committer before merging. If you’d like more than one code review, please don’t hesitate to request one. You can request a review from a specific person, or from the @wp-cli/committers team. If you need help with something, ask for help. Seriously, ask for help any time you feel like you need help. No sense getting stuck. Stellar judgement A great product is a reflection of thoughtful, deliberate, and considered decision-making. WP-CLI committers exhibit stellar judgement when making decisions on new features, fixing bugs, merging others' pull requests, and generally working on the project. The basis of this decision-making ensures: New features fit within the scope and philosophy of the WP-CLI project. Bug fixes are prioritized, because bugs negatively affect the product quality. Pull requests include tests covering the scope of the change. Potential code additions are evaluated on their maintenance burden as well as their usefulness. Consistent participation Effective involvement with the WP-CLI project requires consistent involvement, clarity of communication, and a propensity to help others. As a widely adopted project, WP-CLI has a diverse user base. Helping this user base has tremendous opportunity for impact. WP-CLI committers prioritize clearing others’ blockers over their own work, knowing this is a key contributor to a stable community. Notably, the idea that "pending code reviews represent blocked threads of execution" can be applied broadly across all forms of collaboration. Prioritize providing feedback to others over your own work, if your feedback is blocking their progress. Request a code review for a pull request by assigning the @wp-cli/committers team for review. Committer participation isn’t just committing code. Often, you can have a huge amount of impact by investing a little bit of your time into: Refining an existing piece of documentation, or drafting a new one. Helping a contributor with whatever is needed to finish up their pull request. If a contributor abandons a pull request (e.g. no activity in two weeks) that's close to a mergeable state, you can perform any necessary cleanup by committing directly to their branch and get it over the finish line. Triaging issues by spending 5-10 minutes further diagnosing the report and commenting with additional information you’ve discovered. Contributing Welcome and thanks! We appreciate you 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. Contributing isn’t limited to just code. We encourage you to contribute in the way that best fits your abilities, by writing tutorials, giving a demo at your local meetup, helping other users with their support questions, or revising our documentation. Please take a moment to read these guidelines in depth. Following the guidelines helps to communicate that you respect the time of the other contributors to the project. In turn, they’ll do their best to reciprocate that respect when working with you, across timezones and around the world. Should you have any questions about contributing, please join the #cli channel in the WordPress.org Slack. Reporting Security Issues The WP-CLI team and 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, please visit the WordPress HackerOne program. Reporting a bug Think you’ve found a bug? We’d love for you to help us get it fixed. Before you create a new issue, you should search existing issues to see if there’s an existing resolution to it, or if it’s already been fixed in a newer version of WP-CLI. You should also check our documentation on common issues and their fixes. Once you’ve done a bit of searching and discovered there isn’t an open or fixed issue for your bug, please follow our guidelines for submitting a bug report to make sure it gets addressed in a timely manner. Creating a pull request Want to contribute a new feature? WP-CLI is a mature project, and already chock-full of useful functionality. Please first open an ideas issue to suggest new commands, or open an issue in the appropriate repository to suggest enhancements to existing commands. Opening an issue before submitting a pull request helps us provide architectural and implementation guidance before you spend too much time on the code. New to the WP-CLI codebase? Check out issues labeled 'good-first-issue' for a place to start. These issues are specially earmarked for new contributors. Once you've decided to commit the time to seeing your pull request through, please follow our guidelines for creating a pull request to make sure it's a pleasant experience. See "Setting up" for details on making local modifications to WP-CLI. Keep in mind pull requests are expected to have tests covering the scope of the change. Read through our code review guidelines for a better understanding of how your pull request will be evaluated. Improving our documentation Is documentation your strength? Take a look at the currently open documentation issues and see if you can tackle any of those. 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. Contributing in other ways Feel free to create an issue with your question, and we'll see if we can find an answer for it. Alternatively, if you have a WordPress.org account, you may also consider joining the #cli channel on the WordPress.org Slack organization. Governance This document describes the governance structure of the WP-CLI project. Who's in charge? WP-CLI has one maintainer: schlessera. On a day to day basis, final decision-making authority resides with him. The project roadmap is an organic, evolving vision developed between the project's maintainers, committers, and contributors. Generally, we try to make decisions in alignment with the project's philosophy and committers credo. Why are some people members of the WP-CLI organization? On occasion, we grant write access to contributors who have demonstrated, over a period of time, that they are capable and invested in moving the project forward. These committers are expected to: Hold product and code quality in the highest regard. Exhibit stellar judgement and communication. Participate in the project on a consistent basis. Becoming a committer can seem glamorous, but it also comes with expectations of responsibility, commitment, and humility. andreascreten is the original author of WP-CLI. scribu and danielbachhuber have been long time maintainers. schlessera is the current maintainer. The maintainer is the person most directly responsible for the reliability and longevity of the project. They are expected to: Hold WP-CLI's overall quality in the utmost regard. Refine the project's vision and direction, and make sure it's understood by all. Enable everyone from new users to experienced committers. Take care of the boring day-to-day work (keeping CI passing, triaging new issues, etc.). What's the connection between WP-CLI and WordPress? As of December 2017, WP-CLI is a formal WordPress project. Practically speaking, this means we get to take advantage of the WordPress project's people and software infrastructure: Much of the WP-CLI documentation is hosted on the wordpress.org domain. We get to use the #cli channel in the WordPress Slack organization. If we need help with something, we can ask. Two core committers (dd32 and pento) have ownership permissions to the WP-CLI GitHub organization, in the unlikely event everyone else gets hit by a bus. Other than this, WP-CLI operates independently. How does all of this work? The WP-CLI GitHub organization contains all project code repositories. Some commands are bundled with WP-CLI, while others are independently installable. Commands are bundled with WP-CLI when they're stable, closely aligned with the project philosophy, and useful to a majority of users. wp-cli/wp-cli is the main project repository, which pulls in command packages and other dependencies through Composer. Composer defines which version of which dependencies is included in the build. Changes to command packages are included in WP-CLI proper when a stable release is tagged for the package. Build artifacts are published to the builds repository. Releases are prepared manually in accordance with the release checklist. The wp-cli.org domain is currently owned by andreascreten. DNS is managed through a Cloudflare account that danielbachhuber holds credentials to. Much of the WP-CLI documentation (command pages, etc.) is editable through wp-cli/handbook, and then synced to WordPress.org. The WP-CLI.org homepage is hosted on GitHub Pages. From time to time, you may see a pull request from the wp-make-coffee bot. These originate from a donated WebFaction server running some cron jobs calling bash scripts: 5 4 * * 1,3,5 source ~/.bash_profile; WP_CLI_DIR=~/wp-cli bash ~/wp-cli/utils/auto-composer-update.sh > ~/auto-composer-update.log 2>&1 5 6 * * 1,3,5 source ~/.bash_profile; WP_CLI_DIR=~/wp-cli-bundle bash ~/wp-cli-bundle/utils/auto-composer-update.sh > ~/auto-composer-update-bundle.log 2>&1 The wpcli Twitter account is managed by schlessera. If you subscribe for email updates, your email address is registered with WordPress.com through Automattic's Jetpack plugin. Implementation Details This page contains some history on various implementation details of WP-CLI. Bootstrapping WordPress On a normal web request, your web server calls the index.php file in the root of the web directory to bootstrap the WordPress load process: start(); WP-CLI includes a good amount of setup code prior to calling wp-settings.php. Its bootstrapping process is different than a web request in a couple of notable ways. wp-config.php is parsed, and then executed Rather than calling wp-config.php directly, WP-CLI gets the contents of wp-config.php, parses out the require_once ABSPATH . 'wp-settings.php'; statement, and loads the constants into scope with eval(). Read "How WP-CLI loads WordPress" for a narrative on the historical reasons. After that, WP-CLI used a custom wp-settings-cli.php until v0.24.0 [#2278], but parsing wp-config.php was kept for backwards compatibility purposes. See also #1631. WordPress is loaded inside of a function WP-CLI loads WordPress with the WP_CLI::get_runner()->load_wordpress() method, meaning WordPress plugins and themes aren't loaded in global scope. Any global variables used in plugins or themes need to be explicitly globalized. See #2089 for the history of this decision. Once WP_CLI::get_runner()->load_wordpress() calls wp-settings.php, WordPress handles the rest of the bootstrap process. Command Help Text The wp help has been through several incarnations. Since WP-CLI 0.3, it invoked a static help() method in the command class, if it existed. (48a8887d) Since WP-CLI 0.6, it looked for a .1 ROFF file and displayed it using man. The ROFF file was compiled from a corresponding .txt markdown file and from PHPDoc metadata. (#24). Since WP-CLI 0.11, it generates the help text on the fly. (#548) WP_ADMIN Most WP-CLI commands perform administrative actions and they need access to code defined in wp-admin/includes. This code can be loaded on-demand or preemptively. The question is: should the WP_ADMIN constant be set to true or false? Initially, WP-CLI just loaded the wp-admin code and didn't mess with the WP_ADMIN constant at all. Then, it sort of pretended it was doing a front-end page load, for doing integration testing (#69). [1] Then it pretended it was loading wp-admin, to side-step caching plugins (#164). Then it stopped pretending it was loading wp-admin (#352), because we found a better way to side-step caching plugins. [2] [1]: It turned out that the official WordPress testing suite had a better solution: the go_to() method. [2]: The solution was rolling our own wp-settings.php file. Licensing WP-CLI is licensed under the MIT license. This document outlines WP-CLI's licensing expectations for third-party code. Accepting third-party code into the official repository/organization All code accepted into repositories under the official WP-CLI GitHub organization must be compatible with the MIT license. This ensures that WP-CLI can remain freely usable, modifiable, and distributable by anyone. Bundling third-party code When bundling third-party code directly into a WP-CLI package (i.e., copying code into the repository rather than declaring it as a dependency), the code must: Be licensed under an MIT-compatible license Include the original license file or header - The third-party code's license terms must be preserved Maintain copyright notices - Original copyright notices must remain intact Be clearly identified - It should be clear which code is third-party and where it came from When in doubt about whether to bundle third-party code, consider using it as a dependency through Composer instead. Depending on third-party code Third-party packages declared as dependencies (through Composer or other package managers) must be licensed under MIT-compatible licenses. This applies to both: Direct dependencies - Packages explicitly listed in composer.json Transitive dependencies - Dependencies of your dependencies Checking dependency licenses Before adding a new dependency: Check the dependency's LICENSE file or composer.json for license information Verify that all of the dependency's own dependencies are also compatible Use composer show -t to view the dependency tree with license information, or install additional tools like composer/satis to run composer licenses for detailed license auditing Why these requirements? These licensing requirements ensure that: WP-CLI remains free and open - Users can use, modify, and distribute WP-CLI without legal concerns Commercial use is permitted - Companies can use and integrate WP-CLI into their products No license conflicts - All code in the WP-CLI ecosystem is legally compatible Simplicity for users - Users don't need to track multiple license requirements Questions? If you have questions about licensing or need clarification on whether a specific license is compatible, please open an issue or contact the WP-CLI maintainers. Philosophy WP-CLI is the command-line interface for WordPress. It provides commands for actions that can be performed in the WordPress backend (e.g. wp theme activate and wp user create), as well as commands for actions that don't have an equivalent web UI (e.g. wp cron event run, wp search-replace, and wp scaffold child-theme). WP-CLI's guiding principle is to be the fastest and canonical way to manage WordPress: Speed is inherently present in the simplicity of the command-line interface, and the ability to chain multiple commands together into a more complex operation. When functionality ends up in WP-CLI, it should be good enough to become the defacto solution to the problem. "Managing WordPress" is the ever-evolving problem space in which we operate. WP-CLI should always focus on making existing management patterns more efficient. This page contains a list of guidelines that should inform decisions related to scope, command organization and behavior: Good commands are simple, interact with WordPress, and solve one unique problem. When a command implements existing WordPress functionality (e.g. wp export), it should mirror and re-use existing WordPress behavior as much as possible. Doing so ensures it meets the user's assumed expectations of behavior. When a command adds functionality not present in the WordPress admin (e.g. wp search-replace), it should solve one unique problem and interact with WordPress in some way. Good commands are born of true user need; for a new proposed WP-CLI command, there probably should be existing prior art in the ecosystem. If a command provides useful functionality, but it doesn't have anything to do with WordPress, it doesn't belong in WP-CLI. Similarly, an idea for a command is sometimes better implemented as a change to documentation instead. Consistency makes for an enjoyable user experience. Whenever possible, commands should emulate one another with consistent usage behavior, argument names, and documentation. Decisions, not options. WordPress' philosophy states: [The end user is considered first when making implementation decisions]. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration. As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in. It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users. The same principle applies to WP-CLI. In every case, we should first try to improve the default behavior. Options should be added sparingly, only when a solution is required and no other solutions are available. As a rule of thumb, once a command has a half-dozen options or more, it becomes difficult to understand how the command will operate under each condition. Composability is always a good idea. One of the most useful ideas in UNIX was that of pipelines. WP-CLI commands should be composable, i.e. the output from one command should be easily pipe-able to another command. A corollary of this is that commands should be orthogonal, which means that there should be no overlapping functionality between commands. ( wp plugin install --activate is an exception). See Shell Friends for specific examples of how this philosophy is applied. Readability trumps number of keystrokes. Most of the commands in WP-CLI will be used non-interactively, so make the parameter names self-documenting. Don't assume anything. Bundled commands MUST work on any given WordPress install (provided that it's a new enough version), no matter how it's configured and no matter how much data it has. As a corollary, bundled commands should not assume the presence of any plugin or theme. Pull Requests WP-CLI follows a pull request workflow for changes to its code (and documentation). Whether you want to fix a bug or implement a new feature, the process is pretty much the same: Search existing issues; if you can't find anything related to what you want to work on, open a new issue in the appropriate repository so that you can get some initial feedback. Opening an issue before submitting a pull request helps us provide architectural and implementation guidance before you spend too much time on the code. Fork the repository you'd like to modify, either the framework or one of the command packages. See Setting Up for more details on configuring the codebase for development. Create a branch for each issue you'd like to address. Commit your changes. Push the code changes from your local clone to your fork. Open a pull request. It doesn't matter if the code isn't perfect. The idea is to get it reviewed early and iterate on it. Respond to code review feedback in a timely manner, recognizing development is a collaborative process. Once your pull request has passed code review, it will be merged into the default branch and be in the pipeline for the next release. New to WP-CLI commands? You may want to start with the commands cookbook to learn more about how commands work. There are three classes of repos you might want to edit: wp-cli/wp-cli is the framework implementation. wp-cli/scaffold-command is an example of a command implementation. There are many others. wp-cli/handbook contains documentation rendered in the handbook. Expectations When submitting a pull request, there are several expectations to keep in mind. Tests are required Most of the time, we'll ask that functional or unit tests be added to cover the change. If it's a new feature, the pull request needs tests. If it's fixing a bug, the pull request needs tests. See the documentation below for more information on writing and running tests. Follow WordPress Coding Standards While not yet strictly enforced, the WP-CLI project generally follows the WordPress Coding Standards. We may ask you to clean up your pull request if it deviates too much. Please refrain from unnecessary code churn Code refactoring should not be done just because we can. With a years-old codebase, there's an infinite number of best practice, readability, or consistency improvements that could be made. However, engaging on any of them has non-obvious costs: our time and attention, making Git history more difficult to review, etc. Any code changes should have clear and obvious value. Contributions are atomic To make it far easier to merge your code, each pull request should only contain one conceptual change. Keeping contributions atomic keeps the pull request discussion focused on one topic and makes it possible to approve changes on a case-by-case basis. If you submit a pull request with multiple conceptual changes, we'll ask you to resubmit as separate pull requests. Make regular progress on your contribution Through our code review process, we'll work with you to make sure your pull request is ready for merge. But if changes are needed and we haven't heard from you in two weeks, we'll consider the pull request abandoned. Someone else may pick it up and make the changes required. Or it may be closed. If you need to step away for any reason, make a comment on the pull request or the related issue so we can pick things up or put things on hold when needed. Setting up If you haven't submitted a pull request before, you'll want to install WP-CLI for local development. Depending on whether you want to work on a particular command/package or on the entire project as a whole, the process is slightly different. Working on a specific command/package Install Composer if you don't already have it. Clone the git repository of the command/package you want to work on to your local machine. As an example for working on the wp core command: git clone https://github.com/wp-cli/core-command.git Change into the cloned directory: cd core-command Install all Composer dependencies: composer install Verify WP-CLI was installed properly: vendor/bin/wp --info Within this package, you should preferably use vendor/bin/wp to run the command. Just using wp should work as well, but by doing that you might run the command through a different version of the framework and thus get an unexpected result. Working on the project as a whole Install Composer if you don't already have it. Clone the WP-CLI git repository to your local machine: git clone git@github.com:wp-cli/wp-cli.git ~/wp-cli Change into the cloned directory: cd ~/wp-cli. If you are going to work on the core framework itself, fork the repository on GitHub through the web UI and add it as a remote: git remote add fork git@github.com:yourusername/wp-cli.git Install all Composer dependencies: composer install --prefer-source Alias the wp command to your new WP-CLI install: alias wp='~/wp-cli/bin/wp' Verify WP-CLI was installed properly: wp --info Commands bundled with WP-CLI (e.g. wp scaffold plugin) will be editable from the vendor/wp-cli directory (e.g. vendor/wp-cli/scaffold-command). The --prefer-source flag when installing WP-CLI ensures each command is installed as a Git clone, making it easier to commit to. Commands available for standalone installation (e.g. wp dist-archive) can be installed from source (e.g. wp package install git@github.com:wp-cli/dist-archive-command.git). Run wp package path to find the appropriate directory to edit. Importantly, you'll need to fork each repository in order to have a remote to push to. For each repository you want to contribute to: Fork the repository on GitHub through the web UI Add your fork as a remote: $ cd vendor/wp-cli/scaffold-command $ git remote add fork git@github.com:yourusername/scaffold-command.git $ git remote -v origin https://github.com/wp-cli/scaffold-command.git (fetch) origin https://github.com/wp-cli/scaffold-command.git (push) fork git@github.com:yourusername/scaffold-command.git (fetch) fork git@github.com:yourusername/scaffold-command.git (push) Once you've done so, you'll have a fork in your GitHub account and a new remote you can push to. You can then push changes to your fork with git push fork branch-name. Optional: The GitHub CLI ( gh) can help streamline some of these tasks, such as forking repositories and creating pull requests from the command line. Running and writing tests There are three types of automated tests: code style sniffers, implemented using PHPCS functional tests, implemented using Behat unit tests, implemented using PHPUnit Code style sniffers The sniffers ensure that the code adheres to a given code style, to avoid unneeded discussions about less relevant details like spacing or alignments. They also check for known sources of bugs and PHP compatibility problems. To run the sniffs: composer phpcs To fix the errors and warnings that can be automatically fixed: vendor/bin/phpcbf Functional tests WP-CLI uses Behat for functional testing. Functional tests ensure commands work as expected by executing them end-to-end. For a comprehensive guide on writing and running Behat tests, see Writing Behat Tests. Here's a quick example of what a Behat test looks like: Feature: Manage WordPress options Scenario: Read an individual option Given a WP install When I run `wp option get home` Then STDOUT should be: """ https://example.com """ In this example: Feature: documents the scope of the file. Scenario: describes a specific test. Given provides the initial environment for the test. When causes an event to occur. Then asserts what's expected after the event is complete. Creating a test database Before running the functional tests, you'll need a MySQL (or MariaDB) user called wp_cli_test with the password password1 that has full privileges on the MySQL database wp_cli_test. To override these credentials you can make use of the database credentials constants of wp-cli-tests If your user has the correct permissions, the database can also be set up by running composer prepare-tests. This will create the database and the user and configure the necessary privileges. Note that this operation is not needed for every test run, it only needs to be run the first time for the initial setup. Note: If you are using MySQL >= 8.0, you may experience inconsistencies with WP-CLI successfully connecting to the database. MySQL 8.0 changed the default authentication plugin and some clients (such as PHP) do not yet support this change. More information can be found on this blog post. Running the test suite Then, to run the entire test suite: composer behat Or to test a scenario at a specific line: composer behat -- features/core.feature:10 Or to test a single feature: composer behat -- features/core.feature Or to test a single feature with more verbosity: composer behat -- features/core.feature --format pretty To run only the tests that failed during the previous run: composer behat-rerun When writing new tests, to see which step definitions are available: composer behat -- --definitions l More info can be found by using composer behat -- --help. Unit tests The unit test files are in the tests/ directory. To run the unit tests, execute: composer phpunit To run a specific unit test, you can use: composer phpunit -- --filter= Running all tests in one go To run all tests in one go: composer test This will run all the tests that the package is set up to use, based on the presence of the respective configuration files. Each repository is configured to run all of its active tests on every code push. The wp-cli/automated-tests repository runs all tests for all repositories on a regular basis. Finally... Thanks! Hacking on WP-CLI should be fun. If you find any of this hard to figure out, let us know so we can improve our process or documentation! Release Checklist There are two different release checklists available from within the wp-cli/wp-cli repository: Generate a 🚀 Regular Release Checklist - applies to major (2.x.x) and minor (x.1.x) releases. Generate a 🔧 Patch Release Checklist - applies to patch (x.x.1) releases only. As a first step for initiating a release process, the corresponding checklist should be generated and added to the milestone it relates to. Repository Management Package Names Package names for the official wp-cli GitHub organization need to be discussed upfront with the maintainers. Before creating a new repository, it's important to discuss the repository first. This discussion helps establish consensus on what purpose the codebase serves, and where it lives best in the WP-CLI ecosystem. Package names for WP-CLI commands must end with the -command suffix for clarity, and also to distinguish them from the non-command repositories. Before new repositories are created for commands, a decision needs to be made whether the command deserves its own repository or whether it should be included within an existing repository instead. Example: wp-cli/scaffold-package-command. Package Versions Package versions follow the Semantic Versioning Specification (SemVer). In layman's terms for us, this typically means: Patch releases (e.g. 1.0.x) are used for bug fixes, documentation changes, small enhancements, etc. Minor releases (e.g. 1.x.0) are used when a new command is introduced to a package, or a major enhancement is made to an existing command. Major releases (e.g. x.0.0) are used when changes to the framework change the WP-CLI API in a breaking way. Milestones Open milestones usually point to the next version to be released. As the release notes are built using the milestones, both pull requests and issues that are to be merged need to be set to the upcoming milestone, so that these pull requests will be part of the release notes. Labels Labels are an important organizational tool to communicate the state and progress of the work being done. Committers are required to keep these up-to-date. Keeping issues and pull requests accurately labeled helps us make sense of issue tracker usage in aggregate and more easily search closed issues and pull requests for past discussion. Groups Of Labels Labels can be part of a label group, a concept that is applicable to all packages. The actual labels that are available can depend on the actual package, but the groups always have the same semantic role. Command The labels that define what specific command a given issue/pull request is related to are prefixed with command:. Some examples: command:core - Relates to one or more of the subcommands under the wp core parent command. command:cli-check-update - Relates to the wp cli check-update command. command:post-meta-update - Relates to the wp post meta update command. Scope The labels that define what scope the current issue/pull request applies to are prefixed with scope:. Used scopes: scope:bootstrap - Part of the bootstrap process, which loads both WP-CLI as well as WordPress Core. scope:distribution - Part of the distribution process, where the Phar is being built and releases are produced. scope:documentation - Part of the handbook, command reference or inline help. scope:framework - Part of the WP-CLI framework itself, which provides the architecture, API and helper functions to make commands possible. scope:testing - Part of the unit or functional tests. scope:website - Part of the website infrastructure on wp-cli.org or make.wordpress.org. State The labels that define what state a given issue/pull request is in are prefixed with state:. Used states: state:unconfirmed - The bug/problem in the issue could not be replicated yet or might be related to the reporter's environment. state:unsupported - The issue is outside of the scope of a bug report and cannot be supported on GitHub. The reporter should be pointed towards one of the support channels. Required Labels Some labels have a special meaning and/or might be used for automated workflows down the road. These are required across all official packages. Bug The bug label denotes an issue that is a confirmed bug where the code does not produce the expected result. Bugs are specific to unexpected behavior of existing functionality. Functionality perceived to be missing is not a bug, but an enhancement. Upstream Bug The upstream-bug label denotes an issue that is a bug in upstream software (e.g. WordPress core, PHP, etc.) that won't be fixed in WP-CLI. Good First Issue The good-first-issue label denotes an issue that is a good entry point for new contributors wanting to get their feet wet. Good first issues are small in scope and don't require extensive technical expertise or historical project knowledge to get started. Commits No direct commits are to be done against the default ( main/ master) branch of the packages. All code changes need to go through a pull request workflow. Pull Requests All code changes go through a pull request workflow. Every submitted pull request needs to go through a code review, and needs to be approved by at least one of the committers. Merge Pre-Conditions Non-trivial pull requests should be preceded by a related issue that defines the problem to solve and allows for discussion of the most appropriate solution before actually writing code. If a pull request is submitted by one of the committers, the submitter should set the "Reviewers" for that pull request to wp-cli/committers if a general code review is needed, or to one or more specific committer profiles if the expertise of a specific person is needed/wanted. If a pull request is submitted by an external contributor, the committers should be responsive and provide quick feedback to encourage further contributions. Unmergeable Contributions Sometimes, a pull request may not be mergeable, no matter how much additional effort is applied to it (e.g. out of scope, etc.). In these cases, it's best to let the contributor down as softly and firmly as possible, both to encourage future involvement and avoid flame wars. Make sure to: Thank the contributor for their time and effort. Fully explain the reasoning behind the decision to close the pull request. Link to as much supporting documentation as possible. If you'd like a template to follow: Thanks ________ for the time you've spent on this pull request. I'm closing this pull request because ________. To clarify further, ________. For more details, please see ________ and ________. Merge Conditions Apart from needing to be approved, pull requests also need to have their tests in a passing state before they can be merged. When both of these conditions are true, any committer can merge the pull request by: Ensuring that all applicable labels have been set. Ensuring that the correct milestone has been set. Ensuring that the branch is deleted after the merge (if applicable). Adapting the title of the pull-request as needed. The ideal pull request title is one that can be copied and pasted into release notes as is. Once a pull request is merged, the committer should make sure any corresponding issues are also closed and assigned to the correct milestone. Releases WP-CLI Releases WP-CLI releases are scheduled and communicated well in advance by the maintainers. When the release is ready, it is prepared and executed according to the release checklist by one of the maintainers. Package Releases Package releases happen on an as-needed basis and are executed by the maintainers. A package is tagged for a release when: It has a reasonable number of changes that have been sitting for a while (couple weeks or more) and would benefit from landing in the nightly build. It has a substantial enhancement (e.g. a new command) that's worth getting into the nightly build for pre-release validation. Tagging a release should be postponed (for a few to several days) if there's an open pull request that makes sense to include in the release. Package release notes should include the subject of and a link to each merged pull request. It's not necessary to include minor documentation, coding standard, and test suite changes. Feel free to edit the subject for clarity. See wp-cli/scaffold-command v1.0.6 for an example. Importantly, tagging a package release is also an opportunity to perform a final review of product quality: Each merged pull request makes sense to ship, and has sufficient test coverage and documentation. The package's README.md is up-to-date. No breaking changes were introduced, unless explicitly intended. Sometime after a new package version is tagged, the wp-make-coffee bot submits a pull request against wp-cli/wp-cli with the results of composer update. When this pull request is merged, the package release will end up in the WP-CLI nightly build. Tips & Tools GitHub Searches There are a lot of useful ways to search GitHub. These searches can be put into bookmarks or embedded into pages as a link. Here are some examples: Open issues & pull requests across all WP-CLI repositories, sorted by last updated Merged pull requests across all WP-CLI repositories that have no milestone, sorted by last updated Closed issues & pull requests across all WP-CLI repositories that have no label, sorted by last updated Roadmap WP-CLI is released every 3-4 months, typically around the beta period of WordPress's release cycle: Current: v2.12.0 (May 7th, 2025) Patch versions are released on an as-needed basis, usually to address bugs or regressions. The current version of WP-CLI is the only officially supported version. The current longer-term goals of the project are: Improve contributor onboarding by streamlining development environment setup, testing and documentation. Rethink the role of WP-CLI scaffolding as an educational tool and a practical application of best practices. New features are developed as packages first. Doing so enables: Faster feature iteration with less risk. More contribution opportunities. Reduced complexity and maintenance burden for the core project. To suggest new ideas, head on over to the wp-cli/ideas repository. For more details on how WP-CLI releases are produced, please see Philosophy and Governance. For more information about how WP-CLI handles its requirements, please see WP-CLI PHP Requirements Strategy. Security Vulnerability Reporting for WP-CLI The WP-CLI team appreciates security vulnerability reports and takes them seriously. If you believe you have discovered a security vulnerability in WP-CLI, please read this page in full before following our responsible disclosure process. A valid report can be granted a CVE and may be rewarded with a bounty payment via the HackerOne program. Report validity A growing number of the vulnerability reports we receive are not genuine vulnerabilities. They describe behavior that may be technically accurate in isolation but requires an attacker to already possess more power than the reported vulnerability would grant, or that depends on a victim being socially engineered into compromising themselves. Triaging these reports takes up maintainer time that would be better spent elsewhere. What follows is a set of triage maxims borrowed in spirit from Brocards for vulnerability triage by the maintainer of Zizmor, adapted to WP-CLI's threat model. A brocard is a concise legal maxim that captures the essence of a principle. None of these are universally true, and any given report may rebut any of them, but each lets us evaluate a report quickly when it covers a category we routinely decline. Understand WP-CLI's threat model first Most invalid reports we receive share a single root cause: a misunderstanding of who WP-CLI trusts. WP-CLI is a tool that an operator runs from a shell on a server in order to administer a WordPress installation. To run wp at all, you must already be able to execute arbitrary code on that server. It is a tool for people who are already inside the trust boundary. This means the operator running WP-CLI is not a party we must defend against because WP-CLI's job is not to protect the server from the people who administer it. A report only describes a vulnerability if it shows how someone outside that boundary gains something they could not otherwise have. No vulnerability without a threat model A report must explain who the attacker is and what they gain. "This function could behave unexpectedly" or "this input is not sanitized" is not a vulnerability report, it is an observation. Without a plausible attacker who ends up with more access than they began with, there is nothing to fix from a security standpoint (though it may still be a good bug report). The team will decline reports that demonstrate no actual exploit. This may include: An exposed stack trace or error message with no attack vector A "dangerous" code path that no realistic input can reach A theoretical weakness being presented as a concrete one No exploit from the heavens If exploiting the reported behavior requires the attacker to already hold a capability equal to or greater than the one they gain, there is no vulnerability. A common form of this report requires that the attacker can already write files to the target server, and then demonstrates that WP-CLI will trust a malicious file they placed there. An attacker who can write a malicious file to the server has already won, and the WP-CLI team considers this to be true regardless of the form that the malicious file takes. The same applies to a report that requires the attacker to already have access to the database, the filesystem, a server control panel, or a shell, and then frames WP-CLI's normal trust of that environment as the flaw. The user is not their own attacker A vulnerability in the form of "a remote attacker can convince a WP-CLI user to run a malicious command" is not a vulnerability in WP-CLI, it is social engineering. Any command-line tool will do what the person at the terminal tells it to do. WP-CLI cannot, and does not attempt to, defend the operator against their own keystrokes, including input that's obviously malicious or cleverly obfuscated. A broken neighbour is not our vulnerability Some reports are only exploitable on shared hosting where multiple accounts are not properly isolated from one another. This is a failure of isolation in a multi-tenant environment. The classic problem is account A being able to read account B's files or write into a location account B's WP-CLI will read. When the operating system or hosting platform fails to isolate tenants, the vulnerability lives in that misconfiguration, not in WP-CLI. It is expected that WP-CLI can assume that the server enforces safe user and file permissions. Denial of self is not denial of service Reports of denial of service, memory exhaustion, runaway CPU usage, infinite loops, or processes that consume too many resources are, for WP-CLI, generally not security vulnerabilities. If a command consumes too much memory or runs too long, the operator can press Ctrl-C or set a memory or time limit. No privilege boundary is crossed if a weakness results in runaway resource usage. No vulnerability from an unsupported configuration If the behavior can only be triggered under an unusual, unsupported, or deliberately insecure configuration of WordPress, the server, or WP-CLI, the problem lies in that configuration. Examples include reports that depend on: World-writable directories Disabling PHP safeguards Running WP-CLI as root Unusual or malformed settings that no default installation would ever produce No cure worse than the disease When a report identifies real but marginal behavior, the team will weigh the cost of the fix against the risk it removes. This includes weaknesses where the fix would: Break common workflows Remove or restrict a documented feature Impose significant complexity in order to fix a vulnerability that requires implausible preconditions Such fixes may do more harm than the issue they address. Where the downside of fixing such an issue exceeds the vulnerability's impact, the team may instead choose to clearly document the behavior. If your report still stands The above are filters, not walls. If you have read this far and your report still demonstrates that an attacker outside of WP-CLI's trust boundary can gain access they should not have, then please disclose it responsibly and the team will endeavour to handle it accordingly. WordCamp Contributor Day Welcome to WordCamp Contributor Day! We appreciate you sharing your time with WP-CLI. We'd love to help you submit at least one pull request, so we put together this guide to make it as straightforward as possible. We're here to support you however we can. When you submit your pull request, add Related https://github.com/wp-cli/wp-cli/issues/6295 so we can see all pull requests created during the day. We'll give these some special promotion in the next release notes. Your table lead for the day is: thelovekesh A few seasoned WP-CLI contributors are also helping out: Abhishek Sharma, Deepak Kumar Getting Started If you normally use WP-CLI on your web host or via Brew, you're most likely using the Phar executable. The Phar executable is the "built", single-file version of WP-CLI. It's compiled from a couple dozen repositories in the WP-CLI GitHub organization, so modifying WP-CLI requires working amongst those repositories. Before you can work on WP-CLI, you'll need to first make sure you have PHP and a functioning MySQL or MariaDB server. Once those prerequisites are met, install the wp-cli-dev development environment to start contributing: git clone https://github.com/wp-cli/wp-cli-dev cd wp-cli-dev composer install The wp-cli-dev installation process clones all of WP-CLI's repositories to your local machine. After it's complete, you'll be able to make changes in whichever repository you'd like. However, you'll need to fork the repository and add it as a remote in order to push your feature branch. All WP-CLI pull requests are expected to have tests. See running and writing tests for a complete introduction. Suggested Tickets To help you be successful during Contributor Day, we curated a list of reasonably approachable and actionable issues. Feel free to comment directly on the issue if you plan to work on it. We don't usually assign issues, so no need to worry about that. New contributors Add reason for skipping regeneration Better communicate failure to search-replace JSON-serialized URLs Seasoned contributors Add commands to export and import SQLite databases SQLite Compatibility (multiple issues) WP_CLI_PHP ignored even when installing from deb not phar You're obviously welcome to work on any other issue you'd like too! Contributor Day can be a good opportunity to discuss trickier issues and brainstorm approaches. WP-CLI Contributor Badge The WP-CLI Contributor Badge recognizes individuals who have made meaningful contributions to the WP-CLI project. This badge is displayed on a contributor’s WordPress.org profile and highlights their involvement in maintaining and improving WP-CLI. Eligibility criteria You may be eligible for the WP-CLI badge if you have made consistent and valuable contributions, including but not limited to: Submitting or reviewing pull requests Reporting bugs or helping triage issues Significantly improving documentation Participating in WP-CLI Hack Days or Contributor Days Supporting users in WP-CLI-related discussions There is no strict minimum requirement. Contributions are evaluated based on quality, impact, and consistency. Badge assignment process WP-CLI maintainers regularly review contributor activity across all WP-CLI repositories, typically after every release, and award badges to eligible contributors. Note: Please do not ping maintainers about the badges or try to request it yourself. WP-CLI Hack Day Welcome to WP-CLI Hack Day! We appreciate you taking time to contribute to the project. We'd love to help you submit at least one pull request today. Given this goal, you'll likely want to start with something small and attainable. After you've submitted your first pull request for the day, you're welcome to work on something more ambitious. When you submit a pull request during Hack Day, please add Related https://github.com/wp-cli/wp-cli/issues/5935 so we can easily keep track of them. We'll include them in a recap post at the end of the day. We put together this guide to make contributing as straightforward as possible. Please also join the #cli channel in WordPress.org Slack (sign up instructions) to chat with other contributors, for questions, etc. Your leads for the day are: schlessera, danielbachhuber, swissspidy Open Video Sessions During the Hack Day, we’ll have two open video chat sessions: 🕓 02:00-03:00 PST / 05:00-06:00 EST / 09:00-10:00 UTC / 11:00-12:00 CEST / 18:00-19:00 JST 🕓 08:00-09:00 PST / 11:00-12:00 EST / 15:00-16:00 UTC / 17:00-18:00 CEST / 00:00-01:00 JST These sessions are a great opportunity to discuss remaining issues live, chat about the progress we’ve made, and to connect with the community. Feel free to join these to talk through any challenges or share your updates! Getting Started If you normally use WP-CLI on your web host or via Brew, you're most likely using the Phar executable ( wp-cli.phar). This Phar executable file is the "built", singular version of WP-CLI. It is compiled from a couple dozen repositories in the WP-CLI GitHub organization. In order to make code changes to WP-CLI, you'll need to set up the wp-cli-dev development environment on your local machine. Before you can proceed, though, you'll need to make sure you have Composer, PHP, and a functioning MySQL or MariaDB server on your local machine. Once the prerequisites are met, clone the GitHub repository and run the installation process: git clone https://github.com/wp-cli/wp-cli-dev wp-cli-dev cd wp-cli-dev composer install composer prepare-tests The wp-cli-dev installation process clones all of WP-CLI's repositories to your local machine. After the installation process is complete, you can make changes in whichever repository you like. You'll need to fork the repository in order to push your feature branch, however. GitHub's CLI is pretty helpful for this: cd core-command gh repo fork We have started a video tutorial series that you can watch here: WP-CLI Contribution Tutorials. These videos will provide an overview of the packages and then go through setting up the development environment to allow you to run automated tests locally. All WP-CLI pull requests are expected to have tests. Watch a ~10 minute video introduction, or see running and writing tests for the written version. Suggested Tickets To help you be successful during the day, we curated a list of reasonably approachable and actionable issues. Feel free to comment directly on the issue if you plan to work on it. We don't usually assign issues, so no need to worry about that. New contributors Regenerating a single image size (re-)generates auto-scaled big images & auto-rotated images wp plugin update all doesnt display info which plugin is being updated No thumbnail when importing PDF file using media import Allow theme slug renaming Subtheme installation fails after installing main theme, if subtheme was tried first, due to left-behind directory Include more information with wp plugin list Output only matching IDs in db search DB-Check fails if Database requires SSL See issues labeled 'good-first-issue' or issues labeled 'contributor-day' for a broader list. Seasoned contributors Plugin Dependencies Support Set WP_CLI_PACKAGES_DIR in config file Cache wp plugin install from GitHub Improve speed of import when uploads are available locally Introduce a dedicated search-replace url command You're obviously welcome to work on any other issue you'd like too! Bug fixes in particular are very welcome. This day can be a good opportunity to discuss trickier issues and brainstorm approaches. Thank You for Contributing We appreciate your taking the time to participate in the Hack Day and contribute to wp-cli. Have fun, and we look forward to seeing you on Slack!