Juliette

> I guess I don't understand the point of allow-plugins... Well, it was introduced as a security feature and while this plugin is quite innocent and limited in what it...

@helgatheviking Can we close this issue as "answered" ?

@Potherca FYI: I've added this issue to the "pinned issues" and remove the pins related to Composer 2.x and PHP 8.0 as those are a bit dated by now.

While that would be the _proper_ solution, unfortunately the 'average' WP user doesn't even know what "server configuration" is... so I'd advocate for requiring these empty index files.

@TukuToi The sniff used for this is not a WPCS native sniff, but one from [PHPCS](https://github.com/squizlabs/PHP_CodeSniffer) itself, so if you want to open an issue about it, it should be...

@TukuToi No worries. FYI: The [CONTRIBUTING.md](https://github.com/WordPress/WordPress-Coding-Standards/blob/develop/.github/CONTRIBUTING.md) doc has information about how to determine whether an issue is a WPCS issue or an upstream one.

Same as for #612: > Action plan suggestion: > 1. Deprecate the sniff in the next release (2.x) by: > 1. Adding a deprecation warning to the sniff which will...

As the WPCS property which controls the "allow list" is `protected`, I think we can simply extend the WPCS sniff and add those extra ini settings to the property from...

See: https://github.com/WordPress/WordPress-Coding-Standards/issues/993#issuecomment-539375086

Hard-deprecated hooks using `apply_filters_deprecated()` and `do_action_deprecated()` are currently already ignored by the sniff. It is only the "soft" deprecated hooks, i.e. hooks which have a `@deprecated` marker in the docblock,...