Repository navigation
add a --skip-plugins-except=<plugins-to-keep-active> global parameter #5854
Description
Feature Request
- Yes, I reviewed the contribution guidelines.
Describe your use case and the problem you are facing
When doing wp @foo export --filename_format=file.xml --post_type=my-cpt I usually want to skip all plugins except for the plugin that registers my-cpt and when doingwp @bar import file.xml (where file.xml contains posts of post_type my-cpt) I usually want to skip all plugins except for wordpress-importer and the plugin that registers my-cpt.
In such cases, I turn to various "shell friends" to accomplish this, but I always have to rack my brain to remember exactly the syntax to use in those shell friends:
wp @foo export --filename_format=file.xml --post-type=my-cpt --skip-plugins=$(wp @foo plugin list --field=name --status=active | grep -v my-plugin | paste -s -d ",")wp @bar import file.xml --skip-plugins=$(wp @bar plugin list --field=name --status=active | grep -vE 'wordpress-importer|my-plugin' | paste -s -d ",")
Describe the solution you'd like
I propose adding a new global parameter: --skip-plugins-except=<plugins-to-keep-active>, where <plugins-to-keep-active> is a comma-separate list of plugin slugs.
With this new global parameter, the above commands could be simplified to:
wp @foo export --filename_format=file.xml --post-type=my-cpt --skip-plugins-except=my-pluginwp @bar import file.xml --skip-plugins-except=wordpress-importer,my-plugin
This new global parameter would have many benefits:
- makes the intent much more clear (i.e., self-documenting)
- opens the functionality to more users (e.g., those who aren't comfortable with complex shell commands)
- opens the functionality to environments where typical shell friends aren't available (e.g., Windows)
For completeness, it would probably also be a good idea to add --skip-themes-except=<themes-to-keep-active>, even though I can't at the moment think of any reasonable use cases where I'd want to, say, skip a child theme while leaving the parent theme active...but such use cases could exist.
Although, I haven't yet checked how the existing --skip-plugins (and --skip-themes) parameters are implemented, I think it should be relatively easy to add this new functionality, altho there might be a few corner cases that need to be considered, e.g., #3827.
Activity
pbiron commentedon Oct 29, 2023
Something which should be discussed before jumping in with a proposed patch is: what should happen if the plugins specified in
--skip-plugins-except=<plugins-to-keep-active>are not currently active?A couple of options come to mind:
--skip-plugins + shell friendsapproach)There are probably other others as well.
danielbachhuber commentedon Oct 30, 2023
Thanks for the suggestion, @pbiron
Because global parameters conflict with local parameters, I think it's very unlikely we will add any new ones. While it seems unlikely, we could break someone's existing command.
It could be worth exploring other ways of achieving this same goal, though.
pbiron commentedon Oct 30, 2023
Can you elaborate on this.
I think you're saying that there is a possibility that
--skip-plugins-except=<plugins-to-keep-active>could conflict with the--<field>=<value>parameter of thewp post listcommand (and similar "dynamic" local parameters of other commands). Is that what you're getting at?swissspidy commentedon Oct 30, 2023
@pbiron Someone could have developed a custom command with a
--skip-plugins-exceptparameter. If we now add such a global parameter in WP-CLI, we would break their command. Hope that clarifies it!swissspidy commentedon Oct 30, 2023
Related: the proposed
--skip-plugins-exceptparam reminds me a bit of troubleshooting mode in the Health Check & Troubleshooting pluginpbiron commentedon Oct 30, 2023
Yes, it does, thanx, Pascal. I can understand why adding new global params might be a bad thing
swissspidy commentedon Oct 30, 2023
Perhaps we could add a new
--excludeparam towp plugin list? That would make this a bit easier.e.g.
wp @bar import file.xml --skip-plugins=$(wp @bar plugin list --field=name --status=active --exclude=wordpress-importer,my-plugin)Thoughts?
pbiron commentedon Oct 30, 2023
Just spitballing here, but maybe we could introduce new syntax for the existing
--skip-pluginsparam, such as:wp @foo export --filename_format=file.xml --post-type=my-cpt --skip-plugins=!my-pluginAltho, it's probably possible that a real plugin slug could begin with
!A similar suggestion would be to use
!=, as in:wp @foo export --filename_format=file.xml --post-type=my-cpt --skip-plugins!=my-pluginpbiron commentedon Oct 30, 2023
Another idea I just thought of is to "co-opt" the
--no-flag prefix (e.g., as inwp command --no-color) which might become:wp @foo export --filename_format=file.xml --post-type=my-cpt --no-skip-plugins=my-pluginthat one's a stretch ;-) Like I said, just throwing out ideas
pbiron commentedon Oct 30, 2023
That would work...if we can't come up with better strategy
pbiron commentedon Oct 30, 2023
In general, I think having a way to negate
--param=valparameters would be great.For instance, I occasionally would like get a list of plugins that do not have
--status=inactiveand there is currently no way to do that (without resorting to shell friends). So, having something like:wp plugin list --status!=inactivecould come in handy
pbiron commentedon Oct 30, 2023
I'd also note that having a "negation" syntax would obviate the need for a new
--excludeparam forwp plugin list, because then we could dowp plugin list --name!=wordpress-importer,my-plugin(with whatever negation syntax we come up)danielbachhuber commentedon Oct 30, 2023
The negation syntax is tempting...
pbiron commentedon Oct 30, 2023
But there are certainly params that it should not be allowed on because of the semantics. For example,
wp plugin list --format!=table;-)aaroncampbell commentedon Mar 16, 2024
I think that for both this issue and #5917 it's super useful to be able to process a command while keeping only a specific plugin active. I understand the problem with new global command potentially conflicting with existing custom ones, but it still seems like a useful enough case to solve for.
Would it be possible to allow for new global parameters going forward, but using come kind of prefix?
--wpcli-global--include-pluginsor something similar?danielbachhuber commentedon Mar 17, 2024
What's the specific use case?
aaroncampbell commentedon Mar 17, 2024
A number of commands that we run need our own plugin to be active - to process incoming data before it's stored, retrieve and return data, etc. But other plugins are excess overhead in most of those cases, and in some cases they can cause unintended issues (removing or short-circuiting hooks, etc)
JoshuaGoode commentedon Mar 20, 2024
This can be especially valuable when you need to ensure certain plugins-specific commands can run without conflicting with others. @danielbachhuber
wp jetpackandwp yoastcommands are examples that some admins may want to run in bulk across sites while skipping potential conflicts and fatals from other plugins.For hosts, being able to run
wp jetpackcommands directly without interference can help with various troubleshooting, checks, and fixers running within the context of the plugin and the site. While avoiding complex alternatives.jordantrizz commentedon Nov 19, 2024
Here's a rough draft of some use cases
wp-cli fails to run in the following situations
Running wp-cli at scale (100+ sites) via automation adds latency loading all plugins when only one or two is required.
Many hosting providers and control panels use https://aaemnnost.tv/wp-cli-commands/login/ for SSO, which allows passwordless logins to WordPress instances. All the situations listed in Use Case 1 will cause a failure to generate the URL.
I understand that a plugin and theme should be fixed to work with wp-cli or have conditions to fail in the above scenarios safely. But that's not real life, and when managing 100+ sites, it's unrealistic to control everything even when you're just providing resources and not involved in development.
jordantrizz commentedon Nov 19, 2024
If you use wp-cli with bash or any other linux shell then ! would cause problems https://www.baeldung.com/linux/bash-exclamation-mark
Granted != wouldn't, but why even bring a delimiter that could cause issues.
jordantrizz commentedon Nov 19, 2024
Wouldn't a global parameter precede a package's local parameter not shipped with wp-cli? Excessive caution about downstream impact can potentially stifle further development of wp-cli. Especially in this case with with such a unique name.
If someone else is using --skip-plugins-except, perhaps they're trying to solve this very problem. I'm sure they would feel relieved having this supported parameter in the core of wp-cli.