The command line interface for WordPress

This is a minor release, which contains a single change that fixes many issues.

Changelog

Internals:

• don’t set WP_ADMIN to true and don’t fire the 'admin_init' hook.

This is a minor release, which fixes a few regressions.

Changelog

Commands:

• made search-replace work with tables that have reserved column names, such as ‘default’
• made option update work correctly for blog_public
• fixed notice in scaffold post-type
• fixed colorization on wp plugin update-all --dry-run

Internals:

• fixed bug where wp help would not display commands defined in plugins
• fixed synopsis parser bug where arguments with vertical bars would be ignored
• added support for WP_CLI_PHP_ARGS environment variable

You can also browse the list of resolved issues on GitHub.

Contributors to this release: c10b10, jmslbam, scribu.

It’s been two months since the last major release. We didn’t want to wait any longer to show you all the goodies that we packed into this version.

Import content from WXR files

A significant addition in this release is the wp import command, which is the yin to wp export’s yang.

It’s an iteration on Automattic’s WordPress-CLI-Importer.

Install multisite from scratch

Here’s a little puzzle: How do you spin up a multisite install, when you already have a wp-config.php file with all the settings?

Run wp core install and then wp core install-network? No. Use a dummy wp-config.php file and then swap in the real one? Probably not. Learn to play jazz, impress Matt and then ask him to fix the multisite install process? Maybe later.

To trick WordPress into submission, you have to do a zillion little hacks, strewn throughout the loading process. We took care of this dirty work for you. Just run wp core multisite-install.

Inline help

In previous versions, wp help called man internally. Besides not working on Windows, it also had the significant drawback that you had to use a separate tool to compile man pages.

In WP-CLI 0.11, we generate the docs on the fly, using the information from the command PHPDoc.

Support for community packages

Remember how in the previous release we suggested using the installer? If you followed that recommendation, it should be very easy to install community packages now.

Changelog

Commands:

• added wp import command
• added wp core multisite-install command
• renamed wp core install-network to wp core multisite-convert
• added wp network-meta command
• renamed wp blog to wp site
• added --force flag to wp plugin install and wp theme install
• added wp user get subcommand
• added --format=count to list subcommands
• made wp user commands accept both user logins or user IDs.

Internals:

• added support for @when before_wp_load annotation
• added support for apache_modules config key
• show warning if WordPress version is too old
• support passing --require= multiple times
• deprecated WP_CLI::add_man_dir()

You can also browse the full list of resolved issues on GitHub.

Contributors to this release: dangardner, danielbachhuber, eugeneware, jmslbam, johnbillion, MiteshShah, om4james, scribu, twratajczak, Veered.

This is a minor release, mainly meant to fix a dependency issue.

Changelog

Commands:

• when using --format=json, show warning if the value is not a valid JSON string
• updated man page for wp core install-network and other man page fixes

Internals:

• fix required version for php-cli-tools package

You can also browse the list of resolved issues on GitHub.

This is a minor, bugxfix-only release.

Changelog

Commands:

• improved --version handling for wp plugin and wp theme subcommands
• updated man page for wp post get
• improved .travis.xml file generated by wp scaffold plugin-tests

Internals:

• show warning if a URL redirect is attempted while using WP-CLI

You can also browse the list of resolved issues on GitHub.

In the last two and a half months, we’ve added a ton of new features, fixed many bugs and improved our functional test suite.

New installer

You can still install WP-CLI by cloning the git repo, but the preferred method is to use the installer, as described on the front page.

The main reason for using the installer is to be able to leverage the optional Boris package, for an enhanced wp shell experience.

Changelog

Commands:

• added wp scaffold child-theme subcommand
• added wp media import subcommand
• added wp blog empty subcommand
• added wp post get subcommand
• added wp plugin list and wp theme list subcommands
• added --extra-php flag to wp core config subcommand
• added --label option to wp scaffold post-type and wp scaffold taxonomy
• added --verbose flag to wp export command
• added --fields option to all list subcommands
• removed wp home command
• wp search-replace: added --skip_columns option; added --network flag; fixed a lot of bugs
• wp theme install: fixed --version parameter being ignored
• wp core init-tests: create the test database if necessary
• wp db: ignore ~/.my.cnf file when running subcommands
• wp db query: read from STDIN if no parameter is passed

Internals:

