Improve active_plugins filter

[swissspidy]

See #518 and #597.

Filters active plugins to only include required ones. This means:

• The plugin being tested
• All dependencies of the plugin being tested
• Plugin Check itself
• All active dependents of Plugin Check (they could be adding new checks)

To-do:

• Add Behat tests (ideally after Add feature tests for checking plugin with addon enabled #518 is merged).
  • IMO such end-to-end tests are best for testing this scenario.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: swissspidy <[email protected]>
Co-authored-by: ernilambar <[email protected]>
Co-authored-by: felixarntz <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[felixarntz]

@swissspidy Thanks, looks great! Just a few minor comments.

[felixarntz]

@swissspidy Are you planning to merge #518 first and then see which uncommented Behat tests this here will fix?

[swissspidy]

@swissspidy Are you planning to merge #518 first and then see which uncommented Behat tests this here will fix?

Yep!

[swissspidy]

Right now I can't enable any of the commented out Behat tests because they're still not passing, because we still need to address (2) and (3) from #597 (comment)

[felixarntz]

Right now I can't enable any of the commented out Behat tests because they're still not passing, because we still need to address (2) and (3) from #597 (comment)

I think it would only be point (3) that would help with the remaining Behat tests, so maybe we can work on that one first.

Could you give it a try to implement a Behat test that runs two runtime checks, one from the addon and one built-in one? For instance amend/duplicate the very last Behat test in plugin-check.feature that way. I'm curious what happens then, since part of the problem that (3) would solve is only relevant if the only runtime check comes from an addon. But if we also have a runtime check from the built-in ones, that's a different implication because it'll already know we need to initialize runtime check relevant logic.

[felixarntz]

Following up on my previous comment, based on what I wrote in #597 (comment), I would actually assume that if you do what I recommended before, you'll run into the exception that the slug is invalid - which will prevent the rest from proceeding even if then the plugin checker technically would know to initialize runtime environment preparations.

[swissspidy]

Right now I can't enable any of the commented out Behat tests because they're still not passing, because we still need to address (2) and (3) from #597 (comment)

I think it would only be point (3) that would help with the remaining Behat tests, so maybe we can work on that one first.

Could you give it a try to implement a Behat test that runs two runtime checks, one from the addon and one built-in one? For instance amend/duplicate the very last Behat test in plugin-check.feature that way. I'm curious what happens then, since part of the problem that (3) would solve is only relevant if the only runtime check comes from an addon. But if we also have a runtime check from the built-in ones, that's a different implication because it'll already know we need to initialize runtime check relevant logic.

Argh, sorry I missed this suggestion. I think we can do this in #612 though