WP-CLI Packages: Supercharge Your WordPress Development

#

I think most developers would agree that WP-CLI (the self-described “command-line interface for WordPress”) is the best thing to happen to WordPress since my-hacks.php. It is my favorite way to use WP Migrate DB Pro, set up new WordPress sites, control WordPress with CRON, manage plugins, quickly test code, and a whole host of other tasks that are quicker and easier to complete via the CLI or a shell script.

“What,” you might ask, “could possibly be better than WP-CLI?”.
“A lot of things…” I would reply, preparing to list off things like

  • dogs
  • cheeseburgers
  • fennec foxes
  • when a caterpillar builds its chrysalis on a broom that you left outside and you know that the next time you have to sweep there will be a beautiful, new monarch butterfly flitting around while you work
  • puppies
  • Bitcoin
  • etc…

But then I might catch myself and realize that your question was probably scoped to WordPress development and related tools so I would cough loudly and continue, “*cough* I mean… Packages… For WP-CLI. WP-CLI Packages”

Free Shipping

The WP-CLI package index is a goldmine of incredibly useful commands. Packages can be installed easily from within WP-CLI with the wp package install [...] command, just like you might install an NPM tool using yarn global add [...].

While WordPress plugins can provide their own commands to a site that they are installed and activated on, packages have the advantage of being available globally, so if you have a bunch of sites running on the same server you can install a package once and use it on every site. Packages can also run before WordPress is loaded, or even in directories where WordPress is not yet installed (like Matt’s great wp-installer package).

Show Me The Goods

There are a ton of great packages in the package index, but here are a few of the ones that I have found to be super useful:

aaemnnosttv/wp-cli-login-command

This package is not just at the top of my list alphabetically, it’s an incredibly useful little tool that I find myself using much more often than I’m proud of. The wp-cli-login-command provides a super easy way to log in to a WordPress site without knowing the password or even changing it. Sure, you could run wp user update --pass=Dr1nkM0r30valtine but that’s the sort of nonsense that got you into this mess in the first place.

Now you can run wp login install --activate (because this package needs to install its companion plugin on the site) and then wp login create admin which will generate a “magic login link” that will automatically log you in as your specified user when you click it.

    > wp login install --activate; wp login create admin
    Success: Companion plugin installed.
    Plugin 'wp-cli-login-server' activated.
    Success: Activated 1 of 1 plugins.
    Success: Magic login link created!
    --------------------------------------------------------
    https://deliciousbrains.dev/f430b776/a25737-a2fd5c-863013
    --------------------------------------------------------
    This link will self-destruct in 15 mins, or as soon as it is used; whichever comes first.

Passwords are for suckers.TM

alleyinteractive/wp-doc-command

The wp-doc-command is an incredibly useful tool for developers when you need a little more information about a WordPress core function than your IDE is willing to show.

Rather than go searching through the codex code reference, you can just pop open your CLI and run wp doc [...] to get the PHPDoc output of pretty much anything in WordPress that’s documented (which is everything).

    > wp doc __return_true
    Documentation for function '__return_true()' in wp-includes/functions.php:4835
    ==============================================================================

      Returns true.
      Useful for returning true to filters easily.

    SINCE
      3.0.0
    SEE
      __return_false()

    RETURN   true
      True.

Super useful, especially for all of the WordPress functions that don’t start with __return_.

binarygary/db-checkpoint

db-checkpoint is another package that does something you could already do by running a few WP-CLI commands or even with WP Migrate DB Pro, but since it’s purpose-built to do this one thing, it just does a way better job.

Here’s the idea: db-checkpoint (actually, intuitively, the command is dbsnap) lets you quickly take a snapshot of your database by running wp dbsnap, after which you can try out a bunch of stupid stuff on your site and then quickly restore it without having to even remember what you named your backup file by running wp dbsnapback. Presto! Nobody will ever know about all of that stuff you messed up!

    > wp dbsnap
    Success: Exported to '/var/www/productionsite.com/wp-content/uploads/checkpoint-storage/secure.20180119-0506.sql'.
    Success: Checkpoint Saved!
    #I'm going to change my site url to get all of the traffic!
    > wp option set siteurl http://google.com
    Success: Updated 'siteurl' option.
    #Just checking to make sure that worked...
    > wp option get siteurl
    http://google.com
    #Oh fork! Why did I think that would ever work!?
    > wp dbsnapback
    This is a destructive operation, are you sure? [y/n] y
    Are you sure you want to reset the 'production-db' database? [y/n] y
    Success: Database reset.
    Success: Imported from '/var/www/productionsite.com/wp-content/uploads/checkpoint-storage/secure.20180119-0506.sql'.
    Success: Checkpoint Restored!
    #Nobody can ever know...

iandunn/wp-cli-rename-db-prefix

The wp-cli-rename-db-prefix package is great for any time that you need to change your table prefix for whatever reason. Maybe you still think that it’s a good security practice to make sure that you’re not using wp_ or maybe you’re just trying to use WP Migrate DB Pro to migrate data to a site that uses a different prefix than your dev site. Changing the table prefix manually is a pain and while there are plugins in the repo that rename the WordPress db table prefix, a package just makes way more sense than a plugin that you install, use once, and then uninstall.

    > wp rename-db-prefix slartibartfast_
    Warning: Use this at your own risk. If something goes wrong, it could break your site. Before running this, make sure to back up your `wp-config.php` file and run `wp db export`.
    Are you sure you want to rename devsite.localhost's database prefix from `wp_` to `slartibartfast_`? [y/n] y
    Success: Successfully renamed database prefix.

