In WordPressCS 3.0.0, the functionality of the `WordPress.Security.EscapeOutput` sniff was updated to report unescaped message parameters passed to exceptions created in `throw` statements. This specific violation now has a separate error code: `ExceptionNotEscaped`. This will allow users to ignore or exclude that specific error code.
The error code(s) for other escaping issues flagged by the sniff remain unchanged.
References:
* [https://github.com/WordPress/WordPress-Coding-Standards/releases/tag/3.0.1 WPCS 3.0.1 release notes]
* [https://github.com/WordPress/WordPress-Coding-Standards/compare/3.0.0...3.0.1 Full list of changes in WPCS 3.0.1]
Follow-up to [56695].
Props jrf, bjorsch, dawidurbanski.
See #59161.
git-svn-id: https://develop.svn.wordpress.org/trunk@56799 602fd350-edb4-49c9-b593-d223f7449a82
This is an important release which makes significant changes to improve the accuracy, performance, stability and maintainability of all sniffs, as well as making WordPressCS much better at handling modern PHP.
WordPressCS 3.0.0 contains breaking changes, both for people using ignore annotations, people maintaining custom rulesets, as well as for sniff developers who maintain a custom PHPCS standard based on WordPressCS.
If you are an end-user or maintain a custom WordPressCS based ruleset, please start by reading the [https://github.com/WordPress/WordPress-Coding-Standards/wiki/Upgrade-Guide-to-WordPressCS-3.0.0-for-ruleset-maintainers Upgrade Guide to WordPressCS 3.0.0 for ruleset maintainers] which lists the most important changes and contains a step by step guide for upgrading.
If you are a maintainer of an external standard based on WordPressCS and any of your custom sniffs are based on or extend WordPressCS sniffs, please read the [https://github.com/WordPress/WordPress-Coding-Standards/wiki/Upgrade-Guide-to-WordPressCS-3.0.0-for-Developers-of-external-standards Upgrade Guide to WordPressCS 3.0.0 for Developers].
In all cases, please read the complete changelog carefully before you upgrade.
This commit:
* Updates the Composer dependencies to use the new version, including updating the underlying PHP_CodeSniffer dependency to the new minimum supported version for WPCS.[[BR]] Note: the Composer PHPCS installer plugin is no longer explicitly required as it is now a dependency of WPCS, so the dependency is inherited automatically.
* Updates the ruleset for WPCS 3.0.0. This includes:
* Raising the memory limit to be on the safe side as WPCS 3.0.0 contains a lot more sniffs.
* Removing explicit inclusions of extra rules, which have now been added to the `WordPress-Core` ruleset..
* Updating property names for select sniffs.
* Updating one exclusion — the `WordPress.CodeAnalysis.AssignmentInCondition` sniff has been (partially) replaced by the `Generic.CodeAnalysis.AssignmentInCondition` sniff.
* Adding one new exclusion.
* Downgrades one new error to a warning.[[BR]] The `Generic.Files.OneObjectStructurePerFile` sniff enforces that there is only one OO structure declaration per file. At this time, this sniff would yield 29 errors. By downgrading the sniff to a ''warning'', the build can pass and the issues can be fixed in due time. For now, the test directory will be excluded until the issues are fixed (as the test directory CS run does not allow for warnings).
* Updates ignore annotations for WPCS 3.0.0.
Reference: [https://github.com/WordPress/WordPress-Coding-Standards/releases/tag/3.0.0 WPCS 3.0.0 release notes].
Follow-up to [43571], [44574], [45600], [47927].
Props jrf, jorbin, desrosj.
See #59161.
git-svn-id: https://develop.svn.wordpress.org/trunk@56695 602fd350-edb4-49c9-b593-d223f7449a82
Using script tag helper functions allows plugins to employ the `wp_script_attributes` and `wp_inline_script_attributes` filters to inject the `nonce` attribute to apply Content Security Policy (e.g. Strict CSP). Use of helper functions also simplifies logic in `WP_Scripts`.
* Update `wp_get_inline_script_tag()` to wrap inline script in CDATA blocks for XHTML-compatibility when not using HTML5.
* Ensure the `type` attribute is printed first in `wp_get_inline_script_tag()` for back-compat.
* Wrap existing `<script>` tags in output buffering to retain IDE supports.
* In `wp_get_inline_script_tag()`, append the newline to `$javascript` before it is passed into the `wp_inline_script_attributes` filter so that the CSP hash can be computed properly.
* In `the_block_template_skip_link()`, opt to enqueue the inline script rather than print it.
* Add `ext-php` to `composer.json` under `suggest` as previously it was an undeclared dependency for running PHPUnit tests.
* Update tests to rely on `DOMDocument` to compare script markup, normalizing unsemantic differences.
Props westonruter, spacedmonkey, flixos90, 10upsimon, dmsnell, mukesh27, joemcgill, swissspidy, azaozz.
Fixes#58664.
See #39941.
git-svn-id: https://develop.svn.wordpress.org/trunk@56687 602fd350-edb4-49c9-b593-d223f7449a82
[https://github.com/sebastianbergmann/phpunit/blob/9.6/ChangeLog-9.6.md#961---2023-02-03 PHPUnit 9.6.1] deprecated the `assertObjectHasAttribute()` and `assertObjectNotHasAttribute()` methods, leading to deprecation notices in a number of tests.
[https://github.com/sebastianbergmann/phpunit/blob/10.1.3/ChangeLog-10.1.md#1010---2023-04-14 PHPUnit 10.1.0] brought the methods back by popular request, though renamed as `assertObjectHasProperty()` and `assertObjectNotHasProperty()`, to prevent confusion with PHP 8.0 attributes.
This meant that users which cannot (yet) upgrade to PHPUnit 10.1+ would always have deprecation notices for these methods without recourse. So, after much discussion, the new methods have been backported to [https://github.com/sebastianbergmann/phpunit/blob/9.6/ChangeLog-9.6.md#9611---2023-08-19 PHPUnit 9.6.11], leaving just the 10.0.x series with a deprecation notice and no recourse.
What does this mean for WordPress?
WordPress uses the [https://github.com/Yoast/PHPUnit-Polyfills PHPUnit Polyfills] to be able to write tests for the most recent versions of PHPUnit, with the Polyfills taking care of polyfilling any new PHPUnit methods on older PHPUnit versions.
* The PHPUnit Polyfills 1.x series supports PHPUnit 4.x to 9.x.
* The PHPUnit Polyfills 2.x series supports PHPUnit 5.x to 10.x.
WordPress currently runs against PHPUnit 6.x to 9.x with PHPUnit Polyfills 1.x, while the new methods were previously only included in PHPUnit Polyfills 2.0.0+, as they were introduced in PHPUnit 10.x.
Since the `assertObjectHasProperty()` and `assertObjectNotHasProperty()` methods have been backported to PHPUnit 9.x, the PHPUnit Polyfills will now include these methods in the 1.x series as well.
By upgrading to the latest [https://github.com/Yoast/PHPUnit-Polyfills/releases/tag/1.1.0 PHPUnit Polyfills 1.1.0] release, we can get rid of the deprecation notices related to the use of the `assertObjectHasAttribute()` and `assertObjectNotHasAttribute()` methods.
This could have implications for plugins or themes running integration tests with WordPress if they have set their PHPUnit Polyfills dependency to a fixed version or have a too strict version constraint (limiting the PHPUnit Polyfills to the 1.0.x series). The solution for those plugins or themes is to update their version constraints for the PHPUnit Polyfills to allow for the 1.1.x series.
Follow-up to [51559], [51598].
Props jrf, ayeshrajans.
Fixes#59150.
git-svn-id: https://develop.svn.wordpress.org/trunk@56421 602fd350-edb4-49c9-b593-d223f7449a82
This also removes the random compat library which is no longer necessary, and adjusts unit tests and CI workflows that no longer need to take PHP 5.6 into account.
Thank you for your service, PHP 5. Onwards!
Props SergeyBiryukov, mukesh27, dingo_d, audrasjb, jrf, costdev, azaozz, JavierCasares, hellofromTonya, samiamnot, spacedmonkey, masteradhoc, knutsp, garyjones, chanthaboune
Fixes#57345
git-svn-id: https://develop.svn.wordpress.org/trunk@56141 602fd350-edb4-49c9-b593-d223f7449a82
When running the full test suite locally via `npm run grunt phpunit` or `composer test`, it is not uncommon for the test run to exceed the Composer's default timeout, causing an error in the middle of the test output:
{{{
The process "..." exceeded the timeout of 300 seconds.
}}}
This commit disables the process timeout for the `composer test` command, allowing the test run to complete successfully.
Follow-up to [47881], [51016].
Props ironprogrammer, robinwpdeveloper, SergeyBiryukov.
Fixes#55919.
git-svn-id: https://develop.svn.wordpress.org/trunk@54355 602fd350-edb4-49c9-b593-d223f7449a82
The `dealerdirect/phpcodesniffer-composer-installer` Composer plugin is used to register external PHPCS standards with PHPCS.
As of Composer 2.2, Composer plugins need to be explicitly allowed to run. This commit adds the necessary configuration for that to prevent Composer asking every single time `composer install` or `composer update` is run.
Reference: [https://blog.packagist.com/composer-2-2/#more-secure-plugin-execution Composer 2.2: More secure plugin execution].
Props jrf, johnbillion.
Fixes#54686.
git-svn-id: https://develop.svn.wordpress.org/trunk@52412 602fd350-edb4-49c9-b593-d223f7449a82
The PHPUnit Polyfills are, since [51559], a required dependency for the WP test suite and, by extension, for plugin/theme integration test suites which are based on and use (parts of) the WP core test suite.
However, plugin/theme integration test suites may not use a full WordPress installation.
This commit:
* Removes the presumption that a full WP install, including `vendor` directory, will be available when the test `bootstrap.php` file is run.
* Makes the loading of the PHPUnit Polyfills autoload file more flexible by:
* Checking if the autoload class contained within the autoload file is already available before attempting to load the file.[[BR]]
This allows for plugin/theme integration test suites to load the `phpunitpolyfills-autoload.php` file from any location, as long as it is loaded before the WP core test `bootstrap.php` file is run.
* Allowing for the path to an arbitrary installation location for the PHPUnit Polyfills to be passed as a constant.[[BR]]
As long as the provided location is a valid file path and the `phpunitpolyfills-autoload.php` file exists in the provided location, that file will be loaded.[[BR]]
The constant can be declared in a plugin/theme integration test suite native test bootstrap file, or in the `wp-tests-config.php` file, or even in a `phpunit.xml[.dist]` file via `<php><const name="WP_TESTS_PHPUNIT_POLYFILLS_PATH" value="path/to/yoast/phpunit-polyfills"/></php>`.
* Adds a version check for the PHPUnit Polyfills to prevent a mismatch between the version of the package expected by WordPress and the version used by plugins/themes.[[BR]]
The version this checks for should be in line with the minimum version requirement for the PHPUnit Polyfills as declared in the `composer.json` file.[[BR]]
This version number should only be updated when new features added in later PHPUnit Polyfills releases are actually used in the WP core test suite.
* Adds appropriate error messages for every possible error condition.
* Upgrades the PHPUnit Polyfills to version 1.0.1, which now includes a version constant.
Follow-up to [51559-51577].
Props jrf, hellofromTonya, swissspidy, jeherve, thomasplevy, SergeyBiryukov.
See #46149.
git-svn-id: https://develop.svn.wordpress.org/trunk@51598 602fd350-edb4-49c9-b593-d223f7449a82
**composer.json**:
Remove the PHPUnit dependency in favor of allowing the PHPUnit Polyfills library to manage the supported PHPUnit version. This automatically now widens the supported PHPUnit versions to 5.7.21 to 9.5.8 (current).
Letting the PHPUnit Polyfills handle the version constraints for PHPUnit prevents potential version conflicts in the future, as well as allows WordPress to benefit straight away when a new PHPUnit version would be released and the PHPUnit Polyfills package adds support for that PHPUnit version.
**Test Bootstrap**
Update the supported version number for PHPUnit 5.x, as the minimum PHPUnit 5.x version supported by the PHPUnit Polyfills is PHPUnit 5.7.21, and remove the PHPUnit maximum.
**.gitignore and svn:ignore:**
Add the PHPUnit cache file to the list of files to be ignored.
Since PHPUnit 8, PHPUnit has a built-in caching feature which creates a `.phpunit.result.cache` file. This file should not be committed.
Follow-up to [40536], [40853], [44701], [51559-51573].
Props jrf.
See #46149.
git-svn-id: https://develop.svn.wordpress.org/trunk@51574 602fd350-edb4-49c9-b593-d223f7449a82
The PHPUnit Polyfills package is an add-on for PHPUnit, which works around common issues for writing PHPUnit cross-version compatible tests.
Features:
* It offers a full set of polyfills for assertions and expectations introduced in PHPUnit since PHPUnit 4.8.
* It offers two generic TestCases which include these polyfills, but also solve the `void` return type issue for the fixtures methods.
* It offers a PHPUnit cross-version solution for the changes to the PHPUnit `TestListener` implementation.
* Supports PHPUnit 4.8 – current.
* Supports and is compatible with PHP 5.4 – current.
The package has no outside dependencies, other than PHPUnit, is actively maintained and endorsed by the maintainer of PHPUnit itself (the only package of its kind which has ever been endorsed).
Props jrf, hellofromTonya, johnbillion, netweb, SergeyBiryukov.
See #46149.
git-svn-id: https://develop.svn.wordpress.org/trunk@51559 602fd350-edb4-49c9-b593-d223f7449a82
This prevents the classes from being loaded automatically via the `autoload-dev` directives when a Composer-installed PHPUnit 5.x or 6.x version is used, as that would break the test run.
It is expected that this autoloader will be removed soon, as it should no longer be needed when the PHPUnit version constraints are widened.
Notes:
* The autoloader file will be loaded from the Test bootstrap.
* The autoloader will always be registered and directed to queue itself _before_ the Composer autoload file (which will already have been registered).
* The autoloader will only actually load the WP copies of the files/classes when PHP 8.0 in combination with PHPUnit 7.x is detected. In all other cases, the autoloader will bow out, which effectively then defers to the Composer autoload file to load the files as shipped with the installed PHPUnit version.
Follow-up to [48957], [49037], [51543].
Props jrf.
See #47381.
git-svn-id: https://develop.svn.wordpress.org/trunk@51544 602fd350-edb4-49c9-b593-d223f7449a82
This makes it easier to run unit tests against multiple different PHP versions.
There is currently no reason to have a `composer.lock` file as:
* External runtime dependencies are not managed via Composer.
* Managed updates of the non-runtime dependencies can be done by locking the version used in the `composer.json` file to a precise version instead of using a `composer.lock` file.
* Having the `composer.lock` file in place makes it a lot more difficult to run the tests against all supported PHP versions.
With these considerations in mind, the lock file is now removed from version control and added to `.gitignore` and `svn:ignore`.
Version constraints for the current dev dependencies are adjusted accordingly:
* PHPUnit now explicitly declares in its version constraints that PHPUnit 5.x, 6.x, and 7.x are supported. The minimum supported version for PHPUnit 5.x has been raised from 5.4 to 5.7, which in practice was already the version used for running the tests on PHP 5.6.
* PHPCompatibilityWP is effectively updated to version 2.1.2 with the positive impact that a few new constants polyfilled in WP 5.8 are now accounted for (excluded from being flagged).
* PHP_CodeSniffer is declared as an explicit dependency to ensure that updates to it will always be explicitly managed instead of inherited.
* The DealerDirect Composer plugin is effectively updated to version 0.7.1 without impact.
Follow-up to [42960], [46290], [47881], [48957].
Props jrf, johnbillion, desrosj, ayeshrajans, aristath, hellofromTonya, SergeyBiryukov.
See #47381.
git-svn-id: https://develop.svn.wordpress.org/trunk@51543 602fd350-edb4-49c9-b593-d223f7449a82
This allows other users of the WordPress unit test suite framework to run their own unit tests without needing the GD extension, which should only be a requirement if running core tests.
Follow-up to [49535].
Props jamescollins.
Fixes#50640.
git-svn-id: https://develop.svn.wordpress.org/trunk@49571 602fd350-edb4-49c9-b593-d223f7449a82
Add the GD extension as a hard requirement.
This improves the reliability of the test suite and ensures that if the test infrastructure changes in the future and a platform requirement such as GD accidentally gets removed, the tests fail with an appropriate error message.
Follow-up to [48592].
Props ayeshrajans, jrf, johnbillion.
Fixes#50640.
git-svn-id: https://develop.svn.wordpress.org/trunk@49535 602fd350-edb4-49c9-b593-d223f7449a82
This updates the `dealerdirect/phpcodesniffer-composer-installer` package to allow installing version `0.7.0` which supports composer 2.0.
Props itowhid06, jrf.
Fixes#51624.
git-svn-id: https://develop.svn.wordpress.org/trunk@49306 602fd350-edb4-49c9-b593-d223f7449a82
* Replace the `Match` interface with `ParametersMatch`, to avoid parse errors due to `match` being a reserved keyword in PHP 8.
* Replace `ReflectionParameter::getClass()` usage, which is deprecated in PHP 8.
This allows tests relying on the `getMockForAbstractClass()` and `getMockBuilder()` methods to run again on PHP 8.
When the test suite is updated for compatibility with PHPUnit 9.x, these overrides can be removed.
Follow-up to [48972].
See #50913, #50902.
git-svn-id: https://develop.svn.wordpress.org/trunk@49037 602fd350-edb4-49c9-b593-d223f7449a82
This helps setting up the correct version of PHPUnit to run WordPress core tests locally and for using it as source for code autocompletion in tests. Also introduces a new Composer script `test` to run the PHPUnit tests.
Props welcher, ayeshrajans, vinkla, johnbillion, Rarst, netweb, ocean90.
Fixes#46815.
git-svn-id: https://develop.svn.wordpress.org/trunk@47881 602fd350-edb4-49c9-b593-d223f7449a82
Also, move all arguments up to the top of the custom ruleset to make it easier to understand the conditions the ruleset is run under.
Props desrosj, jrf.
See #46152.
git-svn-id: https://develop.svn.wordpress.org/trunk@46291 602fd350-edb4-49c9-b593-d223f7449a82
This change introduces a new Composer script, `compat` that will scan the codebase for (detectable) potential PHP compatibility issues using the `PHP_CodeSniffer` and a custom ruleset based off of the `PHPCompayibilityWP` ruleset (`phpcompat.xml.dist`).
The command will be run as a separate job within each Travis build. While many compatibility issues and false positives have already been corrected in this commit and other Trac tickets, there are still some remaining. For that reason, the job is allowed to fail while the remainder of the potential compatibility issues are investigated and addressed. After those are resolved, the job should be set as required to pass to help prevent new compatibility issues from being introduced.
Props desrosj, jrf, all PHPCompatibilityWP and PHPCompatibility contributors.
Fixes#46152.
git-svn-id: https://develop.svn.wordpress.org/trunk@46290 602fd350-edb4-49c9-b593-d223f7449a82
Prefixing a script command with `@php ` ensures that the script runs with the same version of PHP that Composer is installed with (and not the system default).
This change also updates the `phpcs` and `phpcbf` commands to use the version of PHPCS installed by Composer.
The `—standard` is no longer explicitly passed to the command. By default, PHPCS will look for `phpcs.xml.dist`, which is the name of the custom standards file currently in Core.
Props dingo_d, jrf.
Fixes#47853.
git-svn-id: https://develop.svn.wordpress.org/trunk@46187 602fd350-edb4-49c9-b593-d223f7449a82
The remaining error-level coding standards issues (specifically, associated with the sniffs `WordPress.PHP.YodaConditions.NotYoda`, `WordPress.NamingConventions.ValidVariableName.VariableNotSnakeCase`, `WordPress.DB.PreparedSQL.InterpolatedNotPrepared`, `WordPress.DB.PreparedSQL.NotPrepared`, and `WordPress.Files.FileName.InvalidClassFileName`) are marked as warnings, until they're all addressed.
This change allows us to run linting on Travis across the entire codebase, ensuring no other error-level violations can be introduced.
Additionally, PHPCS will now cache results locally, drastically improving performance for subsequent checks: scanning the entire codebase takes 1-2 minutes the first time, and less than one second for subsequent checks.
See #47632.
git-svn-id: https://develop.svn.wordpress.org/trunk@45665 602fd350-edb4-49c9-b593-d223f7449a82
Noteable changes:
- WPCS now throws warnings when non-strict comparisons are used. There are quite a few of them in Core. 🙃
- WPCS now detects and warns for assignments in loop conditions.
See #47632.
git-svn-id: https://develop.svn.wordpress.org/trunk@45600 602fd350-edb4-49c9-b593-d223f7449a82
A few sniffs have been renamed, this change includes the relevant `phpcs:ignore` comment updates.
Fixes#46002.
git-svn-id: https://develop.svn.wordpress.org/trunk@44645 602fd350-edb4-49c9-b593-d223f7449a82
WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
git-svn-id: https://develop.svn.wordpress.org/trunk@43571 602fd350-edb4-49c9-b593-d223f7449a82
`.gitignore` + `svn:ignore`:
* Add the typical filenames of overloaded PHPCS configs to `.gitignore`.
Composer:
* Use the `develop` (Packagist `dev-master`) version of WPCS as it contains lots of bugfixes.
* Remove the PHPCS dependency. This is a dependency of WPCS, not of WP Core itself. This will also make sure that the PHPCS version used is always one which is supported by WPCS.
* Refreshed the `composer.lock` file.
PHPCS ruleset:
* Removed a reference to a sniff which doesn't exist in WPCS yet.
* Use the PHPCS 3.x `basepath` option to clean up the file paths PHPCS shows in the reports.
* Use the PHPCS 3.x `parallel` option to enable parallel scanning whenever possible to speed up the scans.
* Whitelist the `wp-includes/l10n.php` file from issues being reported by the `WordPress.WP.I18n` sniff.
Fixes#44366.
git-svn-id: https://develop.svn.wordpress.org/trunk@43348 602fd350-edb4-49c9-b593-d223f7449a82
This allows Core developers to more easily run coding standards checks on PHP code.
Props netweb.
Fixes#43558.
git-svn-id: https://develop.svn.wordpress.org/trunk@42960 602fd350-edb4-49c9-b593-d223f7449a82
To fiddle around with what it does, run `composer install` from the project root. If you do not have Composer installed:
https://getcomposer.org/doc/00-intro.md#locally
tl;dr for Mac/Homebrew users: `brew install composer`
Classes from `wp-includes` and `wp-admin` are eligible for autoloading via `autoload.classmap`. Through a tornado of recent commits, many unsuitable files have been transitioned into a more acceptable state for autoloading: 1 file per class, no side effects.
The file bootstrap in `wp-settings.php` can transition into `autoload.files`. This will be done with care and attention.
See #36335.
git-svn-id: https://develop.svn.wordpress.org/trunk@38384 602fd350-edb4-49c9-b593-d223f7449a82
