Hello 2015! Here’s your first release for the new year.
Update WP-CLI using WP-CLI
We’ve made it even easier to keep WP-CLI up to date. If you’re using the Phar file and it’s writable, you can call
wp cli update to install the latest version.
$ ./wp-cli.0.17.1.phar cli update You have version 0.17.1. Would you like to update to 0.18.0? [y/n] y Downloading from https://github.com/wp-cli/wp-cli/releases/download/v0.18.0/wp-cli.phar... New version works. Proceeding to replace. Success: Updated WP-CLI to 0.18.0
Of course, if you’ve installed WP-CLI via Composer or Git, you should run master to always get the latest and greatest.
Manage post and user terms
WP-CLI supports managing terms associated with posts and users:
$ wp post term add 1 post_tag foo Success: Added term. $ wp post term add 1 post_tag bar Success: Added term. $ wp post term list 1 post_tag +---------+------+------+----------+ | term_id | name | slug | taxonomy | +---------+------+------+----------+ | 4 | bar | bar | post_tag | | 3 | foo | foo | post_tag | +---------+------+------+----------+ $ wp post term remove 1 post_tag foo bar Success: Deleted term.
Consistent behavor for plugin activation and deactivation
We’ve cleaned up the behavior for activating and deactivating plugins:
- If a plugin is already active, it’s allowed to become network active.
- If a plugin is already network active, it’s not allowed to become active.
- Network active plugins must be deactivated with the
- A warning will be thrown when an inactive plugin is attempted to be deactivated.
Previously, the behavior was quite inconsistent — sometimes you’d get errors, sometimes silent success, etc.
What’s coming in 2015
If I may editorialize a bit, I think 2015 could be an interesting year for WP-CLI.
The WP-API project has more overlap than you may think. The task of building a RESTful API for WordPress is also a task of preparing a useful abstraction to interact with WordPress internals. Instead of directly calling
wp_update_post(), the API uses
WP_JSON_Posts_Controller::update_item(), which is a consistent interface with
Similarly, we too have had to invent our own pattern of abstraction for interacting with WordPress internals. It would be nice if we could drop much of our code, and leverage WP-API instead. And, what if
WP_JSON_Controller was the pattern we adopted for listing, getting, creating, updating, or deleting any WordPress primitive, which means that plugins implementing it would automatically have WP-CLI commands?
Plus, I’d think it would be quiet useful to have feature parity between what I can do locally with WP-CLI, and what I can do against a remote site via WP-API.
- Migrate users between sites in one go —
wp user import-csv <file>supports CSV produced by
wp user list --format=csv > <file>.
wp user list --networkto list all users in your network.
- All subcommand help docs also include global parameters, to give those global parameters more visibility.
--helpflag is passed, a command will now show the help screen instead of erroring on invalid parameters. Useful for debugging aforementioned errored parameters.
- Similar to
--skip-themesglobal parameter allows you to skip loading specific themes when using WP-CLI. If you run a hosting company, this can be a useful way to blacklist known problem themes when performing maintenance.
wp core languageimprovements: Use
wp core language list --fields=language --status=activeto get the active language; install and activate a language with
wp core language install <language> --activate; active language can’t be uninstalled.
wp (post|comment|term|user) get <object-id>supports
--fieldsparameter for getting specific fields.
wp post update <object-id>to update a post’s content from a
- Activate all installed plugins at once with
wp plugin activate --all.
wp plugin listnow indicates version numbers for mu plugins when they have properly formatted plugin headers.
- Added support for specifying any version for
wp plugin update <plugin>... --version=<version>. Previously, the parameter only supported ‘dev’.
wp option update <name> <value>will supply a friendly message when the option is already set to the supplied value.
- Added alias from
wp theme uninstallto
wp theme delete, giving greater parity between theme and plugin interfaces.
- Adopted a Debian package build script.
- Resolved a nasty file cache collision between
wp core updateand
wp core download.
WP_CLI\CoreUpgraderwas renaming ZIP files to
wp core downloadwould then attempt to use.
- If a file required by
--requireis missing, WP-CLI will throw a human-friendly error instead of fataling.
wp cli inforuns early to protect from invalid runtime configurations.
wp core configwill only define WPLANG for WP < 4.0.
/bin/install-wp-tests.shfixes: Properly marked executable when scaffolding plugin unit tests; works on older versions of Bash; added support for
wp comment (approve|unapprove)will actually change comment status.
wp_is_mobile()is defined, avoiding fatals in some themes and plugins.
- Windows fixes: disabled colors by default; allows deleting plugins that aren’t in folders (e.g. Hello Dolly).
- Throws an error when trying to get meta on a missing object, instead of silently failing.
- Throws an error when trying to install multisite with subdomains when domain is
- Doesn’t force update check on
wp plugin installto reduce dependency on WordPress.org.
You can browse the full list of resolved issues on Github.
Contributors to this release: viper007bond, boonebgorges, borekb, bparbs, danielbachhuber, here, miya0001, nyordanov, oneumyvakin, ozh, pippinsplugins, rodrigoprimo, spacedmonkey, ntwb, lordspace, szepeviktor, tiagohillebrandt, wturrell