wp-cli
wp-cli copied to clipboard
wp-cli
Provide an easier way to specify target site (`--url`)
My use case / problem
I frequently run commands on a Multisite instance with a large number of sites, most of which have long domains. Typing in the full URL to specify the target site feels unnecessarily tedious and slow.
e.g., wp shell --url=https://2019.saintpetersburg.wordcamp.org
The solution I'd like
It'd be much faster and more convenient if --url accepted a substring, and performed a search if the string isn't an exact match for a domain.
e.g., wp shell --url=2019.saintp
To avoid any confusion, the command could output the full URL of the selected site when a substring is used:
> wp cron event list --url=2019.saintp
Running command against `https://2019.saintpetersburg.wordcamp.org`
+------------------------------------------+---------------------+-----------------------+---------------+
| hook | next_run_gmt | next_run_relative | recurrence |
+------------------------------------------+---------------------+-----------------------+---------------+
| wp_cache_gc | 2019-07-30 14:36:28 | 2 minutes 8 seconds | Non-repeating |
...
That could be disabled when --quiet is set, though.
If multiple results are found for the given substring, then the safest thing to do might be to throw an error, and ask the user to provide a unique substring.
In mutli-network installs, it should probably just search all networks, since everything is stored in wp_blogs anyway.
wp_blogs has a domain index comprised of wp_blogs.domain and wp_blogs.path, so searching should be performant even in very large sites. If that doesn't turn out to be true, though, then the search could simply be disabled when wp_is_large_network(), and the user would have to specify an exact URL. That would only impact a relatively small number of WP-CLI users, though.
If a scheme isn't specified, then I think WP would just default to the value of force_ssl_admin(), but haven't tested that.
@iandunn Im' not necessarily a fan of letting WP-CLI guess something and then immediately act on that.
However, why don't we add the possibility to use the shell autocompletion on the --url parameter?
Hi! Any progress on this? Or at least having a hook there to extend/customise behaviour here would be extremely helpful.
Related: https://github.com/wp-cli/extension-command/issues/21#issuecomment-311995871
The only drawback would be that completions wouldn't be as snappy, since we'd have to load WordPress.
The ideal situation would be to load WordPress on demand when the autocompletion context requires it. No idea how workable that is.
Closing this as maybelater. I don't think it's feasible to load WordPress in the autocompletion process, but I'd be happy to be proven wrong.
For this use case, we could maybe write a cache file w/ a list of URLs in the network. That way we wouldn't have to load WP each time.
I think this should live in an installable package. This could make for a good contributor day project.
