WP-CLI is the official command line tool for interacting with and managing your WordPress sites.
Need help with something? Please review your available support options.
Want to help make it better? Check out our Contributing guide for an introduction, or “good first issues” for your first pull request.
Just in time for the release of WordPress Core 5.3.0 we have a new release of WP-CLI as well. A team of 37 contributors has collaborated to get 159 pull requests merged.
Let’s go over some of the noteworthy changes in this release. Most of the work went into compatibility fixes, so there’s not many new toys to play around with, unfortunately. As always, you can also skip directly to the detailed changelog if you prefer.
It should be obvious that WP-CLI supports the latest upcoming WordPress Core release, of course. However, there were quite a few changes that went into 5.3 that made it not only difficult to keep WP-CLI working across 5.3 and earlier versions at the same time, but also made it necessary to release WP-CLI in parallel to have a working option available.
The push to support more of the newer PHP features that became available due to the bump to the minimum PHP version of Core introduced changes to function signatures and class interfaces, which required a few adventurous fixes in some cases…
PHP 7.4 is not yet available in a stable release, but we’re slowly coming closer to the planned release date.
There have been quite a few fixes that went into WP-CLI to make sure it works correctly with PHP 7.4 once it’s available. It’s an ongoing process, still, as we’re working towards the first stable version. Tests are running for PHP 7.4 in the background as well for each package. These are still allowed to fail right now, but after this release, they will be switch to break on error.
The core download command now accepts a URL to download a specific ZIP archive with a version of Core to use. This also allows you to use your own custom version easily. Just add the URL and you’re good to go: wp core download https://somesite/build.zip
WP-CLI will properly deal with large images in the way that WP Core 5.3 was improved. It knows about the original source images as well so you can safely rebuild your thumbnails without losing quality.
hosting-companies.md file [#341]hosting-companies.md file [#336]hosting-companies.md file [#334]wp-completion.bash [#391]core download test [#136]core download [#135]install changed to installation [#132]site_id is 1 [#122]db clean get all the tables with prefix [#152]comment spam output [#272]--debug output for the file being processed. [#183]package.json [#225]@aommundsen, @azito122, @beaucollins, @burhandodhy, @connerbw, @derweili, @drzraf, @dz0ny, @felipeelia, @gitlost, @greatislander, @herregroen, @jrfnl, @l3ku, @localheinz, @marksabbath, @marty-crane, @maximejobin, @mcdwayne, @michaelzangl, @mustafauysal, @nxnjz, @nylen, @ocean90, @pdaalder, @raphael-concil, @sagarnasit, @schlessera, @siliconforks, @swissspidy, @tecking, @thrijith, @vladutilie, @wojsmol, @yousan, @zzap
This release v2.3.0 is, as already announced, rather unspectacular. The previous release was very taxing for several reasons, so we lowered the pace for a while to recover.
This version is mainly meant to finally get a few bug fixes out there that were not critical enough to warrant an immediate hotfix release but are nice to have eradicated at one point, nevertheless.
Overall, a team of 36 contributors has collaborated to get 129 pull requests merged. I’ll briefly go over some of the more noteworthy stuff, but as always, you can also skip directly to the detailed changelog if you prefer.
Some cameras and smartphones will automatically tag pictures to denote “which way is up”. This means that you will have these devices show you the pictures you took during your handstand in the correct orientation no matter what, even though the actual picture file is upside down.
The media command now has a new subcommand media fix-orientation that reads these special tags and properly applies them to your images. This way, the images will also be shown with the correct orientation on devices that do not support this tag.
The --skip-tables flag for the search-replace command has learnt a new trick – it now lets you skip a group of tables in one go through wildcards.
You can use wildcards like 'wp_*options' or 'wp_post*' to make your life easier.
Up until now you always had to provide an anchor to attach changes to your wp-config.php to when using the config add command.
You can use this through the special anchor flag --anchor=EOF.
When you’re connecting to your vagrant VMs through WP-CLI’s special-case vagrant SSH connection scheme, you’ll notice that the operations are way faster now, as we’re caching the configuration across calls now.
php7.2-mysql and php7.3-mysql in Debian build [#130]parse_url scheme bug [#5241]vagrant ssh-config [#5235]File_Writer for STDOUT support [#60]load_export_api() public [#59]wp theme get command [#177]strpos(): Empty needle when going through include paths [#149]--skip-copy [#110]media fix-orientation command [#108]--skip-tables parameter [#124]@afragen, @ajoah, @blackfile, @connerbw, @drzraf, @felipeelia, @fernandoherlo, @fuegas, @fullsteamlabs, @gitlost, @greatislander, @herregroen, @hofmannsven, @jrfnl, @l3ku, @localheinz, @maximejobin, @michaelzangl, @MikeWKrystal, @mustafauysal, @ocean90, @ovidiul, @pdaalder, @sagarnasit, @schlessera, @shadyvb, @shashank3105, @siliconforks, @swissspidy, @szepeviktor, @tecking, @thrijith, @vladutilie, @wojsmol, @yognsk, @yousan
Phew, it’s finally here! Although there are not that many new features, we had a lot of work being done behind the scenes, to make future releases smoother. A lot of the processes have been improved, and we’ve managed to squash quite a few bugs while doing so.
A team of 57 contributors has collaborated on this release to get 347 pull requests merged. I’ll briefly go over some of the more noteworthy stuff, but as always, you can also skip directly to the detailed changelog or examine the breaking changes section if you’re impatient.
alias and maintenance-mode.Through the initiative of @jrf, and with the outstanding help from @thrijith, @wojsmol & @williampatton, we now have a WP-CLI code standard that we can enforce.
For any package, you can just run composer phpcs to verify that your code meets the CS requirements. Basic formatting issues can be automatically corrected through vendor/bin/phpcbf (a Composer script will soon follow for that).
The goal of this big effort is to reduce the back & forth on pull requests and thus reduce the maintenance burden. For most pull requests, whitespace issues and code style issues represent the bulk of the time and effort required by the maintainers. With enforced and automated coding standards, everyone saves time and the discussion more often revolves around the actual logic that solves the problem, instead of alignment issues and spacing rules.
This is all pretty fresh, so stay tuned while more extensive documentation and updates to the tooling will follow.
The old wp cli alias has finally grown up and has become a complete CRUD interface for managing your WP-CLI aliases. You can alias list to retrieve your current configuration, alias get to retrieve an individual alias, and alias add|update|delete to make changes.
While experimenting with these commands, please remember that you need to work around the already active global parameters. This is why we had to add a prefix (--set-<flag>) to all the flags that let you configure the aliases. So, updating the SSH connection string for an alias is done through alias update <key> --set-ssh=<ssh>. If you would use --ssh instead to configure it, you’d actually immediately connect to that SSH target instead.
# List alias information.
$ wp cli alias list
---
@all: Run command against every registered alias.
@local:
user: wpcli
path: /Users/wpcli/sites/testsite
# Get alias information.
$ wp cli alias get @dev
ssh: dev@somedeve.env:12345/home/dev/
# Add alias.
$ wp cli alias add prod --set-ssh=login@host --set-path=/path/to/wordpress/install/ --set-user=wpcli
Success: Added '@prod' alias.
# Update alias.
$ wp cli alias update @prod --set-user=newuser --set-path=/new/path/to/wordpress/install/
Success: Updated 'prod' alias.
# Delete alias.
$ wp cli alias delete @prod
Success: Deleted '@prod' alias.WP-CLI now lets you enable or disable the WordPress maintenance mode with the two simple commands maintenance activate and maintenance deactivate. You can query the current status with maintenance status (for humans) or maintenance is-active (for easy shell scripting).
# Activate Maintenance mode.
$ wp maintenance-mode activate
Enabling Maintenance mode...
Success: Activated Maintenance mode.
# Deactivate Maintenance mode.
$ wp maintenance-mode deactivate
Disabling Maintenance mode...
Success: Deactivated Maintenance mode.
# Display Maintenance mode status.
$ wp maintenance-mode status
Maintenance mode is active.
# Get Maintenance mode status for scripting purpose.
$ wp maintenance-mode is-active
$ echo $?
1The eval-file had a small, innocuous tweak. When it encounters a “shebang“, a first line in a file that starts with #!, it will strip that line and try to run the rest of the file through PHP’s eval().
For folks not used to working in Unix shells, that might sound rather useless, but this shebang is actually a construct that your shell understands, and that lets you tell the shell how to execute the file.
As an example, here’s a file that contains such a shebang and actually points to WP-CLI’s eval-file command:
#!/bin/env wp eval-file
<?php
echo get_bloginfo('name');With that file structure, you can now rename that script file to something like blogname and make it executable. It now behaves like any other shell tool, and will use WP-CLI as a shell framework for retrieving the current blog’s name.
Have fun experimenting with this new functionality, and don’t forget to share the more interesting use cases you can think of with the rest of the community!
While going through the code to make it fit for actually enforcing our new WP-CLI coding standard, we decided to rename some of the more internal functions, methods and properties to make the experience more consistent.
Although we took great care to figure out what we could safely rename and what needed to stay intact, there might be some edge cases where people are nevertheless directly coupling to some bit of internal code.
This is mostly relevant if you extend one of the WP-CLI classes to override default behavior.
The test package included a few framework files that were used to make the FeatureContext logic work. However, as wp-cli/wp-cli was a hard requirement for wp-cli/wp-cli-tests anyway, we removed these framework files and had the test package pull them in through the dependency.
In case you were directly coupling your code to these files as they were found in wp-cli/wp-cli-tests (which is unlikely), then you’ll have to change your code to refer to these same files in the wp-cli/wp-cli package. See the pull request for more details.
Serialized data has been displayed very inconsistently, with some commands showing them as is (option list), and some commands unserializing them automatically for display (post meta list).
We’ve changed this so that they all show the values as they are stored, to avoid surprises.
This is a breaking change, however, and if you happened to rely on the automatic unserialization, you’ll be glad to hear that the affected commands now provide an optional --unserialize flag to get back to the old behavior. You can even put this flag into your global config to permanently stick with the old behavior.
Affected commands are: comment meta get|list, network meta get|list, post meta get|list, user meta get|list.
WP_CLI_CS rulesetWP_VERSION=latest to 5.1
dependencies.yml [#74]dependencies.yml file to define auto-updates [#70]WP_CLI_SSH_PRE_CMD is in use [#5197]aliases subcommand for backwards compatibility [#5194]wp_get_table_names() [#5128]array_column() shim, because package is abandoned [#5126]wp-config.php path with env var WP_CONFIG_PATH [#5119]make_progress_bar() [#5112]FileCache::export() not ensuring parent directories exist for $target [#5103]ext-readline to ‘suggest’ instead of a hard requirement [#5102]add_command() to properly reflect the return value [#5099]parse_str_to_argv() regex to be more accurate [#5090]dependencies.yml file to define auto-updates [#5066]WP_CLI::has_config() method [#5063]ISSUE_TEMPLATEfile [#5056]wp config create [#317]backwpup plugin [#315]wp cli info as first environment info [#305]<scheme> part of the --ssh flag [#299]--foo[=<bar>]to command-cookbook.md [#293]WP_CLI_CUSTOM_SHELLenvironment variable [#292].bash_profile to .bashrc [#290]memory_limit[#286]hosting-companies.md [#284]Happy blogging. to Happy publishing. in wp-config.php template [#82]wp.dev with example.com [#115]--force-regex flag [#50]STDIN if --post_content is used [#189]phpunit.xml to phpunit.xml.dist [#252]#! /bin/bash and similar at the beginning of PHP files [#35]__FILE__ and __DIR__constants in eval()‘d code. [#38]--page parameter to the theme search command [#167]LanguagePackUpgrader::download_packagesignature [#82]--show-grant argument to cap list and --grant to cap add[#19]--field=<field> support to listing roles [#17]dependencies.yml to plugin .distignore [#202].deployignore to ignored files in .distignore [#201].distignore [#200]--basic flag [#23].gitattributes file [#12]@abhijitrakas, @afragen, @ajitbohra, @amieiro, @andreamk, @andrewminion-luminfire, @anthony-curtis, @atanas-angelov-dev, @cwales92, @D9Dan, @danielbachhuber, @DavidHickman, @dependencies[bot], @desrosj, @diggy, @emirpprime, @felipeelia, @jankimoradiya, @jbwtech, @jcomack, @jonathanbardo, @jrfnl, @Juberstine, @killua99, @kimdcottrell, @korikori, @kuoko, @kushalraha, @lanresmith, @localheinz, @luc122c, @man4toman, @mkaz, @mrmakadia94, @msaggiorato, @Mte90, @musicaljoeker, @nickdavis, @nishitlangaliya, @Nomafin, @pattonwebz, @rosswintle, @salcode, @shashank3105, @Sidsector9, @spicecadet, @ssnepenthe, @swissspidy, @thrijith, @tomjn, @tyrann0us, @Umang8, @villuorav, @websupporter, @wojsmol, @XedinUnknown
‘Tis the season to celebrate a new release of WP-CLI! 🎄 A total of 39 contributors has collaborated on this release to have a staggering 293 pull requests merged. We’ll go over the main areas now, but you also skip directly to the detailed changelog or ponder over the breaking changes section if you’re impatient.
i18n make-pot command has replace the old make-pot tool in WordPress Core and is now the official translation build tool for the Core. This effort has lead to numerous improvements to make it both more robust and more flexible.
Amongst the more notable changes, it can now parse JavaScript in addition to the PHP files, and together with the new i18n make-json command that lets you produce separate JSON files, you’re all set to make your Gutenberg blocks translatable!
language family of commands got several improvements and fixes. The most notable one is that language plugin|theme update now understands an --all flag, so you can update language packs for all your installed plugins/themes in one go.
# Update the language packs for all plugins.
$ wp language plugin update --all
Updating 'Japanese' translation for Akismet 3.1.11...
Downloading translation from https://downloads.wordpress.org/translation/plugin/akismet/3.1.11/ja.zip...
Translation updated successfully.
Updating 'Japanese' translation for Contact Forms 7 4.2.1...
https://downloads.wordpress.org/translation/plugin/contact-form-7/4.2.1/ja.zip...
Translation updated successfully.
Success: Updated 2/2 translation.--prompt global parameter has now become even more useful. Instead of always prompting for all arguments, it skips those that were already provided, as you would probably already have expected.
One way this can be used is to prefill all arguments that you can remember and then use --prompt to help you with the more arcane flags.
More importantly, though, you can now prefill all the arguments that are already known inside of a script, and then add the --prompt argument to let the script query the remaining information from the user.
cli cache clear will clear the entire cache, whereas cli cache prune will only clear the elements known to be stale. This latter will for example remove all the versions of WP core that you downloaded except for the most recent one.
# Remove all cached files.
$ wp cli cache clear
Success: Cache cleared.
# Remove all cached files except for the newest version of each one.
$ wp cli cache prune
Success: Cache pruned.transient list command. You can search for specific transients or exclude the ones you want to hide. You can even choose whether you want the expiration to be displayed in a human-readable or machine-parseable format.
# List all transients
$ wp transient list
+------+-------+---------------+
| name | value | expiration |
+------+-------+---------------+
| foo | bar | 39 mins |
| foo2 | bar2 | no expiration |
| foo3 | bar2 | expired |
| foo4 | bar4 | 4 hours |
+------+-------+---------------+db size loved the idea of a --human-readable flag like in the transient list command so much that it got its own version. This will always use the unit that is best adapted to convey the information.
# List the size of the database in a human-readable form
$ wp db size --tables --human-readable
+---------+--------+
| Name | Size |
+---------+--------+
| my_site | 117 MB |
+---------+--------+db import command now understands all the flags that the mysql binary does, so that you can get past errors in SQL exports or adapt the result you want to see in your target site.
# Import an SQL export file that contains errors, by
# passing the --force argument to mysql binary.
$ wp db import export-with-errors.sql --force
Success: Imported from 'export-with-errors.sql'.config commands are now smarter. They not only allow you to edit the wp-config.php even on a broken WordPress installation, but you’re also able to retrieve the individual settings in whatever format best fits your scripting needs.
Finally, adding new configuration values or updating existing ones will now only throw errors in the most ambiguous scenarios, while they just work for the majority use cases without the need to explicitly specify a --type.
post exists command. It returns a shell exit code, so you can use it directly in shell conditionals.
if wp post exists 42; then
echo "Skipping post import for ID 42, it already exists."
else
echo "Importing post with ID 42..."
# ...
fireplace-label maintenance command [#17]$args [#5049]ext-posix requirement from Composer file [#5038]--prompt [#5015]composer.json file [#5001]ext-zip as suggested extension [#4998]WP_CLI::runcommand() with launch=false [#4989]wp-config.php [#4984]dirname() instead of .. to locate wp-config.php to match Core behavior [#4963]vendor folder location [#4938]var_export return in WP_CLI::print_value [#4926]cli cache prune & cli cache clear commands [#4787]running-commands-remotely.md to add ~/bin approach [#256]STDOUT PHP notice [#252]transient list method to be consistent with other list commands [#49]transient type generic to include multisite behaviour [#47]wp_using_ext_object_cache() [#45]wp config edit when WP isn’t functional [#71]--format option for config get command [#79]print_value() instead of log() for output of config get [#78]--human-readable parameter to db size command [#124]mysql flags while importing database [#123]db clean to README.md and configuration files [#119]--format & --size_format flags [#118]site meta test requirement to WP 5.1+ [#225]--description flag logic for user create [#217]--force [#188]post exists command [#182]plugin delete <plugin-name> not working if path has a space or & in it [#138].js.map files to improve reliability of JS translations [#103]WP_CLI::success() [#112]i18n make-json command [#109]activate_language() to private [#47]$available_updates is not a array [#62]wp site switch-language [#57]WP_TEST_TAG for RC and beta [#186]post_type_extended.mustache [#184]installation as well as install [#177]block-php.mustache [#176]docker-php-ext-install with sudo -E in CircleCI [#188]SERVER_ADDR for the built-in webserver [#49]This is a big one! 67 awesome contributors have collaborated over 364 pull requests to bring you WP-CLI v2!
Before going over the detailed change log, let’s discuss a few key areas of this update in more detail. There’s also a “Breaking changes” further down in the document.
This is the main change we planned to include with version 2 of WP-CLI. From v2 onwards, the “framework” is a separate package from the “bundle” that is used to build the Phar file you can download. The framework is now contained within the wp-cli/wp-cli package, while the bundling has moved on to the wp-cli/wp-cli-bundle.
Agreed, this does not sound like such a big deal, but in terms of development experience and maintenance effort, it is a tremendous improvement, making almost every future change faster and simpler.
Nothing much, really. Apart from some of the debugging information containing different paths, you won’t see much of a difference. One of the goals was to not disrupt current usage more than necessary. If you only ever download the WP-CLI Phar and use that to control your sites, you should not need to care about this change.
They will rejoice! The framework itself has gotten rid of most of its problematic dependencies. If you compare the dependencies of v1.5.1 with those of v2.0.0, you’ll see that the list is drastically shorter. Also, the most problematic set of the dependencies, the hard requirement on an old version of Symfony, is gone. The only Symfony component we still have (yet) is symfony/finder, as there’s no upper version limit for that one.
Most of the more problematic dependencies actually came from the WP-CLI package manager (wp-cli/package-command). That command is not only optional now, there’s also no valid reason to use it at all when pulling WP-CLI in via Composer directly.
This also means that you will not see WP-CLI automatically pull in all bundled commands automatically. Let’s say, you need the wp-cli/db-command for some maintenance tasks for your site. With v1.5.1, this would have pulled in the entire WP-CLI bundle as a dependency. With v2.0.0, it will only pull in the lean framework as a dependency, nothing more. You’ll end up with a WP-CLI active on your site that contains the commands cli, help (as the two “built-ins”) and db.
As a nice side-benefit, this makes WP-CLI run much faster in such scenarios, as it only loads what is effectively needed for the site. The difference might not seem like much, but depending on how you use in in your scripts, it can make a big difference.
Splitting everything up has provided a few additional perks for developers (see also the next section about the testing improvements). Everything is leaner, and the dependency resolutions are less problematic, as we got rid of that one nasty circular dependency (command requires framework => framework equals bundle => bundle requires command).
However, dependency declarations need to be more explicit now. If you require wp-cli/wp-cli, this will only provide the pure framework. You cannot implicitly rely on any of the bundled commands in that case, you’ll have to explicitly require any additional command you might need.
One of the things that bothered me a lot while maintaining WP-CLI was the fact that the testing infrastructure was “scaffolded” into the individual command packages (just as it is into the third-party commands). This basically means that we copy-pasted the code in there, and if the code needs to change (because of a bug being fixed or an improvement being made), we have to create changes in every single package to overwrite the copy-pasted version of the testing code with an updated one.
Now we have the testing infrastructure abstracted away into a separate package: wp-cli/wp-cli-tests. For this first iteration, it includes out-of-the-box support for PHP linting, PHP Code Sniffer checks (including the WordPress Coding Standards and the PHP Compatibility Checks), PHPUnit unit tests and Behat functional tests. They are set up in such a way that they detect whether they should run, based on config files or test files presence.
A simple composer test will run all of the tests in order. But you can also run them individually, through composer lint|phpcs|phpunit|behat. Adding further configuration flags can be done as well, but you need to remember to prepend them with a double-dash ( --) first, otherwise the arguments will be interpreted by Composer itself.
For the most important tests, the functional Behat tests, you can also define some constants to adapt the environment in which to test. For example, testing against a specific version of WordPress can be done by providing the WP_VERSION constant: WP_VERSION=4.2 composer behat. This constant also understands latest and trunk correctly.
In general, the tests are set up in such a way that you’ll face less differences between what you get locally and what you’ll get inside of the Travis CI checks.
And given that the tests can now be worked on in one central location, we’re already thinking about what our next steps are to further improve them, like letting you easily re-run only the failed scenarios from last run or automatically retrying failures on Travis to make sure it was not a random intermittent timeout or similar.
i18n make-pot
@swissspidy has spent countless hours working on a new command that has now finally made it into the official WP-CLI bundle. We now introduce you to the i18n command family and its first usable subcommand, i18n make-pot.
What started out as an exploration at first is now a robust tool that is already being used in production systems and is even planned to replace the default translation tool bundled with WordPress Core. It supports both PHP and JavaScript, can manipulate and put into shape multiple files and even detected bugs in the original Core tooling.
This can now easily be including in whatever automated tooling you use for your site/plugin/theme development, and should make your translation work much smoother. Here’s a quick rundown of the main features:
A big shoutout to @swissspidy for the fabulous work he did on that command!
'cli_init'
We introduced a new action 'cli_init' that will be triggered by WP-CLI during the 'plugins_loaded' action. This can be used as a conditional trigger for loading WP_CLI specific code, in case you don’t want to use the constants we already provide, for whatever reason.
This being a WordPress action, it adds a bit more flexibility to the process of loading a WP-CLI command, like for example one plugin being able to unhook the commands of another plugin.
config edit
Easily open your wp-config.php in your favorite editor (configured through the EDITOR environment variable). Once you save within that editor, the wp-config.php will be correctly updated.
Note: This works through SSH/vagrant/docker tunnels as well, but keep in mind that it will use the EDITOR of the remote system, which should be something like vim (=> “how to exit the vim editor” 😉).
# Launch system editor to edit wp-config.php file $ wp config edit # Edit wp-config.php file in a specific editor $ EDITOR=vim wp config edit
config shuffle-salts
This refreshes the salts stored in your wp-config.php file, which are cryptographic values used for authentication and other security-related functionality. Regulary refreshing these salts could be considered “security hygiene” for a site.
The command will generate the salts locally if your PHP server environment is cryptographically secure enough to do so, and falls back to the remote wordpress.org API endpoint if not.
# Get new salts for your wp-config.php file $ wp config shuffle-salts Success: Shuffled the salt keys.
db columns
Get a tabular view of the table schema for a given table. It shows you how the individual columns of the table have been defined, which default values they use and what extra functionality might be attached to them.
$ wp db columns wp_posts +-----------------------+---------------------+------+-----+---------------------+----------------+ | Field | Type | Null | Key | Default | Extra | +-----------------------+---------------------+------+-----+---------------------+----------------+ | ID | bigint(20) unsigned | NO | PRI | | auto_increment | | post_author | bigint(20) unsigned | NO | MUL | 0 | | | post_date | datetime | NO | | 0000-00-00 00:00:00 | | | post_date_gmt | datetime | NO | | 0000-00-00 00:00:00 | | | post_content | longtext | NO | | | | | post_title | text | NO | | | | | post_excerpt | text | NO | | | | | post_status | varchar(20) | NO | | publish | | | comment_status | varchar(20) | NO | | open | | | ping_status | varchar(20) | NO | | open | | | post_password | varchar(255) | NO | | | | | post_name | varchar(200) | NO | MUL | | | | to_ping | text | NO | | | | | pinged | text | NO | | | | | post_modified | datetime | NO | | 0000-00-00 00:00:00 | | | post_modified_gmt | datetime | NO | | 0000-00-00 00:00:00 | | | post_content_filtered | longtext | NO | | | | | post_parent | bigint(20) unsigned | NO | MUL | 0 | | | guid | varchar(255) | NO | | | | | menu_order | int(11) | NO | | 0 | | | post_type | varchar(20) | NO | MUL | post | | | post_mime_type | varchar(100) | NO | | | | | comment_count | bigint(20) | NO | | 0 | | +-----------------------+---------------------+------+-----+---------------------+----------------+
db clean
We already had db reset, but that dropped the entire database… which is not a nice thing to do if there’s more than a default WordPress site in there 😱!
The new db clean will only drop the tables that are actually part of the current WordPress installation and leave the rest of the database instance intact.
# Delete all tables that match the current site prefix. $ wp db clean --yes Success: Tables dropped.
site meta
We’ve added CRUD methods add, delete, get, list, patch, pluck and update for the “site meta” entities.
Oh, and while you are wondering… Yes, you are right, WordPress does not have “site meta” entities. But we didn’t lose our minds: WordPress will introduce “site meta”, together with a wp_site_meta table, with its 5.0 version. We just like to be prepared, that’s all… 😜
# Set site meta $ wp site meta set 123 bio "Mary is a WordPress developer." Success: Updated custom field 'bio'. # Get site meta $ wp site meta get 123 bio Mary is a WordPress developer. # Update site meta $ wp site meta update 123 bio "Mary is an awesome WordPress developer." Success: Updated custom field 'bio'. # Delete site meta $ wp site meta delete 123 bio Success: Deleted custom field.
user check-password
You can now let WordPress tell you whether a given password is valid for a specific user. This is NOT an endorsement to build your authentication layer with Bash scripts! But who knows what exotic automation needs the DevOps folks will come up with…
The command will let you know through a shell exit code whether the password was valid or not, so you can use it directly in if conditionals.
# Check whether given credentials are valid; exit status 0 if valid, otherwise 1
$ wp user check-password admin adminpass
$ echo $?
1
# Bash script for checking whether given credentials are valid or not
if ! $(wp user check-password $USER $PASSWORD); then
notify-send "Invalid Credentials";
fi
language plugin and language theme
They both come with the following subcommands: install, update, uninstall, list and is-installed (which was added to core language as well).
You can now fully control all of the language files of your installation individually.
# Install the Dutch theme language pack. $ wp language plugin install hello-dolly nl_NL Success: Language installed. # Uninstall the Dutch theme language pack. $ wp language plugin uninstall hello-dolly nl_NL Success: Language uninstalled. # List installed theme language packages. $ wp language plugin list --status=installed +----------+--------------+-------------+-----------+-----------+---------------------+ | language | english_name | native_name | status | update | updated | +----------+--------------+-------------+-----------+-----------+---------------------+ | nl_NL | Dutch | Nederlands | installed | available | 2016-05-13 08:12:50 | +----------+--------------+-------------+-----------+-----------+---------------------+
db size now knows about ISO size units as welloption list got a new --unserialize flagpost generate can now deal with --post_date_gmt
user update now allows you to --skip-email
eval-file can read from STDIN
plugin uninstall and plugin delete can now act on --all plugins at oncecap list can now --show-grant
cap add , seeing what its list sibling had done, grew a new --grant flagrole list can now print a single --field=<field>
scaffold _s learned the new --woocommerce tricksearch-replace lets you set a --regex-limit
If you have ever contributed to WP-CLI and made a change to a command signature or documentation, you probably had me tell you that you needed to regenerate the README.md as well using the wp scaffold package-readme . --force command. No more!
We have now added a package wp-cli/regenerate-readme that automates this process. It adds both a precommit and a postcommit git hook that collaborate to transparently regenerate the README.md file behind the scenes and then amend your commit to add the required changes automatically.
This has not been deployed to all command packages yet while we still experiment with some of the finer points of its implementation, but you’ll slowly see the annoying “please regenerate README.md kthxbye” reminders from my side disappear and become forgotten artifacts of the past.
The debug output was always a bit sparse for WP-CLI. This is why we took the opportunity of v2 to improve upon it and make it more useful. It will now add debug messages for the hooks that are triggered, or details about how commands are being loaded or deferred. This will be very useful for third-party command developers that ignore why their command is not properly registered.
We’ll make sure to add even more useful debugging information in the future.
Small side note: To make debugging work as early as possible, it is now smart enough to just store all messages until the logger it needs to send them to becomes available. This means you don’t need to worry about the timing here, if the WP_CLI exits for your code, the debugger is good to go!
Here are a few things you need to be aware of when moving from ^v1 to ^v2:
--all flag to plugin uninstall, a breaking change was introduced for consistency reasons. Whereas WP-CLI used to consider uninstalling a non-existent plugin as a “Success: Plugin already uninstalled”, it will now throw an error “Error: No plugin uninstalled”.wp-cli/i18n-command [#9]make-phar test to skip wiki links [#4873]'cli_init' hook during WordPress 'plugins_loaded' action. [#4861]wp-cli/wp-cli to represent the framework only, not the bundle [#4851]—skip-theme tests [#4843]ci/deploy.sh [#4842]bin/wp [#4841]ci/prepare.sh [#4840]wp-completion.bash to v1.5.1 [#4839]search-replace package to fix tests broken due to privacy policy change [#4807]'latest' into version number [#4806]wp cli alias [#4765]--skip-plugins and --skip-themes flags [#4759]README.md to popular installation methods [#4756]ABSPATH defined [#4743]wp_blogmeta table for back compat [#4736]\WP_CLI\Utils\normalize_path function. Using it for ABSPATH constant. [#4718]@require-php-5.4 in bootstrap test. [#4716]pre-commit hook in auto-composer-update [#4711]wp cli info” [#4702]: from cli update info check. [#4697]pre-commit PHPCS verification [#4696]get_sites_by_path change. [#4695]uniq_id() when extracting file from Phar [#4692]pre-commit hook. [#4622]wp cli info [#4613]brew [#236]optimize WP CLI command of the WP-Optimize Plugin [#231]updraftplus WP CLI command [#228]LICENSE file to the repo [#224]wp-cli/ideas repo [#223]WP_CLI_PHP_ARGS in WP-CLI config document [#221]wp-config.php as a common issue. [#212]WP_CLI_PHP to Environment variables [#211]pt_BR translation [#311]LICENSE file to the repo [#309]http to https in all wp-cli.org links. [#305]^1.2.1 [#53]remove() operation [#52]config edit command [#48]file_put_contents() writes to the wp-config.php path [#63]shuffle-salts command [#62]WP_CACHE_KEY_SALT [#59]wp-cli/wp-cli [#73]db columns command [#100]wp_blogmeta table [#94]db clean command [#93]--column-statistics=0 to mysqldump command [#105]db size [#104]--user_email=<user-email> argument [#173]latest into actual version number [#171]site meta sub-command [#159]--unserialize flag to option list command [#156]--from-post=<post_id> flag to create duplicate posts [#154]user check-password subcommand [#144]--post_date_gmt in post generate [#184]--skip-email flag for wp user update [#155]theme mod list [#100]README.md and test suite prior to v1.1.10 release. [#89]modern-wordpress redirect [#85]--all flag for plugin uninstall command [#84]--all flag to plugin delete [#103]PhpFunctionsScanner extensible [#62]__invoke() [#60]--headers parameter [#58]X-Generator header to POT file [#57]@when before_wp_load to command namespace [#42]exclude option to JsCodeExtractor [#37]download_url() in language pack upgrader [#41]is-installed command to check if a given language is installed [#36]language core update --dry-run message [#32]language plugin and language theme command. [#29]ghostscript/imagick install and fix bmp name in regenerate test. [#69]media regenerate/import. [#62]composer.json file cannot be retrieved [#78]test-command to wp-cli-test Github organization [#66]prompt() [#129]$msg parameter to cli\Progress\Bar::tick() [#126]--show-grant argument to wp cap list and --grant to wp cap add [#19]--field=<field> support to listing roles [#17]scaffold block to create index.js [#142]tests/test-sample.php via the phpunit.xml.dist file [#134]sed -i option on MacOS [#132]$WP_TESTS_DIR on MacOS [#131]phpunit 6.5.6 for PHP 7.2 to get around core test incompat. [#125]'add_new_item' label [#163]--woocommerce flag to scaffold _s command [#159]'wp-blocks' from style dependency [#151]function_exists() check to block PHP template [#147]--regex-limit logic [#70]--regex-limit option. [#62]Here’s the complete list of the fantastic folks that have helped make this happen:
@2020media, @abhijitrakas, @ajitbohra, @alpipego, @austinginder, @benlk, @BhargavBhandari90, @burhandodhy, @chesio, @CodeProKid, @danielbachhuber, @drzraf, @emirpprime, @ericgopak, @erlendeide, @felicianotech, @felipeelia, @fumikito, @GaryJones, @ghost, @gitlost, @greatislander, @JanVoracek, @janw-oostendorp, @javorszky, @jblz, @jmichaelward, @johnbillion, @josephfusco, @kirtangajjar, @kshaner, @lalaithan, @lf-jeremy, @libertamohamed, @marcovalloni, @marksabbath, @miya0001, @MoisesMN, @montu1996, @NicktheGeek, @ocean90, @pdaalder, @pekapl, @pixolin, @pjeby, @pmbaldha, @ptrkcsk, @ryanjbonnell, @sagarnasit, @salcode, @sasagar, @schlessera, @spacedmonkey, @spicecadet, @stevegrunwell, @strandtc, @svenkaptein, @swissspidy, @terriann, @thrijith, @tiagohillebrandt, @tomjn, @torounit, @wojsmol, @wp-make-coffee, @yousan, @zipofar
A big thank you to all involved! ❤️
Starting from May 31st, 2018 (from WP-CLI version 1.5.1 onwards), the GPG key that is used to sign the releases has changed.
Here’s the new public key for signed releases:
-----BEGIN PGP PUBLIC KEY BLOCK----- mQENBFsQEBkBCADfGAhxQ71XaIk31SjD8dNH3uVNtPh/2SIIhYbObMvEG6uoMucP t3jCsnkh/veKBkJ+HJ/XcARGoFYdaCZo5PTORBWOwHmeWPbu7aiAM4v3EKPc8wZP jabtEejwZrRFlSlAu5YL25ldz5KNgvGOBdje9jUi2iovQ4lfjMEuH2sXhmDQPbDW 22Fb2xinvmlnyf5kJn9ADiWm6VEnaNvaL96TCC1iUrMJmYI0m29j2sVbKJIq8ZBO CgtY4llPC7QskWw8VXEAq2WnQeZMVLqxOSoRDy/qUvw0RR+DfiXsrHjBxAH4uvHK zUdnMl1Qbh2A/rfcsIaJubXg5pUXwF7TCvSPABEBAAG0JVdQLUNMSSBSZWxlYXNl cyA8cmVsZWFzZXNAd3AtY2xpLm9yZz6JAU4EEwEIADgCGwMFCwkIBwIGFQgJCgsC BBYCAwECHgECF4AWIQRjr3qhUGfAVhb93YijoujyJvC8BgUCWxAQ7AAKCRCjoujy JvC8BmYTCACPEYQr89U/H/iQcI012UaOSLYLx+Qj9oA7p9gv2mZSBHNSijzhnizo QBEg7q7BXF8B8UqL9ZhUWfG9PiR8kkFbBN1sIY0RM5cFltb3cJthVH4ZV8SUiGW6 zIOd8m5JXVnekmZyJFpufxDHms6F3Z2RNUbdZSp2Mj+5p/a4GtJhfGGpfYBbXOxG gdx5dmipjlxfP5M3YL4QCJoySB+sY92de5b3S3tqmj7ldb/GRvN/7XjoMDwbRso6 jrhGtk8TjtAV0l/VdjebpI6zivrDLYDQq5vwi6hGPl7k88ElU47vaJiJX5yXaJ/k LFQ3g8raFQq69nqcDjJLGds+Y+lAXrtzuQENBFsQEBkBCAC9ZUHiXbBLvCejMXKK vFpKaVsovI6RBU8l0sC+00yvpP+TJmRXracnesTqHyTlhAUMhpbFvG0mBMBdROt5 IPRZ2S9JdJKZFVqO7Nop0elO8wUe6rsEHisUbEP49BcqDHGxfEnB/MubnJO1hHEH 1ftnZBEQW3jNagOTikki9675qF4ONvaSeCY9DkHa4lbau24SzePvtWuxYGsdX+Jf ikFxq8N2ArPlSoVv/DKEbl5dgz1hYFJ9qBKoXSbaKk1TxZ4bA8nxcznZHS+8Lirv tEjB8Z68Hz+pXIFJBbchC/FMatZC2hjFobedc4dT3nxf5iiH9XsHI5bqp3UEsPlx 8LP5ABEBAAGJATYEGAEIACACGwwWIQRjr3qhUGfAVhb93YijoujyJvC8BgUCWxAR IQAKCRCjoujyJvC8BhGMCACkNhkshrOYDRoOwny8m1mI2nSIU0KnjEruaeAXrY2T 5VHNfLkTX3wD2HYO97r1CvUNBUWpmTwSicK0Z6TCDp4A9Oi+z5CA/5zBT/iydC6E czNAPUehdLKka9Qs0vrVq22S0dDiA4xXZUvQpoo8VUKlvau9igF98mbd56U89s3L gg7O72A/4x7rhDO0Q+U8SIBJtFmEHIcu6gHkooQW3d7opHKCjbnyqxDQ/iUY3b8o n75TXnDJWbjCFTiTMyVTeyQfK0Us8FbJNXhMMagalRQu/sBH56S7Cg2OLciQB1B2 sLbhbfYDXYriI/OGVIPvCEIH6FX4+KiFy7RS+0JthI0R =fQDM -----END PGP PUBLIC KEY BLOCK-----
You can find the above current (as well as the old) key in the README.md file of the wp-cli/builds repository, as well as in the form of a downloadable file in that same repository: wp-cli/builds/wp-cli.pgp.
The new key is configured to be the following user:
WP-CLI Releases (releases@wp-cli.org)
The new key will not expire.
In case you have problems with using this key, please open an issue in wp-cli/wp-cli.
A new release is upon us!
We’re excited to bring you WP-CLI v1.5.1, an intermediary bugfix release with a total of 52 merged pull requests since v1.5.0 in January 2018.
This is a bugfix release, which means that you shouldn’t expect major feature enhancements. We’re working hard on v2.0.0 which is planned for the summer, and all new features will have to wait for that big one.
Yes, I just said not to expect any new features. However, a small number of features managed to sneak into this release nevertheless.
The config command now has a new config edit function that opens the wp-config.php file in your favorite editor for easy changes. You can configure the editor to be used through the EDITOR environment variable [#48].
Although WordPress is able to have a capability be set to false, to effectively mean an explicit “deny” of that capability, WP-CLI did not yet show that distinction. It only let you know that the capability was defined, but not whether it was negated, giving the false impression of it being “allowed” instead.
This has now changed, and you can get a complete picture of how the capabilities are set by adding the --show-grant to the cap list command [#19].
Breaking change: Note that the default behavior of cap list has slightly changed because of that. Whereas the previous version showed a capability set to false alongside the normal capabilities, a simple cap list without the new --show-grant flag will now hide the capabilities that are set to false, effectively returning only the capabilities that are actually “granted”.
Framework
proc_(open|close) aren’t available [#4758]
tar output [#4674]
phpunit extractor, glob, behat tests [#4672]
phpunit PHP directive tests to behat [#4675]
phpcs against PHP files on pre-commit hook [#4755]
Commands
plugin verify-checksums
config
$n and \\n sequences in preg_replace() values [wp-cli-transformer #3]package
scaffold block
scaffold plugin
tests/test-sample.php via the phpunit.xml.dist file [#134]scaffold plugin-tests | theme-tests
search-replace
Contributors to this release (15 total)
danielbachhuber, emirpprime, ericgopak, felicianotech, gitlost, johnbillion, kshaner, lalaithan, pdaalder, ptrkcsk, salcode, schlessera, stevegrunwell, thrijith, torounit
It’s release day again!
We’re excited to bring you WP-CLI v1.5.0, with a total of 279 merged pull requests since v1.4.1 in November 2017.
This release was led by the tireless Martin Burke (@gitlost), who made sure no bug went unsquashed and no edge case untested.
embed family of commands.WP-CLI can now verify the integrity of your installed plugins through the new plugin verify-checksums command (in addition to the already existing core verify-checksums command). [#15], [#26]
# Verify the files of all installed plugins against their official checksums.
$ wp plugin verify-checksums --all
+-------------+---------------+-------------------------+
| plugin_name | file | message |
+-------------+---------------+-------------------------+
| gutenberg | backdoor.php | File was added |
| gutenberg | gutenberg.php | Checksum does not match |
+-------------+---------------+-------------------------+
Error: Only verified 1 of 2 plugins (1 failed).
Note: This is a first iteration on this functionality, and it still comes with a few limitations:
Please keep these limitations in mind when you plan on using this new command.
As we will further iterate on this project to allow verification of all free themes from the themes repository, and later hopefully also third-party plugins/themes, we welcome any and all feedback to the current implementation.
Managing your wp-config.php file just got a whole lot easier! Not only did we improve the config get and included both a config has and a filterable config list command… No, we finally bring you full WordPress Config file manipulation with the new config set and config delete commands. [#42], [#44]
# Get the table_prefix as defined in wp-config.php file.
$ wp config get table_prefix
wp_
# Check whether the DB_PASSWORD constant exists in the wp-config.php file.
$ wp config has DB_PASSWORD
(return exit code)
# List only database user and password from wp-config.php file.
$ wp config list DB_USER DB_PASSWORD --strict
+-------------+-------+----------+
| key | value | type |
+-------------+-------+----------+
| DB_USER | root | constant |
| DB_PASSWORD | root | constant |
+-------------+-------+----------+
Big thanks to @fjarrett for the awesome work on the wp-cli/wp-config-transformer package that powers the changes to wp-config.php.
The new embed command allows you to inspect and manipulate the oEmbed object, for instance you can clear the cached values for a particular post with
$ wp embed cache clear 123
Success: Cleared oEmbed cache.
or reset the cached values with
$ wp embed cache trigger 123
Success: Caching triggered!
You can find out what the embed HTML is for a URL with fetch:
$ wp embed fetch https://www.youtube.com/watch?v=dQw4w9WgXcQ
[youtube https://www.youtube.com/watch?v=dQw4w9WgXcQ?feature=oembed&w=525&h=295]
or look at exactly what the provider is returning by using the --raw option:
$ wp embed fetch https://www.youtube.com/watch?v=dQw4w9WgXcQ --raw
{"height":295,"thumbnail_height":360,"provider_name":"YouTube","provider_url":"https:\/\/www.youtube.com\/","author_name":"RickAstleyVEVO","width":525,"version":"1.0","thumbnail_width":480,"author_url":"https:\/\/www.youtube.com\/user\/RickAstleyVEVO","html":"<iframe width=\"525\" height=\"295\" src=\"https:\/\/www.youtube.com\/embed\/dQw4w9WgXcQ?feature=oembed\" frameborder=\"0\" allow=\"autoplay; encrypted-media\" allowfullscreen><\/iframe>","title":"Rick Astley - Never Gonna Give You Up","thumbnail_url":"https:\/\/i.ytimg.com\/vi\/dQw4w9WgXcQ\/hqdefault.jpg","type":"video"}
And lots more!
The --meta_input option of the post create and post update commands now accepts JSON-formatted arrays, so you can add or update your post and its meta in one go:
$ wp post create --post_title='Title' --post_content='Content.' --meta_input='{"key1":"value1","key2":"value2"}
Success: Created post 123.
A great time saver, as you’d previously have to run three separate commands to get the same result.
This rather innocuous change means we can finally accept associative arrays as parameter arguments, through the use of this JSON syntax. The --meta_input parameter is probably just the first of many more to come. Let us know if you can think of other potential use cases for this syntax.
Backward Compatibility breaks
Please note that a framework change [#4624] alters the behavior of table filter arguments to the db search, db tables and search-replace commands.
The table filter arguments now:
wpdb tables when given a table filter and not given the --all-tables-with-prefix or the --all-tables option.--scope option when given the --network option.Also note that option list no longer shows transients by default [#127].
New and notable
user reset-password: Resets a user’s password [#119].Command improvements
cli info:
core download:
'http://' to nightly build [#44].core update:
core verify-checksums
wp- are included in WordPress root [#28].db *:
after_wp_config_load hook for early invocation of db commands [#57].db check/cli/create/drop/export/import/optimize/query/repair/reset:
--dbuser and --dbpass options to all the heightened privilege commands, and extra arguments option to check, optimize and repair [#75].db search:
db size:
db tables:
export:
--with_attachments option to force including attachments when --post__in has been specified. [#16].media image-size:
media regenerate:
option get:
option list:
package *:
package browse/list:
package install/uninstall:
composer.json on memory limit error [#64].package install:
plugin install:
post create/update:
post create:
--post_category and checks if incorrect ids or slugs given [#129].post delete:
post generate:
post_title [#94].scaffold block:
style.css, supports latest supportsHtml API, WordPress Coding Standards fixes [#107].scaffold child-theme:
scaffold plugin:
scaffold plugin-tests:
scaffold post-type:
scaffold taxonomy:
scaffold theme-tests:
tests/bootstrap.php to make sure theme’s functions.php gets loaded [#116].search-replace:
--skip-tables=<tables> argument to exclude specific tables [#48].--report-change-only [#54].user remove-caps:
Framework enhancements
@when to override class @when [#4458].get_site_url() without set_url_scheme() [#4473].after_wp_config_load hook (used to invoke wp db * early) [#4488].vagrant ssh-config [#4495].php7.1-mysql in Debian build [#4511].'longdesc' as command argument when registering a command [#4513], [#4636].wp cache flush and wp search-replace on multisite even when site isn’t found [#4527].'sitecategories' table unless global terms are enabled [#4552].make_progress_bar() [#4603].Utils\esc_like() polyfill of wpdb version [#4612].wp_get_table_names() (see Backward Compatibility breaks above) [#4624].Contributors to this release (39 total)
ahmadawais, BhargavBhandari90, danielbachhuber, davidbhayes, DrewAPicture, drzraf, ecotechie, emgk, eriktorsner, fjarrett, gitlost, grantpalin, gziolo, inetbiz, kirtangajjar, LC43, lukecav, marcochiesi, marksabbath, miya0001, mm-pagely, neonardo1, ntwb, ocean90, playmono, rkialashaki, runofthemill, ryotsun, sagarprajapati, schlessera, Shelob9, ssnepenthe, swissspidy, szepeviktor, terriann, thrijith, vbaranovskiy-plesk, vigilanteweb, websupporter