-
Notifications
You must be signed in to change notification settings - Fork 958
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add a --skip-plugins-except=<plugins-to-keep-active>
global parameter
#5854
Comments
Something which should be discussed before jumping in with a proposed patch is: what should happen if the plugins specified in A couple of options come to mind:
There are probably other others as well. |
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. |
Can you elaborate on this. I think you're saying that there is a possibility that |
@pbiron Someone could have developed a custom command with a |
Related: the proposed |
Yes, it does, thanx, Pascal. I can understand why adding new global params might be a bad thing |
Perhaps we could add a new e.g. Thoughts? |
Just spitballing here, but maybe we could introduce new syntax for the existing
Altho, it's probably possible that a real plugin slug could begin with A similar suggestion would be to use
|
Another idea I just thought of is to "co-opt" the
that one's a stretch ;-) Like I said, just throwing out ideas |
That would work...if we can't come up with better strategy |
In general, I think having a way to negate For instance, I occasionally would like get a list of plugins that do not have
could come in handy |
I'd also note that having a "negation" syntax would obviate the need for a new
|
The negation syntax is tempting... |
But there are certainly params that it should not be allowed on because of the semantics. For example, |
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? |
What's the specific use case? |
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) |
This can be especially valuable when you need to ensure certain plugins-specific commands can run without conflicting with others. @danielbachhuber
For hosts, being able to run |
Feature Request
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 registersmy-cpt
and when doingwp @bar import file.xml
(where file.xml contains posts of post_typemy-cpt
) I usually want to skip all plugins except forwordpress-importer
and the plugin that registersmy-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:
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.The text was updated successfully, but these errors were encountered: