GithubHelp home page GithubHelp logo

wp-cli / handbook Goto Github PK

View Code? Open in Web Editor NEW
179.0 17.0 309.0 1.75 MB

📖 Complete documentation for WP-CLI

Home Page: https://make.wordpress.org/cli/handbook/

License: MIT License

PHP 92.85% Shell 2.39% Mustache 4.77%
wp-cli documentation wordpress cli handbook documentations docs hacktoberfest

handbook's Introduction

WP-CLI

WP-CLI is the command-line interface for WordPress. You can update plugins, configure multisite installations and much more, without using a web browser.

Ongoing maintenance is made possible by:

The current stable release is version 2.10.0. For announcements, follow @wpcli on Twitter or sign up for email updates. Check out the roadmap for an overview of what's planned for upcoming releases.

Testing Average time to resolve an issue Percentage of issues still open

Quick links: Using | Installing | Support | Extending | Contributing | Credits

Using

WP-CLI provides a command-line interface for many actions you might perform in the WordPress admin. For instance, wp plugin install --activate (doc) lets you install and activate a WordPress plugin:

$ wp plugin install user-switching --activate
Installing User Switching (1.0.9)
Downloading installation package from https://downloads.wordpress.org/plugin/user-switching.1.0.9.zip...
Unpacking the package...
Installing the plugin...
Plugin installed successfully.
Activating 'user-switching'...
Plugin 'user-switching' activated.
Success: Installed 1 of 1 plugins.

WP-CLI also includes commands for many things you can't do in the WordPress admin. For example, wp transient delete --all (doc) lets you delete one or all transients:

$ wp transient delete --all
Success: 34 transients deleted from the database.

For a more complete introduction to using WP-CLI, read the Quick Start guide. Or, catch up with shell friends to learn about helpful command line utilities.

Already feel comfortable with the basics? Jump into the complete list of commands for detailed information on managing themes and plugins, importing and exporting data, performing database search-replace operations and more.

Installing

Downloading the Phar file is our recommended installation method for most users. Should you need, see also our documentation on alternative installation methods (Composer, Homebrew, Docker).

Before installing WP-CLI, please make sure your environment meets the minimum requirements:

  • UNIX-like environment (OS X, Linux, FreeBSD, Cygwin); limited support in Windows environment
  • PHP 5.6 or later
  • WordPress 3.7 or later. Versions older than the latest WordPress release may have degraded functionality

Once you've verified requirements, download the wp-cli.phar file using wget or curl:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

Next, check the Phar file to verify that it's working:

php wp-cli.phar --info

To use WP-CLI from the command line by typing wp, make the file executable and move it to somewhere in your PATH. For example:

chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

If WP-CLI was installed successfully, you should see something like this when you run wp --info:

$ wp --info
OS:     Linux 5.10.60.1-microsoft-standard-WSL2 #1 SMP Wed Aug 25 23:20:18 UTC 2021 x86_64
Shell:  /usr/bin/zsh
PHP binary:     /usr/bin/php8.1
PHP version:    8.1.0
php.ini used:   /etc/php/8.1/cli/php.ini
MySQL binary:   /usr/bin/mysql
MySQL version:  mysql  Ver 8.0.27-0ubuntu0.20.04.1 for Linux on x86_64 ((Ubuntu))
SQL modes:
WP-CLI root dir:        /home/wp-cli/
WP-CLI vendor dir:      /home/wp-cli/vendor
WP_CLI phar path:
WP-CLI packages dir:    /home/wp-cli/.wp-cli/packages/
WP-CLI global config:
WP-CLI project config:  /home/wp-cli/wp-cli.yml
WP-CLI version: 2.10.0

Updating

You can update WP-CLI with wp cli update (doc), or by repeating the installation steps.

If WP-CLI is owned by root or another system user, you'll need to run sudo wp cli update.

Want to live life on the edge? Run wp cli update --nightly to use the latest nightly build of WP-CLI. The nightly build is more or less stable enough for you to use in your development environment, and always includes the latest and greatest WP-CLI features.

Tab completions

WP-CLI also comes with a tab completion script for Bash and ZSH. Just download wp-completion.bash and source it from ~/.bash_profile:

source /FULL/PATH/TO/wp-completion.bash

Don't forget to run source ~/.bash_profile afterwards.

If using zsh for your shell, you may need to load and start bashcompinit before sourcing. Put the following in your .zshrc:

autoload bashcompinit
bashcompinit
source /FULL/PATH/TO/wp-completion.bash

Support

WP-CLI's maintainers and contributors have limited availability to address general support questions. The current version of WP-CLI is the only officially supported version.

When looking for support, please first search for your question in these venues:

If you didn't find an answer in one of the venues above, you can:

  • Join the #cli channel in the WordPress.org Slack to chat with whomever might be available at the time. This option is best for quick questions.
  • Post a new thread in the WordPress.org support forum and tag it 'WP-CLI' so it's seen by the community.

