WP-CLI Packages We Can’t Live Without
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.
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!
Source: https://deliciousbrains.com/wordpress-cli-packages-review/
