WordPress provides backfills for a number of PHP native functions and constants.
These can therefore be safely used in themes and plugins.
This commit adds a whitelist for the PHPCompatibility ruleset of the backfills currently provided by WP.
N.B.: At this moment, none of the whitelisted classes/constants/functions/interfaces are used in `_s`.
However, `_s` is also a teaching tool and an example for others, so having this whitelist block in there serves that purpose and allows for themes which are build onto `_s` to use these PHP features without having to worry about cross-version compatibility notices.
Everything which is defined in the global namespace should be prefixed to prevent conflicts with other themes and plugins.
This snippet enables the sniff which verifies this and tells it which prefix to look for.
A number of additional sniffs have been added to WPCS which all use the `minimum_supported_version` property to know which WP version to check against.
As setting these properties for each sniff becomes tedious and would necessitate the ruleset to be adjusted each time a new sniff which uses that property becomes available, WPCS now offers a (forward-compatible) way to set the minimum supported WP version for all sniffs in one go.
This uses a new feature which is available since PHPCS 3.x.
The effect will depend on the system on which PHPCS is being run, but if parallel processing can be run, the build should be faster using this option.
The `-n` flag will ignore warnings completely, while often it is useful to see them and to fix them.
Using `--runtime-set ignore_warnings_on_exit 1` in the Travis script instead, warnings will be shown, both when a developer runs PHPCS on their own machine, as well as in Travis, but warnings will not cause a failed Travis build.
The `-v` flag will list each file being scanned. This is intended for debugging purposes and not needed for normal use.
The link was pointing to the `WordPress-Core` ruleset, while `_s` uses the `WordPress` ruleset which encompasses more than just the core rules.
Pointing to the repo + the wiki seems more appropriate to me.
If the file is called `phpcs.xml` or `phpcs.xml.dist`, it is automatically picked up by PHPCS.
A `phpcs.xml` is given preference over a `phpcs.xml.dist` file. So renaming the file to `phpcs.xml.dist` allows for people to use the file provided by `_s` if they choose not to add their own, but also leaves people the freedom to easily overrule it.
jrfnl
Truong Giang
David A. Kennedy
jrfnl