GitHub issues are meant for tracking enhancements to and bugs of existing commands, not general support. Before submitting a bug report, please review our best practices to help ensure your issue is addressed in a timely manner.

Please do not ask support questions on Twitter. Twitter isn't an acceptable venue for support because: 1) it's hard to hold conversations in under 280 characters, and 2) Twitter isn't a place where someone with your same question can search for an answer in a prior conversation.

Remember, libre != gratis; the open source license grants you the freedom to use and modify, but not commitments of other people's time. Please be respectful, and set your expectations accordingly.

Extending

A command is the atomic unit of WP-CLI functionality. wp plugin install (doc) is one command. wp plugin activate (doc) is another.

WP-CLI supports registering any callable class, function, or closure as a command. It reads usage details from the callback's PHPdoc. WP_CLI::add_command() (doc) is used for both internal and third-party command registration.

/**
 * Delete an option from the database.
 *
 * Returns an error if the option didn't exist.
 *
 * ## OPTIONS
 *
 * <key>
 * : Key for the option.
 *
 * ## EXAMPLES
 *
 *     $ wp option delete my_option
 *     Success: Deleted 'my_option' option.
 */
$delete_option_cmd = function( $args ) {
	list( $key ) = $args;

	if ( ! delete_option( $key ) ) {
		WP_CLI::error( "Could not delete '$key' option. Does it exist?" );
	} else {
		WP_CLI::success( "Deleted '$key' option." );
	}
};
WP_CLI::add_command( 'option delete', $delete_option_cmd );

WP-CLI comes with dozens of commands. It's easier than it looks to create a custom WP-CLI command. Read the commands cookbook to learn more. Browse the internal API docs to discover a variety of helpful functions you can use in your custom WP-CLI command.

Contributing

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.

Read through our contributing guidelines in the handbook for a thorough introduction to how you can get involved. Following these guidelines helps to communicate that you respect the time of other contributors on the project. In turn, they’ll do their best to reciprocate that respect when working with you, across timezones and around the world.

Leadership

WP-CLI has one project maintainer: schlessera.

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.

Read the governance document in the handbook for more operational details about the project.

Credits

Besides the libraries defined in composer.json, we have used code or ideas from the following projects:

handbook's People

Contributors

aaemnnosttv avatar akkspros avatar danielbachhuber avatar dz0ny avatar ernilambar avatar gilbitron avatar gitlost avatar hofmannsven avatar jankimoradiya avatar janw-me avatar jaywood avatar jmslbam avatar man4toman avatar miya0001 avatar nielsdeblaauw avatar nishitlangaliya avatar pmbaldha avatar porg avatar rmccue avatar schlessera avatar scribu avatar sejas avatar shashank3105 avatar sidsector9 avatar spicecadet avatar swissspidy avatar szepeviktor avatar terriann avatar thrijith avatar wojsmol avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

handbook's Issues

Warning: strtotime() ... in Cookie.php on line 262

I just updated WP-CLI and saw these odd warnings.

You have version 1.1.0. Would you like to update to 1.2.0? [y/n] y
Downloading from https://github.com/wp-cli/wp-cli/releases/download/v1.2.0/wp-cli-1.2.0.phar...

Warning: strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in phar:///usr/local/bin/wp/vendor/rmccue/requests/library/Requests/Cookie.php on line 262

Warning: strtotime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in phar:///usr/local/bin/wp/vendor/rmccue/requests/library/Requests/Cookie.php on line 262
md5 hash verified: ffa57fd2d992b5329795ba9501ae8085
New version works. Proceeding to replace.
Success: Updated WP-CLI to 1.2.0.

It is minor in the grand scheme of things. Props to another awesome release!

Common Issues Doc - Memory Limit example typo

Regarding the common problem PHP Fatal error: Allowed memory size of 999999 bytes exhausted.

The first example (editing the php.ini file) changes the memory_limit to 512M. However, the second example for setting the memory_limit on the fly temporarily changes it to 256M. For my server, this was not sufficient - I needed to set it to 512M as suggested in the previous example. So, I am thinking this may be a typo in the docs and that those troubleshooting this issue may have more success with 512M.

I can create a pull request for the issue but I'm not 100% I'm not sure if this is something that does need fixing, so I decided to start with creating an issue :)

Repository management

Now that there are multiple people merging pull requests, closing issues and tagging releases, I think it's a good time to codify some repository management standards.

This document should include detail on:

  • Labeling #16
  • Tagging releases / release note format.
  • Milestone usage.
  • Versioning.

Integrating WP Unit Testing in windows

This document assumes that you have already tried setting up WP Unit Testing environment for your project in windows but have stucked somewhere.

