Based on the [Contributor Covenant](https://www.contributor-covenant.org) version 2.0.
As there is no email address available for the project, I'm proposing to use the WP Core Slack channel #core-coding-standards as the official channel to report violations. Depending on the violation, details can shared in private via DMs if needed to protect the privacy of the parties involved.
While the minimum PHPCS version has already been upped to PHPCS 3.5.0 previously for the WPCS 3.0.0 branch, I'm proposing to up it yet further to the latest PHPCS version available.
PHP 8.0 and 8.1 introduced a lot of new syntaxes and, while a lot of this can be supported for older PHPCS versions via PHPCSUtils, this will always impact performance and precision, so it is strongly advisable to use the latest PHPCS version as the new minimum if we want to support the newly available PHP syntaxes.
For now, I'm upping the minimum version to PHPCS 3.6.2, which is the latest PHPCS release. This will unblock PRs to add support for PHP 8.0 features to WPCS.
Once PHPCS 3.7.0 has been released, the minimum PHPCS version should be upped again to unblock adding support for PHP 8.1 features to WPCS.
Includes updating the GH Actions matrixes for this change.
Also see #2048
While rare, there are some deprecations which PHP can show when a file is being linted.
By default these are ignored by PHP-Parallel-Lint.
Apparently though, there is an option to show them (wasn't documented until recently), so let's turn that option on.
A number of predefined actions have had major release, which warrant an update the workflow(s).
These updates don't actually contain any changed functionality, they are mostly just a change of the Node version used by the action itself (from Node 14 to Node 16).
Refs:
* https://github.com/actions/checkout/releases
This allows for a time calculation to be wrapped in parentheses.
Fixes 2025
---
Note: just looking at the code, I can see multiple additional improvements which could/should be made:
* Only search for close parenthesis as a "valueEnd" if the `$valueStart` token is an open parenthesis.
* Allow for more assignment operators - the new schedule could be build up bit by bit and only assigned to the array later.
These additional things are not addressed here. This just addresses the immediate issue.
This commit makes the necessary adjustments to the test matrix to account for that.
Note: the protected branch settings should be adjusted after this change to include the two new PHP 8.1 builds.
The `dealerdirect/phpcodesniffer-composer-installer` Composer plugin is used to register external PHPCS standards with PHPCS.
As of Composer 2.2.0, Composer plugins need to be explicitly allowed to run. This adds the necessary configuration for that.
Refs:
* https://blog.packagist.com/composer-2-2/#more-secure-plugin-execution
... to the default "ignore" list.
The `libxml_disable_entity_loader()` function is deprecated in PHP 8.0, but a call to the function is still needed in select circumstances, in which case silencing the deprecation warning is perfectly acceptable.
Turns out the default setting for `error_reporting` used by the SetupPHP action is `error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT` and `display_errors` is set to `Off`.
For the purposes of CI, I'd recommend running with `E_ALL` and `display_errors=On` to ensure **all** PHP notices are shown.
In this script, error_reporting was already enabled, but the error display was not yet fixed. Sorted now.
After the umpteenth time of getting a non-reproducible bug report (not just in this repo, mind you), I figured it may help to add some more guidance to the bug report template.
More important changes:
* Ask for the actual CLI command people have used.
* Ask for the custom ruleset used (if used).
* Give some guidance on how to find out the version numbers of the tooling used.
... which show through in PRs, even when the code in those files has not been adjusted in the PR.
There's only one such warning remaining now, which is _actual_ commented out code.
Per the discussion had on Slack about this initiated by GaryJones.
WP Core currently has 27 violations against this rule.
In `Extra` the error message was changed and downgraded to a `warning`.
Now the sniff will be added to `Core`, per this PR, the:
* Message text will still be changed a little to be clearer, but will be stricter.
* The message will be an `error` and not be downgraded to a `warning`.
To do:
- [ ] Add a rule to this effect to the handbook.
... as the `quicktest` workflow is run on `push` events, not on PRs, so displaying results in a PR is not relevant (and is done via the `test` workflow which _is_ run on `pull` events anyhow).
Letting PHPUnit read the config file causes an error on PHP 8.1 in combination with PHPUnit 7.
For now, special case the test run on PHP 8.1 and pass the only necessary config from the configuration file on via CLI arguments.
PHP 8.1 deprecates passing `null` to PHP native functions where the parameter(s) is not explicitly nullable.
While in PHP 8.1 this is only a deprecation, it should, of course, still be fixed.
This commit contains a fix for the second of the two issues in WordPressCS found related to this so far (based on the unit tests).
Passing `null` to `trim()` is now deprecated, so more defensive coding or explicit type casting is needed.
This comes into play for the `I18nSniff::process_token()` and the `PrefixAllGlobalsSniff::process_token()` methods where the `Helper::getConfigData()` method can return either string or `null`.
Ref: https://phpcsutils.com/phpdoc/classes/PHPCSUtils-BackCompat-Helper.html#method_getConfigData
PHP 8.1 deprecates passing `null` to PHP native functions where the parameter(s) is not explicitly nullable.
While in PHP 8.1 this is only a deprecation, it should, of course, still be fixed.
This commit contains a fix for the one of the two issues in WordPressCS found related to this so far (based on the unit tests).
Passing `null` to `trim()` is now deprecated, so more defensive coding or explicit type casting is needed.
This comes into play for the `MinimumWPVersionTrait::get_wp_version_from_cli()` method where the `Helper::getCommandLineData()` method can return either string or `null`.
Ref: https://phpcsutils.com/phpdoc/classes/PHPCSUtils-BackCompat-Helper.html#method_getCommandLineData
As it looks like PHPCS 4.x is still quite a while away (2022 at the earliest), let's stop testing against PHPCS 4.x for the time being.
This should allow build failure reporting to be more accurate, as currently every PR has a failure on PHPCS 4.x due to a bug in some of the new code in 4.x (fix for this was pulled six months ago and still not merged).
The build against PHPCS 4.x should be re-enabled closer to the PHPCS 4.x release.
Note: PHPCSUtils will continue to test against PHPCS 4.x and will update the provided utilities ahead of time, so with a bit of luck, by the time the build against PHPCS 4.x is re-enabled, the build should largely pass thanks to the compatibility layers in PHPCSUtils.