• made it possible to call wp from subdirectories
• set WP_ADMIN to true
• improved Cygwin compatibility
• replaced --man flag with --help --gen
• converted --json to --format=json everywhere
• show PHP errors only on STDERR

You can also browse the full list of resolved issues on Github.

Contributors to this release: cyberhobo, daithi-coombes, danielbachhuber, future500, glebis, goldenapples, j3lamp, jmslbam, mwilliamson, om4james, scribu, tlovett1, tolgap, twisty, westonruter.

What’s next?

I foresee a comeback of community commands, but in a better form.

Custom post types and custom taxonomies are the building blocks for advanced functionality. Most of the time, the code for registering them is either copy+pasted from somewhere or it’s saved as a snippet in your text editor.

Now you can do this with WP-CLI, using the wp scaffold command.

Scaffold a custom post type

The following command generates the code for registering the post type and also for customizing the update messages:

wp scaffold post-type zombie

Scaffold a taxonomy

The following command generates the code for registering the taxonomy to the zombie post type:

wp scaffold taxonomy zombie-speed --post_types=zombie

But I only want the registration of the post-type…

Then you can add the --raw flag:

wp scaffold post-type zombie --raw

This will only output the code that will register_post_type() without the init action and the update messages.

But where does the code go?

This is a personal preference. Some ship it within a theme, while others will save it within a plugin. That’s why we have these two flags:

wp scaffold post-type zombie --theme

--theme stores the generated code within your current active theme under a /post-types directory and names a file name zombie.php

wp scaffold post-type zombie --plugin=pluginname

--plugin=plugin-dir-name stores the generated code within the given plugin name.

By default, the code will be output to your terminal (STDOUT) so you could write it to your file of choice:

wp scaffold post-type zombie > ~/project/foo/bar.php

And what about I18n?

Internationalization by gettext can be achieved through the --textdomain parameter:

wp scaffold post-type zombie --textdomain=my-textdomain

By default when using the --theme, the textdomain will be that of your active theme, and if using the --plugin flag, the textdomain will be your plugin name.

Enjoy these commands; we hope it will speed-up and ease your development with WordPress!

Version 0.9.0 is now available.

New distribution method

The PEAR channel has been abandoned, and replaced with a much simpler distribution method: you download a single Phar archive. Done.

Of course, installing via git is still possible and encouraged, if you want to hack on WP-CLI.

The front page has up-to-date information about all the supported installation methods.

Changelog

Commands:

• added wp media regenerate command. props Viper007Bond and benmay for the initial work
• added wp role command
• added wp term command
• added wp post edit
• added --edit flag to wp post create
• added wp scaffold _s
• added wp core init-tests
• made wp scaffold plugin generate files for unit tests. see the blog post
• added --format parameter to wp user list
• made wp help work without a WP install
• added --force flag to wp core download

Internals:

• fixed --path argument getting ignored when running wp core download
• don’t set WP_ADMIN to true
• fixed loading error with some wp-config.php files
• replaced git submodules with Composer dependencies
• improved functional test coverage and set up Travis CI builds

You can also browse the full list of resolved issues.

Contributors to this release: danielbachhuber, drrobotnik, erwanlr, goldenapples, jmslbam, leewillis77, nacin, nb, ocean90, scribu, sebastiaandegeus, taupecat.

A few years ago, I came across a very interesting project by Joseph Scott, called PressFS; it exposed WordPress posts as plain text files on your filesystem. This allowed you to use all your favorite command-line tools to manipulate these posts, including editing their content in your favorite text editor.

With WP-CLI 0.9.0-beta, you can do the same thing:

wp post edit 123

Once you run that command, your $EDITOR will open up, pre-filled with the content of the post with ID 123. After you’ve made your changes and quit the editor, WP-CLI will update the post in the database.

Credit goes to goldenapples for implementing it.

One of the reasons so few people take the time to write unit tests for plugins they author is that it’s a chore to set everything up. Besides installing PHPUnit, you also have to set up the WordPress testing library, as well as the actual plugin tests configuration files.

If you’re running WP-CLI 0.9.0-alpha2 or later, there are commands that make the last two steps significantly easier. See the Plugin Unit Tests wiki page for up-to-date usage info.

You can check out the sample-plugin repo to see what a generated plugin looks like.

A shout-out to the people that contributed to benbalter/wordpress-plugin-tests is in order.