The purpose of this discussion is to perfectly set up WP Unit Testing environment in a local project. Followed through https://make.wordpress.org/cli/handbook/plugin-unit-tests/ but it lacks some points when it comes to windows with addition to some general points missing.

First, some commands in wp-cli doesnt work with windows, so use cygwin or alike command line utility.
Cygwin is preferred because its suggested even in Working With Patches – Make WordPress Core.

Before starting, let me suggest that if you fail with running wp scaffold command then update your wp-cli to stable version first (Ex : wp cli update --nightly)

For ease of understanding, I rewrite the points of above mentioned tutorial, such as ...

  1. Generate the plugin test files:

    wp scaffold plugin-tests my-plugin

It would work perfectly when you are running it on WordPress downloaded with wp core download but when you run this command in any local WordPress setup, which is not downloaded from above, it would generate error :

Error: This does not seem to be a WordPress install.
Pass --path=path/to/wordpress or run wp core download.

Which is valid cause its not installed from wp-cli, run the wp core download and it will create src with WordPress in it (The folder structure of core WordPress installation).

Running plugin-tests command can still generate error like ....

Error: 'wp-config.php' not found.
Either create one manually or use wp config create.

Now, running wp config create will create wp-config.php file in src installation.

  1. Initialize the testing environment locally: cd into the plugin directory and run the install script. (You’ll need to already have svn and wget installed.)

bash bin/install-wp-tests.sh wordpress_test root '' localhost latest

bash script does not work directly in windows. In windows10, they have introduced "Windows Subsystem for Linux" but in other versions of windows, you need to do separate work for running bash. Cygwin by default runs the bash scripts.

For running above bash script, not only svn and wget but svn and either wget or curl are required because of the following lines in install-wp-tests.sh script

download() { if [ which curl]; then curl -s "$1" > "$2"; elif [which wget ]; then wget -nv -O "$2" "$1" fi }

Again, which is a linux command not by default in windows, it can be installed as a package. All curl, svn and wget can be installed in windows as packages, but for running bash you need to be depending on third party tools, Cygwin in our case.

Bash script is bound to build wordpress over there right after wordpress-tests-lib because of mkdir -p $WP_CORE_DIR in install-wp-tests.sh file but it sometimes fails because its a tmp folder and so sometimes it depends on whether or not tmp folder is perfectly emptied or not. If in any case WordPress folder does not get created there, then you can set up one manually. The logic is, while running any tests, it runs them against this WordPress in /tmp/wordpress-tests-lib. So finally in your /tmp folder there should be structure like this ...

  1. data
  2. includes
  3. WordPress
  4. wp-tests-config.php file

Finally run phpunit and there you go.....

Hope, above mentioned tutorial helps.

Improve "Submitting a bug report" to clarify on what additional detail can be helpful

From Write the Docs April newsletter:

First up this month, someone asked the channel for a good example of how to document a bug. The community came through with suggestions for a template that includes:

Environment: affected software and versions
Summary in narrative form, such as “While testing feature x, I encountered z.”
Steps to reproduce the bug
Results and impacts, including severity level
Workarounds
Relevant diagnostics

It'd be good to get this worked into https://make.wordpress.org/cli/handbook/bug-reports/

Create a "Troubleshooting Guide"

When something does not work as expected, most users don't really know how to go about diagnosing the issue. We already have a "Common Issues" document, but I think it would be very useful to also have a "Trobuleshooting Guide" document, that explains things like:

  • how plugins & themes can interfere with WP-CLI and how to skip them
  • how config files can interfere with WP-CLI and how to find out which ones are being loaded
  • how third-party commands can interfere with WP-CLI and how to find out which ones are loaded and how to skip them

Create a new WP.org home for /docs/internal-api/

These docs need to move to WordPress.org:

image

Hit list:

  • Write a WP-CLI command to generate markdown docs for internal APIs.
  • Write a WP-CLI command to generate a manifest file of the handbook.
  • Update make/cli to import the manifest file.
  • Set up CloudFlare redirects for internal API docs
  • Finalize formatting of the internal API page.
  • Document how all of this works.

From https://meta.trac.wordpress.org/ticket/2465

Released vs `master` documentation

The handbook is currently being generated against the latest master versions. This causes issues where the handbook documents functionality that has not been released yet, like in wp-cli/media-command#15

We should discuss how to best handle this. I see three general approaches that are commonly being used for such documentation:

  1. Always build handbook against latest released versions only, so that the handbook does not contain stuff that is not generally available yet. This is the easiest approach, and is a safe compromise.

  2. Build two separate versions of the handbook (stable|nightly or similar), that the users can switch to and from as needed. This covers most use cases.

  3. Build the handbook for every released version + master (0.23.0|1.0.0|1.1.0|nightly or similar), that the users can switch from. This is the complete solution that makes sure that even users that rely on legacy versions get reliable documentation.

