Indicate non-WP components

[DavidAnderson684]

Perhaps it'd be useful to have a mechanism for plugin authors to include a configuration file (e.g. plugin-check-info.json in the root of the plugin) to give information to Plugin Check?

For example, I'd like to indicate that vendor/phpseclib/phpseclib is a third-party library and hence Plugin Check warnings that recommend using internal WP functions are simply unhelpful noise. i.e. In this example it'd be handy to tell Plugin Check to exclude any checks that purely make suggestions for using WP internals. But there are likely to be many other examples of this sort of thing in relation to 3rd party libraries. A configuration file to declare such items would both reduce noise and still allow developers/reviewers to see what's being declared easily.

[ernilambar]

May be related to #310

[swissspidy]

Like for similar requests in the past this I think this is something that could be implemented in a custom plugin using the existing filters. Alternatively, the CLI command amd the GitHub action are also very powerful.

[DavidAnderson684]

But if the default experience of the plugin UI is going to include junk results for which the solution is "use or code something else to work around that", then why have a plugin UI at all?
i.e. Providing a second-class experience isn't worth the effort. Having external dependencies inside a plugin which will litter the provided results every time and which the author will want to exclude every time isn't a rare or exotic use case.

[swissspidy]

Just because it's a third-party package doesn't mean it can be safely skipped. When you submit a plugin to the plugin directory, the tool can't simply ignore the vendor directory by default.

We could consider adding more UI options to exclude certain checks or directories, but then I'd say we can close this issue as a duplicate of #313 & reopen that one.

[DavidAnderson684]

"Just because it's a third-party package doesn't mean it can be safely skipped."

That's why I think a declarative file (N.B. not a UI option) in which the specific skips can be listed so that they're clearly visible for everyone would be a good solution.

I don't think #313 is the same thing. UI options might be on, might be off - but without a declaration of proposed exclusions, the reviewer won't know what's being proposed to him by the plugin. (And having to manually enter them every time would be a poor experience). I think the only UI option relevant to my suggestion would be whether or not to follow the bundled list of proposed exclusions in the check being run.

[email protected] could well be the #1 expert on PHP/encryption issues over the last couple of decades. Recommending that his phpseclib/phpseclib consider using WP core functions makes no sense. Allowing a plugin author to effectively pre-request sensible exclusions (a request which will be visible to the reviewer so that he can decide if he thinks they make sense), is a win for everyone.