Welcome to WP-CLI!
WP-CLI is the official command line tool for interacting with and managing your WordPress sites.
WP-CLI is the official command line tool for interacting with and managing your WordPress sites.
WP-CLI welcomes its second maintainer, thanks to the support of our 2017 sponsors.
First, I’d like to formally welcome Alain Schlesser as WP-CLI’s newest co-maintainer. If you’ve been following the project over the last month, you may have noticed him diving deep into WP-CLI’s internals. We’re excited about the infrastructural improvements coming in the next release, and the new features they’ll enable.
Alain is new to the WordPress community, and brings years of experience developing for other platforms, from hobby game development to large enterprise projects in a government environment.
I’m wildly excited about the opportunity to join Daniel and work on WP-CLI. This project represents a special facet of the WordPress ecosystem and comes with a unique set of requirements and challenges. I can’t wait to explore the possibilities!
With Alain joining the project as a co-maintainer, the WP-CLI project is restoring capacity to meet current demands (e.g. support), and ramping up on new feature development and evangelization. We’ve already improved the build time by 33%!
Come say hello to Alain at our new office hours every Tuesday. Office hours start tomorrow, Tuesday, April 4 at 16:00 UTC
Maintaining an open source project requires a substantial, ongoing commitment of time and energy. WP-CLI is a dependable tool loved by thousands because it’s actively maintained, which is made possible by the generosity of its sponsors.
Aaron Jorbin, Anant Shrivastava, Andy Fragen, Austin Ginder, Barry van Someren, Ben Meredith, Ben Welch-Bolen, Bill Christensen, Birgit Pauli-Haack, Bjørn Johansen, Boone Gorges, Carl Hancock, Chuck Reynolds, Craig Martin, Daniel Hüsken, David Herrera, David McDonald, Doruk Fisek, Drew Linsalata, Dwayne McDaniel, Erik Joling, Full Name, Hidetaka Okamoto, Hugh McGuire, Ian Johnson, Jared Atchison, Jason Conroy, Javi, Javier Arnáez, Jeremiah J Terhark, Joel Gaeddert, John Speed, Jonathan Bossenger, Jonathan Daggerhart, Joost de Valk, Joshua Koenig, Kevin Cristiano, Knight Tan, Matt Gross, Matthew Lawrence, Mike Garrett, Miya0001, Ned Zimmerman, Nicholas Duncan, Nick Cernis, Patrick Garman, Per Søderlind, Pippin Williamson, Rachel Baker, Rahul Bansal, Ralf Hortt, required gmbh, Richard Aber, Rick Wiggins, Robert Mathews, Rocket Lift In., Ross Wintle, Ryan Sullivan, Sean Hayes, Simon Blackbourn, Steph Gray, Tadpole Collective, Tanner, Thiana Kitrilakis, Thorsten Ott, Vlad Olaru, WP Bullet, Yash Chandra
There are two issues in the backlog we’d love your input on:
Feel free to weigh in as you see fit.
Have a question about something related to WP-CLI? There are now two places you can go for general help:
#clichannel in the WordPress.org Slack to chat with whomever might be available at the time. This option is best for quick questions.
Want to help others with their use of WP-CLI? Click “Subscribe to this topic tag” to receive email notifications of new forum discussion:
In preparation for the 2017 WordPress Community Summit (“CS”) on June 13th-14th before WordCamp Europe in Paris, France we’ve been asked to provide the following (in summary):
This post serves as a request for input for the above three areas. Note that these three requests are detailed further with some clarifying notes on Make/Summit.
Feel free to ping me privately in Slack if you prefer. I will send a summary of the responses with the Community Summit team on Wednesday, March 1st (as I’ll be offline on Thursday and Friday).
Excited to experiment with a couple new WP-CLI commands?
wp doctor and
wp profile are now available for everyone to install.
wp doctor lets you diagnose problems within WordPress by running a series of checks for symptoms. It includes an API for defining your own diagnosis, as well as writing custom checks.
$ wp @daniel doctor check --all Running checks 100% [============================================================================================] 0:02 / 0:09 +----------------------------+---------+--------------------------------------------------------------------+ | name | status | message | +----------------------------+---------+--------------------------------------------------------------------+ | core-verify-checksums | success | WordPress verifies against its checksums. | | file-eval | success | All 'php' files passed check for 'eval\(.*base64_decode\(.*'. | | autoload-options-size | success | Autoloaded options size (16.25kb) is less than threshold (900kb). | | constant-savequeries-falsy | success | Constant 'SAVEQUERIES' is undefined. | | constant-wp-debug-falsy | success | Constant 'WP_DEBUG' is defined falsy. | | core-update | success | WordPress is at the latest version. | | cron-count | success | Total number of cron jobs is within normal operating expectations. | | cron-duplicates | success | All cron job counts are within normal operating expectations. | | option-blog-public | success | Site is public as expected. | | plugin-active-count | success | Number of active plugins (2) is less than threshold (80). | | plugin-deactivated | success | Less than 40 percent of plugins are deactivated. | | plugin-update | success | Plugins are up to date. | | theme-update | warning | 1 theme has an update available. | +----------------------------+---------+--------------------------------------------------------------------+
wp profile quickly identifies what’s slow with WordPress, by giving you visibility into key I/O indicators.
$ wp @daniel profile stage --fields=stage,time,cache_ratio +------------+---------+-------------+ | stage | time | cache_ratio | +------------+---------+-------------+ | bootstrap | 0.2643s | 80% | | main_query | 0.0186s | 85.71% | | template | 0.0489s | 93.71% | +------------+---------+-------------+ | total (3) | 0.3318s | 86.47% | +------------+---------+-------------+
Both packages are in early stages of development — feedback welcome!
Happy release day!
Today, I’m excited to bring you WP-CLI v1.1.0, chock full of enhancements and bug fixes.
Want to get props in the next release? There are a few projects we’ll be working on:
And, in case you missed it: I’m looking for help maintaining WP-CLI (paid opportunity, commitment of 5-10 hours/week). Know someone who might fit? Email firstname.lastname@example.org or ping ‘danielbachhuber’ on the WordPress Slack.
wp cache *:
wp cache type:
wp (comment|post|user) list:
wp core config:
--forceparameter for overwriting existing
wp core is-installed:
wp_guess_url()when core isn’t installed [#3711]
wp core language install:
translations_api()so that WordPress reports the correct language download file [#3748]
wp core update:
--version=(nightly|trunk), which will download the latest nightly build [#3645]
wp core update-db:
wpmu_upgrade_siteoption for all networks, not just current, to ensure the admin notice is dismissed [#3659]
wp db *:
wp help db importto be run when WordPress has been downloaded, a wp-config.php has been created, but WordPress hasn’t yet been installed [#3780]
wp db cli:
wp db export:
wp media regenerate:
wp plugin install:
wp scaffold plugin:
wp scaffold plugin-tests:
wp scaffold (plugin-tests|theme-tests):
wp scaffold _s:
wp site create:
$pathto form proper path then global
$baseisn’t ‘/’ [#3688]
wp site option list:
wp theme install:
wp theme mod get:
--field=<field>argument for fetching a particular field [#3644]
WP_CLI::runcommand()correctly persists current process’ environment variables [#3683, #3730]
wp-config.phpvariables to local scope too, enabling WordPress to properly change
$table_prefixin multisite [#3695]
Contributors to this release (pull requests, documentation, and package authors): amq, bgeihsgt, danielbachhuber, edpittol, ernilambar, greatislander, inderpreet99, louisremi, lwh, metodiew, migueldemoura, miya0001, mmcev106, nikschavan, ntwb, nylen, ocean90, ramoonus, rosswintle, szepeviktor, trepmal, westonruter
You can browse the full list of resolved issues on Github.
WP-CLI’s long-form documentation has a new shiny home: make.wordpress.org/cli/handbook
Want to suggest an edit?
Click on the “Edit” next to the title to submit your changes via pull request workflow. The documents are tracked in a GitHub repo for easy collaboration. Just like with code changes, documentation contributors receive credit in every WP-CLI release.
Have five minutes to make the documentation better?
At the heart of it, WP-CLI commands enable you to do anything you want with WordPress, faster. Performing some task at the command line almost always yields some (often huge) amount of efficiency gain over the alternative.
For instance, consider the following (from #2523):
theme listcommand without
urlparameter shows if a theme is enabled for the network and active in the default site.
If you pass the
urlof a site of the network, this command shows if a theme is active in that site.
But i can’t find a way to list which themes are inactive in every site of the network so i can safely disable and delete them, and i’d love to have this feature
Without WP-CLI, you’d need to:
With WP-CLI, you can simply run
wp find-unused-themes. Pretty much infinity time savings.
So, what do you wish you had a WP-CLI command for?
There’s no such thing as a bad idea. We’ll implement the best, and maintain them as canonical WP-CLI community packages.
But wait, how will you pick which ideas to build?
That’s a great question — I’d love your input on how to decide.
The end goal for the WP-CLI package index is to be a directory of well-maintained, canonical features. Packages will be considered community projects shepherded by one or more maintainers, instead of the domain of a specific author. There’s a two-fold benefit in taking this approach:
But, we need to work out how we get from 0 to 1 (idea to initial implementation), and then 1 to n (ongoing development and maintenance).
But wait, who’s “we”?
That’s a great question too.
I’m now actively looking for someone to help me run with this vision. They’ll focus on facilitating great community packages: soliciting and vetting ideas, establishing best practices and standards, and supporting package maintainers. The best candidate sweats the little details, and commitment is already a part of their track record.
In the near future, we’ll be looking for people to maintain packages in the directory. Our goal is for maintainership to be a rewarding, enjoyable experience — and for maintainers to extend the same to contributors.
Know anyone who might fit either of these roles? I’d love to hear from you. Email email@example.com or ping ‘danielbachhuber’ on the WordPress Slack.
As announced last week, WP-CLI is now an official WordPress.org project. I consider this the best possible outcome of my efforts trying to identify sustainability for the project over the last year. Frankly, it’s hard to communicate how relieved I am.
But wait, what does that actually mean?
Most of the details are still to be worked out. On a high-level, these are the big changes:
The decision to make WP-CLI an official WordPress project also means there’s a clear path forward for me to invest more of my own time into the WP-CLI roadmap. Concurrent with the transition process over the next couple of months, I want to move forward the conversation of how we realize a future where WP-CLI is the fastest way to do anything with WordPress. If that’s something you’re interested in, stay tuned!
In order to successfully and completely migrate the wp-cli.org website to wordpress.org (and WordPress), it’s important to understand its current form:
These are the core functions needing to be replicated on WordPress.org. Ideally, the work done would be the foundation of where I’d love to see the WP-CLI website go in the future:
Fortunately, Github makes it easy to transfer repositories between organizations. Before we make the switch, we need to dot the i’s and cross the t’s on these core functions:
It’s also worth noting there will be more WP-CLI repositories in the future. Each new feature will be developed as an independent package. In fact, existing features (e.g. search-replace) are going to be split out into separate packages too. We’ll need an organizational structure that can accommodate this growth (let it be github.com/wordpress/wp-search-replace-command or github.com/wp-cli-packages/search-replace-command).
Anything I’ve missed? Have a question about something I didn’t cover? Hit me up with a comment!