The one in `functions.php` can be considered a bug in WPCS and has been reported as such.
Once that issue is fixed, the whitelisting can be removed.
The one in `inc/wpcom.php` will need to remain as WPCS does not keep track of globals introduced by wpcom.
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.
As WPCS and PHPCompatibility were for a little while (May - July 2017) not compatible with PHPCS 3.x, the library tags cloned were previously fixed to prevent issues with that.
As both WPCS as well as the PHPCompatibility standard are now compatible with PHPCS 3.x, the changes made in PR 1110 and PR 1183 can be reverted.
Notes:
* PHPCS - use `master`.
WPCS uses a limited set of sniffs from PHPCS itself.
Most of these sniffs are long established, stable and rarely get updated, so using PHPCS `master` should be safe.
* WPCS - use the latest release `0.14.0`.
WPCS is the main source of CS violations and is under active development. This means that new versions of WPCS will easily break the build, so should be managed.
* PHPCompatibility - use `master`.
PHPCompatibility checks PHP cross-version compatibility.
It is actively developed and heavily unit tested, so any new violations found in `_s` because of changes in that library, should actually be addressed in `_s` ASAP.
The PHPCompatibility library became compatible with PHPCS 3.x and improved compatibility with Composer installs in version `8.0.0` which was a breaking change.
To account for that, the location where the library is cloned to and the `phpcs --installed_paths` command have been updated.
Ref: https://github.com/wimg/PHPCompatibility/pull/446
At some point in time, PHP was lagging behind and HHVM seemed like the future. What with PHP 7 being released and doing incredibly well, that time has passed and the popularity of HHVM is now marginal.
This commit drops testing against HHVM and starts testing against bleeding edge PHP nightly instead.
jrfnl
jrfnl
Chris Runnells
Ram Ratan Maurya
Laurel
Benoît Chantre
Oliver Juhas
Sergey Biryukov
David A. Kennedy
Thomas Guillot
Ismail El Korchi
Ben
Bappi
Sami Keijonen