For standard installs (multisite admins are on their own here…), the rename-db-prefix command really turns this otherwise annoying task into something that barely requires a second thought.

markri/wp-sec

The wp-sec package is probably something that every WordPress developer should be running regularly on every site they manage, probably with a CRON job that greps the output and emails you when it indicates a vulnerability.

    > wp wp-sec check
    -----------------------------------------------
    Checking core vulnerabilities for version 4.8.5
    -----------------------------------------------
    No known core vulnerabilities found in version 4.8.5
    -------------------------------
    Checking plugin vulnerabilities
    -------------------------------
    Vulnerabilities:
    -----------------------------
    Plugin: wordpress-seo
    Version: 4.9
    Vulnerability: Yoast SEO <= 5.7.1 - Unauthenticated Cross-Site Scripting (XSS)
    CVE's: 2017-16842
    Fixed in: 5.8
    ------------------------------
    Checking theme vulnerabilities
    ------------------------------
    Vulnerabilities:
    No known theme vulnerabilities found
    -----------------------------------------------

Packages Are Dead, Long Live Packages!

Okay, so by now you’re totally on board: you’ve installed all of the packages I talked about, you’re browsing the index for more packages you might be able to use, and you’re excited to hear about all of the new packages that are surely being added to the index on a weekly basis, right?!

Here’s the thing though… The WP-CLI Package index is pretty much dead.

TL;DR:

For installing packages, we won’t have an actual “index” in place, we accept any Composer source (git repository, zip file, path to folder, …) as a package, with the added detail that a package identifier of vendor/package will default to the corresponding GitHub repository.
[…] “Discovery” is then an entirely different problem and will be solved through a separate (potentially third-party) project.

it’s dead

The Package Index is officially deprecated and not currently accepting new packages. There seems to be a plan… to make a plan… to eventually replace it, but other than that we’re currently stuck with what’s currently in the index. New packages can still be installed, albeit a bit more manually by navigating to your package directory (cd $(wp package path)) and installing a package directly with composer, but there is currently no way for new packages to be discovered in a centralized place.

While the index is currently host to quite a few great packages, I really hope that the WP-CLI team makes some moves towards creating a new package index so that new packages can be discovered and current package maintainers have a bit more motivation to keep their projects updated.

Delivery Complete

Long story short: WP-CLI Packages are great and I’d highly recommend browsing the Package Index (even though it’s dead) to find your next invaluable tool. Sure, some of the packages in the index are getting a bit long in the tooth (I even had to remove a few of my recommendations from this post after realizing that they were a bit too broken to recommend), but that doesn’t mean that they’re a total loss. If you find something you like that’s getting a bit buggy, submit a issue or even a PR on the package’s repository.

The best hope we have for a new, improved package index that supports a growing ecosystem of packages is by showing the WP-CLI team and package developers that their packages are being used and an index is necessary.

What are your favorite packages? Do you use any WP-CLI packages that aren’t currently in the package index? Do you have any insights (or just wishful thinking) about the future of the WP-CLI Package Index? Let us know in the comments!

About the Author

Jeff Gould

Jeff is a problem solver at heart who found his way to the web at an early age and never looked back. Before Delicious Brains, Jeff was a freelance web developer specializing in WordPress and front-end development.

  • Hmm. Tried to try some of these out but ran into an error I’m unable to figure out how to solve, right off the bat. This is on a DigitalOcean droplet configured by ServerPilot.io

    ““
    $ wp package install markri/wp-sec

    Installing package markri/wp-sec (dev-master)

    Updating /srv/users/xxxxxxx/.wp-cli/packages/composer.json to require the package…

    Using Composer to install the package…

    Loading composer repositories with package information

    Updating dependencies

    PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 18874368 bytes) in phar:///opt/sp/bin/wp-cli.phar/vendor/composer/composer/src/Composer/DependencyResolver/RuleSet.php on line 90

    Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 18874368 bytes) in phar:///opt/sp/bin/wp-cli.phar/vendor/composer/composer/src/Composer/DependencyResolver/RuleSet.php on line 90
    ““

  • Thanks for chiming in, Daniel! I agree that it’d be best to have commands that are maintained by the community, but doesn’t this limit us to functionality that’s generally considered useful/safe for the bulk of the WP-CLI user base? Or at least functionality that someone has enough time and influence to advocate for?

    I see a repository of unofficial commands as a great place for both innovative and niche commands, not to mention that it’s always going to be easier for developers to work on and release their own code as opposed to getting their ideas accepted by and merged into the much larger machine that WP-CLI has become.

  • Hey Daniel, could you please point that out to Matt Mullenweg? Various WordPress devs have been fiddling around for years with the plugin and theme repositories, but nobody, it or so it seems, has the Cojones to really clean it up. They just keep rearranging the deckchairs while the band plays on. Its so chocked with dead or dying plugins its A) a minefield for new users, and B) a pain in the petutie for everyone. It maybe might not be so bad if they spent a few moments to get it set up where the ‘average user’ could at least search for plugins/themes which are maintained and tested with your version of WordPress. By leaving it focused on their self-centred classifications, and doing so little aimed at helping Joe average find his way around and make a sound decision ~ just to maintain that magic big number ~ many of which are now ‘site or user poison’, is just plain dumb and wrong headed. I congratulate you Sir for being so straight thinking and decisive. But did you, perhaps, ~ by not having a Plan B ~ throw the baby out with the bathwater? Just a thought.