What do you wish you had a WP-CLI command for?

At the heart of it, WP-CLI commands enable you to do anything you want with WordPress, faster. Performing some task at the command line almost always yields some (often huge) amount of efficiency gain over the alternative.

For instance, consider the following (from #2523):

Using the theme list command without url parameter shows if a theme is enabled for the network and active in the default site.

If you pass the url of a site of the network, this command shows if a theme is active in that site.

But i can’t find a way to list which themes are inactive in every site of the network so i can safely disable and delete them, and i’d love to have this feature

Without WP-CLI, you’d need to:

  1. Find an intern.
  2. Prepare a spreadsheet of all sites and themes.
  3. Have the intern go through each site to log the active theme on your spreadsheet.
  4. Evaluate the spreadsheet to determine with themes can safely be deleted.

With WP-CLI, you can simply run wp find-unused-themes. Pretty much infinity time savings.

So, what do you wish you had a WP-CLI command for?

Now you have a place to request them. Head over to the new wp-cli/ideas GitHub repo and file issues to your heart’s content.

There’s no such thing as a bad idea. We’ll implement the best, and maintain them as canonical WP-CLI community packages.

But wait, how will you pick which ideas to build?

That’s a great question — I’d love your input on how to decide.

The end goal for the WP-CLI package index is to be a directory of well-maintained, canonical features. Packages will be considered community projects shepherded by one or more maintainers, instead of the domain of a specific author. There’s a two-fold benefit in taking this approach:

  • You (as a WP-CLI package author) will feel less burdened in maintaining your package, because you have supporting resources to help you out.
  • You (as a WP-CLI user) will have greater confidence in using the packages in the package index because you know there’s a small community of maintainers around each of them.

But, we need to work out how we get from 0 to 1 (idea to initial implementation), and then 1 to n (ongoing development and maintenance).

But wait, who’s “we”?

That’s a great question too.

I’m now actively looking for someone to help me run with this vision. They’ll focus on facilitating great community packages: soliciting and vetting ideas, establishing best practices and standards, and supporting package maintainers. The best candidate sweats the little details, and commitment is already a part of their track record.

In the near future, we’ll be looking for people to maintain packages in the directory. Our goal is for maintainership to be a rewarding, enjoyable experience — and for maintainers to extend the same to contributors.

Know anyone who might fit either of these roles? I’d love to hear from you. Email daniel@handbuilt.co or ping ‘danielbachhuber’ on the WordPress Slack.