add a --skip-plugins-except=<plugins-to-keep-active> global parameter

[pbiron]

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-plugin
• wp @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.

[pbiron]

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:

1. silently ignore the "user error" (which is essentially what happens with the --skip-plugins + shell friends approach)
2. temporarily activate those plugins that aren't already active (if they are installed)
3. exit with an error (to let the user know that their intent can't be realized)

There are probably other others as well.

[danielbachhuber]

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]

Because global parameters conflict with local parameters...

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 the wp post list command (and similar "dynamic" local parameters of other commands). Is that what you're getting at?

[swissspidy]

@pbiron Someone could have developed a custom command with a --skip-plugins-except parameter. If we now add such a global parameter in WP-CLI, we would break their command. Hope that clarifies it!

[swissspidy]

Related: the proposed --skip-plugins-except param reminds me a bit of troubleshooting mode in the Health Check & Troubleshooting plugin

[pbiron]

@pbiron Someone could have developed a custom command with a --skip-plugins-except parameter. If we now add such a global parameter in WP-CLI, we would break their command. Hope that clarifies it!

Yes, it does, thanx, Pascal. I can understand why adding new global params might be a bad thing

[swissspidy]

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 ",")

Perhaps we could add a new --exclude param to wp 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]

It could be worth exploring other ways of achieving this same goal, though.

Just spitballing here, but maybe we could introduce new syntax for the existing --skip-plugins param, such as:

• wp @foo export --filename_format=file.xml --post-type=my-cpt --skip-plugins=!my-plugin

Altho, 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-plugin

[pbiron]

Another idea I just thought of is to "co-opt" the --no- flag prefix (e.g., as in wp command --no-color) which might become:

• wp @foo export --filename_format=file.xml --post-type=my-cpt --no-skip-plugins=my-plugin

that one's a stretch ;-) Like I said, just throwing out ideas

[pbiron]

Perhaps we could add a new --exclude param to wp 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)

That would work...if we can't come up with better strategy

[pbiron]

In general, I think having a way to negate --param=val parameters would be great.

For instance, I occasionally would like get a list of plugins that do not have --status=inactive and there is currently no way to do that (without resorting to shell friends). So, having something like:

• wp plugin list --status!=inactive

could come in handy

[pbiron]

Perhaps we could add a new --exclude param to wp 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)

That would work...if we can't come up with better strategy

I'd also note that having a "negation" syntax would obviate the need for a new --exclude param for wp plugin list, because then we could do

• wp plugin list --name!=wordpress-importer,my-plugin (with whatever negation syntax we come up)

[danielbachhuber]

The negation syntax is tempting...

[pbiron]

But there are certainly params that it should not be allowed on because of the semantics. For example, wp plugin list --format!=table ;-)

[aaroncampbell]

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-plugins or something similar?

[danielbachhuber]

it's super useful to be able to process a command while keeping only a specific plugin active.

What's the specific use case?

[aaroncampbell]

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]

What's the specific use case?

This can be especially valuable when you need to ensure certain plugins-specific commands can run without conflicting with others. @danielbachhuber

wp jetpack and wp yoast commands 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 jetpack commands 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.