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
--network flag.
- 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 WP_JSON_Terms_Controller::update_item() and WP_JSON_Users_Controller::update_item().
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.
Other changes
Enhancements:
- Migrate users between sites in one go —
wp user import-csv <file> supports CSV produced by wp user list --format=csv > <file>.
- Use
wp user list --network to list all users in your network.
- All subcommand help docs also include global parameters, to give those global parameters more visibility.
- If
--help flag 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-plugins=<plugin>,<plugin>, the --skip-themes global 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 language improvements: Use wp core language list --fields=language --status=active to 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 --fields parameter for getting specific fields.- Use
wp post update <object-id> to update a post’s content from a <file>.
- Activate all installed plugins at once with
wp plugin activate --all.
wp plugin list now 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 uninstall to wp theme delete, giving greater parity between theme and plugin interfaces.
- Adopted a Debian package build script.
Bug fixes:
- Resolved a nasty file cache collision between
wp core update and wp core download. WP_CLI\CoreUpgrader was renaming ZIP files to .tar.gz, which wp core download would then attempt to use.
- If a file required by
wp-cli.yml or --require is missing, WP-CLI will throw a human-friendly error instead of fataling.
wp cli info runs early to protect from invalid runtime configurations.wp core config will only define WPLANG for WP < 4.0./bin/install-wp-tests.sh fixes: Properly marked executable when scaffolding plugin unit tests; works on older versions of Bash; added support for WP_CORE_DIR environment variable.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
localhost.
- Doesn’t force update check on
wp plugin install to 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
