ideas
ideas copied to clipboard
wp-cli
Third-party command discovery
As the package index has now been deprecated, we should start the discussion about whether we want a new discovery mechanism, and how that could work.
As the installation of packages has now been split off of the discovery mechanism, discovery can just as well be something entirely external to WP-CLI. It could be a full-blown package repository, but it could just as well be a specialized search engine.
That will only cover commands stored on GitHub. Ideally, we'd have a discovery mechanism for finding both stand-alone commands as well as commands included with plugins, no matter where the source files are stored.
as well as commands included with plugins
Oh, this is an interesting idea.
as well as commands included with plugins
Oh, this is an interesting idea.
For plugin commands, maybe the more appropriate place would be the WordPress.org plugin repo. It'd be cool to work out a way for plugin authors to easily incorporate that detail.
Yes, that might be feasible. Add a meta tag to the plugin file header, with something like:
commands: event list, event get, ...
Another approach would be to scan the plugin files for WP_CLI::add_command() calls.
How about Packagist?
https://packagist.org/packages/wp-cli/core-command?query=&type=wp-cli-package
Hi, I just found out about the fact that wp package is deprecated by running wp package browse.
Would it be possible to include this information in the docs? https://developer.wordpress.org/cli/commands/package/
Although the package index will remain in place for backward compatibility reasons, it has been deprecated and will not be updated further. Please refer to https://github.com/wp-cli/ideas/issues/51 to read about its potential replacement.
Was a replacement ever decided on? OR if not, can we resurface the discussion?
Was a replacement ever decided on?
It was not.
OR if not, can we resurface the discussion?
Sure, how would you suggest moving the discussion forward?
Sure, how would you suggest moving the discussion forward?
Thanks for the response, @danielbachhuber !
There are several good suggestions above, but I've been unable to find (so far) why none of them were selected as appropriate. I've read the blog post and it seems that a packagist-like solution (Satis, wpackagist, etc) would solve both the central search location, and discoverability issues.
They do not address discovering cli packages that are bundled into plugins/themes; HOWEVER, one could argue in those situations the cli functionality is worthless without the plugin/theme it is bundled into.
IMO, I don't think plugin/theme cli discoverability should be a road-block for a centralized wp-cli package repository. I'm curious why none of the above solutions were ever implemented. Resources? Sponsor? Agreement?
Edit: mispelling
I'm curious why none of the above solutions were ever implemented. Resources? Sponsor? Agreement?
Honestly, I think it's more a lack of momentum than anything else. It's a little bit of a solution in search of a problem — in reality, there aren't a ton of new packages created on a regular basis.
At this point, my preferred approach would be:
- A page in the handbook that lists community packages maintained outside of the WP-CLI community.
- Create more repos inside of this GitHub organization for common, general purpose commands.
Out of curiosity, how did you stumble upon this issue? What problem are you hoping to see addressed?
Out of curiosity, how did you stumble upon this issue? What problem are you hoping to see addressed?
I've been writing several wp-cli packages that I've been installing via git url. I'm now doing a presentation on writing custom wp-cli packages and noticed the handbook mentions the package index numerous times. But when I went to investigate how to submit a package to the index (linked from the package-index page), discovered it was deprecated. That led me down a rabbit hole that ultimately brought me here. 😄
there aren't a ton of new packages created on a regular basis.
I can't speak with confidence on whether there are, or there aren't, but I'll offer this counterpoint: one possibility is people follow the same path I did above, see that the index is deprecated, but then just stop. As an example of this, you can read the discussion surrounding the deprecation (and reversal) of Gitlab's public accessibility job template.
Thanks for the explanation 😊
I've been writing several wp-cli packages that I've been installing via git url.
Are these packages meant for public consumption? Do you intend to maintain and support them?
I can't speak with confidence on whether there are, or there aren't, but I'll offer this counterpoint: one possibility is people follow the same path I did above, see that the index is deprecated, but then just stop.
Sure, makes sense. If there's interest at an upcoming Contributor Day, we could potentially discuss reviving a package index cc @wp-cli/maintainers
A curated list of some useful and popular commands sounds like a good start in the interim.
Highlighting plugins offering commands would also be nice. Maybe for now also in a curated way? There are around 600 in the repo: https://wpdirectory.net/search/01H46J87X60A5XC4KSJ1A42QVH
Are these packages meant for public consumption?
Possibly? I could certainly make them more generic to see if anyone else can use them. So far they've mostly been for my own use.
Do you intend to maintain and support them?
Yes, if I end up putting them in a public directory of some sorts, I'd definitely continue to maintain them.
@swissspidy I already created an "awesome list" in the past: https://github.com/schlessera/awesome-wp-cli
@swissspidy I already created an "awesome list" in the past: https://github.com/schlessera/awesome-wp-cli
Is it ok if I promote/publicize that repository?