Bug Description

The current description of the rulesets available (https://github.com/WordPress/WordPress-Coding-Standards?tab=readme-ov-file#rulesets) is potentially misleading (although I appreciate it may well be technically accurate).

You can use the following as standard names when invoking phpcs to select sniffs, fitting your needs:

• WordPress - complete set with all of the sniffs in the project
  • WordPress-Core - main ruleset for WordPress core coding standards
  • WordPress-Docs - additional ruleset for WordPress inline documentation standards
  • WordPress-Extra - extended ruleset with recommended best practices, not sufficiently covered in the WordPress core coding standards
    • includes WordPress-Core=

My reading of this, is that I can either run the WordPress standard, or the individual subsets. For example, if I don't want to run the WordPress-Docs checks, then I could have my project run WordPress-Extra (which includes WordPress-Core and that would yield the same results as running WordPress but with WordPress-Docs excluded. In other words, I'd expected that all sniffs were included in either WordPress-Core, WordPress-Docs, or WordPress-Extra and that WordPress didn't itself define any additional sniffs.

However, it seems that that is not the case, and running WordPress runs some sniffs (including security-related sniffs) that are not present in the subsets.

If that's intended then I think that the documentation could be clearer. Specifically it should probably only refer to running the WordPress standard and excluding subsets, rather than running subsets directly, and should state clearly that the WordPress standard does include some sniffs that aren't in the subsets.

An alternate resolution would be for all sniffs to be contained in at least one subset so that running a check with all subsets yields the same results as running with the superset.

Again, I'm aware that the current terminology (superset/subset) is technically accurate to describe the observed behaviour, but I still feel it's not the inference most people would make reading that text.

Minimal Code Snippet

Take the following example file (test.php):

<?php

$foo = $_REQUEST['foo'];

Checking that with the WordPress-Docs, and WordPress-Extra standards yields two errors:

phpcs --standard=WordPress-Docs,WordPress-Extra test.php

FILE: /private/tmp/phpcs-repo/test.php
----------------------------------------------------------------------
FOUND 1 ERROR AND 1 WARNING AFFECTING 2 LINES
----------------------------------------------------------------------
 1 | ERROR   | Missing file doc comment
 3 | WARNING | Processing form data without nonce verification.
----------------------------------------------------------------------

Checking the same file with the WordPress standard yields a further 3 errors (all from the WordPress.Security namespace - others may also be affected):

phpcs --standard=WordPress test.php

FILE: /private/tmp/phpcs-repo/test.php
----------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 4 ERRORS AND 1 WARNING AFFECTING 2 LINES
----------------------------------------------------------------------------------------------------------------------------------------------------
 1 | ERROR   | Missing file doc comment
 3 | WARNING | Processing form data without nonce verification.
 3 | ERROR   | Detected usage of a possibly undefined superglobal array index: $_REQUEST['foo']. Check that the array index exists before using it.
 3 | ERROR   | $_REQUEST['foo'] not unslashed before sanitization. Use wp_unslash() or similar
 3 | ERROR   | Detected usage of a non-sanitized input variable: $_REQUEST['foo']
----------------------------------------------------------------------------------------------------------------------------------------------------

Error Code

The three sniffs in the example above are as follows - although this is not an exhaustive list of affected sniffs:

• WordPress.Security.ValidatedSanitizedInput.InputNotValidated
• WordPress.Security.ValidatedSanitizedInput.MissingUnslash
• WordPress.Security.ValidatedSanitizedInput.InputNotSanitized

Environment

dealerdirect/phpcodesniffer-composer-installer 1.2.0  PHP_CodeSniffer Standards Composer Installer Plugin
phpcsstandards/phpcsextra                      1.5.0  A collection of sniffs and standards for use with PHP_CodeSniffer.
phpcsstandards/phpcsutils                      1.2.1  A suite of utility functions for use with PHP_CodeSniffer
squizlabs/php_codesniffer                      3.13.5 PHP_CodeSniffer tokenizes PHP, JavaScript and CSS files and detects violations of a defined...
wp-coding-standards/wpcs                       3.3.0  PHP_CodeSniffer rules (sniffs) to enforce WordPress coding conventions