Pull Requests - Setting up steps

I think the "Setting up" steps in "Pull Requests" should include the initial forking, eg

  1. Fork the WP-CLI repository.
  2. Clone your forked repository to your local machine: git clone https://github.com/<your-name>/wp-cli ~/wp-cli
  3. Install Composer etc...

Also using the "https:" style of request will work for everyone.

Identify best practices for closing a pull request

Sometimes, a pull request submitted by a new contributor needs to be closed for one reason or another. How the committer communicates the closure can strongly influence whether the contributor feels positive or negative about the experience.

We should identify some best practices for closing a pull request and document them in the handbook. I'm undecided as to whether "Code review" or "Repository management" is the best place for this; open to suggestions.

Add documentation for the `--foo[=<bar>]` syntax

If you want to provide a flag that can optionally include a value, the syntax is --foo[=<bar>].

If you want to make that flag with an optional value entirely optional as well, the syntax is [--foo[=<bar>]].

This needs to be documented in the command cookbook.

Revisit "Contributing" document and associated workflows

Now that the project is being split into subcomponents, it'd be good to revisit the "Contributing" document and associated workflows.

On a whole, I think we need one large CONTRIBUTING.md that links to a variety of deeper how-to guides as needed. Our current CONTRIBUTING.md is too shallow, which means the reader quickly is scattered in a variety of directions.

Some specific improvements to make:

  • Open an issue to discuss new features.
  • One logical change per pull request.
  • Pull requests are expected to have tests. Pull requests without tests are a rare exception.

Some inspiration:

Add LICENCE file

Currently the handbook repo does not have any license. I guess MIT should work in this case but I'm not sure as this doc is hosted on make.wordpress.org which may or may not have a policy of having all code in GPL.

Refresh "Governance" document

It's now incorrect in some ways.

  • Reference who has commit access, and the standards they're held to #30
  • Update WP-CLI homepage to link to the Governance document.

Create a dedicated doc for how to write Behat tests

WP-CLI integration test documentation exists in two places:

It would be more user-friendly to have an uberdoc for Behat tests. We could have two sections:

  1. Introduction - Getting started, and writing your first test
  2. Advanced usage - Now that you've written a test, here's how you write steps, etc.

Once this document exists, we can have both existing places link directly to it.

Related https://deliciousbrains.com/writing-functional-tests-wp-cli-packages/

Create a new WP.org home for /commands/

Hit list:

  • Write a WP-CLI command to generate markdown docs for commands.
  • Write a WP-CLI command to generate a manifest file of the commands.
  • Update developer.wp.org to import the manifest file.
  • Create an archive page listing all commands.
  • Set up CloudFlare redirects for commands
  • Finalize formatting of the command page.
  • Document how all of this works.

Related #32

From https://meta.trac.wordpress.org/ticket/2465

Documentation for running tests

Now that the project consists of many sub-components, it's not clear how to (or whether it's necessary to) run all tests for all commands.

Points of note:

  • If a contributor makes a change to a command in a sub-component, is it sufficient to run just the tests for that particular sub-component?
  • If a contributor makes a change to the bootstrap functionality, how can they run the tests for all of the commands to ensure nothing unexpected breaks?
  • The bin/test.sh script that lives in every sub-component command has a dependency on the behat executable being installed globally. It should instead run Behat from the root vendor/bin/behat executable if possible.

Ref: https://make.wordpress.org/cli/handbook/pull-requests/

Related: #17.

Incorrect links in Commands Cookbook page

Several links are incorrect now as we have moved to make site.

Like, current link for documentation standards is https://make.wordpress.org/docs/documentation-standards/

Correct link https://make.wordpress.org/cli/handbook/documentation-standards/

Document the aliases feature on the config page

From Slack:

I've read a lot of articles and watched videos from WCs. Wondering as a hoster with multiple sites, how I would target those installs (spread across different cpanel /home/* directories) to install and activate a plugin. The plugin commands are straightforward, but what I'm not clear on (and don't find in docs) is if I can target those WordPress installs from a global WP-CLI install, and how I would do that. Thanks.

WP-CLI aliases are a good fit for this: wp-cli/wp-cli#2039 (comment)

Our annotated wp-cli.yml file makes them hidden though:

image

We should document aliases in a dedicated sub-section.

Add actual "User Manual"

Right now, the handbook is mostly a reference, with tips and tutorials sprinkled throughout.

Apart from the "Quickstart" guide, there's no real user manual that explains all the concepts for a new user in a linear progression.

I'd like to plan for a real "User Manual" with a clean list of linear chapters that takes new users by the hand and provides a proper introduction that can be read from start to finish.

Repo standards: Labels

We should produce a Repo standards document that has a subsection on labeling. Specifically:

  • What labels each package repository should have.
  • How to determine which labels an issue should receive.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.