Release WordPressCS 3.2.0 #2558
Draft
+1,417
−355
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from 3 to 4. - [Release notes](https://github.com/codecov/codecov-action/releases) - [Changelog](https://github.com/codecov/codecov-action/blob/main/CHANGELOG.md) - [Commits](codecov/codecov-action@v3...v4) --- updated-dependencies: - dependency-name: codecov/codecov-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
…ecov/codecov-action-4 GH Actions: Bump codecov/codecov-action from 3 to 4
Okay, so apparently, there is a long-standing bug in the Microsoft package deploy process which caused `apt-get update` to fail in the first half hour after Microsoft has deployed a package. The failure looks like this: ``` E: Failed to fetch https://packages.microsoft.com/ubuntu/22.04/prod/dists/jammy/InRelease Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?) ``` As this only happens intermittently (after a MS package deploy), the chance of running into this bug are slim, but guess what: today I ran into it. This change to the workflow is intended to prevent the next person running into this issue from having to waste time on figuring this out. By splitting the "Install xmllint" step into two steps: one doing the `apt-get update` and one doing the actual install and making the first step one which is allowed to `continue-on-error`, this issue should hopefully not crop up anymore. Any errors in the `apt-get update` step will now be ignored and as most errors which could potentially come from that step are irrelevant for the rest of the job anyway, this is fine. If a relevant error would be surfaced, the next step (the xmllint install), will fail the job anyway. Refs: * actions/runner-images#3410 * dotnet/core#4167
…ass-apt-get-update GH Actions: work around intermittent apt-get errors
* Composer: avoid writing a lock file * Allow creation of composer.lock during some tests
…ns_ValidFunctionName_Documentation Add documentation for WordPress.NamingConventions.ValidFunctionName
* Double checked that all existing XML docs have the `xsi` attributes and schema reference of the `<documentation>` element. * Verified that the contents of `<standard>` elements is consistently indented (with four spaces). * Verified that all `<code>` `title` attributes use proper punctuation.
* Docs: add documentation for WordPress.DB.PreparedSQL --------- Co-authored-by: Juliette <663378+jrfnl@users.noreply.github.com>
…eaks Documentation: various consistency fixes
Follow up on 2468 Darn! Looks like I forgot to push an update to the commit. Sorry about that. This adds the capitalization consistency fixes for the `<code>` `title` attributes. Co-authored-by: jrfnl <jrfnl@users.noreply.github.com>
* ✨ New WordPress.WP.GetMetaSingle sniff * This sniff warns when get_*_meta() and get_metadata*() functions are used with the $meta_key/$key param, but without the $single parameter. This could lead to unexpected behavior as an array will be returned, but a string might be expected. --------- Co-authored-by: Juliette <663378+jrfnl@users.noreply.github.com>
) This commit fixes the test failure seen in PR 2499. The test failure was surfaced due to a new exception in PHPCS (see: PHPCSStandards/PHP_CodeSniffer 524), which will be included in PHPCS 3.11.0. The test failure highlighted that the above mentioned PHPCS PR needs a follow-up with some extra defensive coding, however, that defensive coding is needed in a part in PHPCS which does the error handling for PHP notices being encountered, i.e. the throwing of `Internal.Exception` errors. This implied there was also an underlying issue in WPCS causing the `Internal.Exception`, which apparently was only triggered when the fixer was being run. > Note: the fact that `Internal.Exception`s during a PHPCBF run are being suppressed is a known issue, but fixing that is not that easy, so that definitely won't happen before PHPCS 4.0 (and may not even make it into 4.0). See: squizlabs/PHP_CodeSniffer 2871 Either way, I've looked into the `Internal.Exception` now. The error was as follows: ``` An error occurred during processing; checking has been aborted. The error message was: PHPCSUtils\Utils\GetTokensAsString::getString(): Argument #2 ($start) must be a stack pointer which exists in the $phpcsFile object, 8 given. The error originated in the AbstractClassRestrictionsSniff.php sniff on line 131. ``` The additional defensive coding added in this commit, fixes the issue. Co-authored-by: jrfnl <jrfnl@users.noreply.github.com>
... to make sure this is checked a little more regularly.
Release checklist: add new action item
... to satisfy shellcheck rule SC2086: "Double quote to prevent globbing and word splitting". Ref: https://www.shellcheck.net/wiki/SC2086
This commit updates various sniffs to use `return $phpcsFile->numTokens` instead of `return ($phpcsFile->numTokens + 1)`. If a sniff file contains 50 tokens, the last `$stackPtr` will be 49, so returning `50` will already get us passed the end of the token stack and the `+ 1` is redundant. Includes changing a few plain `return` statements to `return $phpcsFile->numTokens` for efficiency.
This Monday, [PHPStan 2.0 will be released](https://phpc.social/@OndrejMirtes/113441109253809720). I've done some preliminary scans with PHPStan 2.0-dev to check if this would have an impact on this codebase and as things are, this would mean the build would start to fail. For now, I'm proposing to make a small change in the GH Actions workflow to explicitly use PHPStan 1.x. This buys us some time to evaluate PHPStan 2.0 properly and to make any changes needed to make the codebase compatible with PHPStan 2.x when we're ready for it.
Even though PR 2507 ensured we didn't automatically move onto PHPStan 2.0, the build is still failing as PHPStan 1.12.9 contained a change which causes a new error to show up. This commit fixes [the newly flagged issue](https://github.com/WordPress/WordPress-Coding-Standards/actions/runs/11775908547/job/32797254994) to allow builds to pass again. Ref: https://github.com/phpstan/phpstan/releases/tag/1.12.9
* Builds against PHP 8.4 are no longer allowed to fail. * Add _allowed to fail_ build against PHP 8.5. * Update the "tested against" badge in the README. Ref: https://www.php.net/releases/8.4/en.php
Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from 4 to 5. - [Release notes](https://github.com/codecov/codecov-action/releases) - [Changelog](https://github.com/codecov/codecov-action/blob/main/CHANGELOG.md) - [Commits](codecov/codecov-action@v4...v5) --- updated-dependencies: - dependency-name: codecov/codecov-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…eference-sniff
Add `rest_sanitize_boolean()` to unslashing sanitizing functions
Follow up on PR 2472 - safeguarding that no new typos get introduced.
Notes:
* The "Typos" tool is known for having a low false positive ratio and being aware of code contexts. However, this also means, it may at times miss some things.
When selecting it, I deemed the low false positive ratio more important.
* The language has been set to `en-US` as that's the language predominantly used for the WordPress documentation.
This does mean that various phrases using `en-GB` spelling will need to be fixed/updated.
Ref: https://github.com/crate-ci/typos
Mostly US English vs UK English and as WP Core predominantly uses US English, I think we should standardize on that for this spellcheck as well. Note: where text was copied from the rules on https://developer.wordpress.org/coding-standards/ (typically to the `ruleset.xml` files), the text upstream has been updated via WordPress/wpcs-docs#151.
GH Actions: add a basic spellcheck CI check + fix some typos
The previous description contained information about the ContextHelper class.
…use_of_global_constant()` The parameter description incorrectly mentioned that `$strackPtr` should be the pointer to a function call token while it actually should be the pointer to a T_STRING token.
…d-param-description
…r fork The `quicktest` workflow runs the code coverage for merges to `develop`, but wasn't limited to this repo. The net effect of this is failing builds for contributors who have actions enabled on their fork and who update the `develop` branch in their own fork. The reason for the failure is that they don't have access to the `CODECOV_TOKEN`. This commit changes the conditions on when to run the tests normally and when to run with code coverage to take the organisation where the repo lives into account. That should prevent the failing builds.
…-qtest-in-forks GH Actions/quicktest: fix failing build when contributors update their fork
Not claiming completeness, but just fixing up some I ran into.
…tant type This commit modifies one of the existing class constants in the code used in the `WordPress.NamingConventions.PrefixAllGlobal` tests to have a type. This is just to ensure that there is a test for typed class constants added in PHP 8.3 as this sniff listens to the `T_CONST` token. The sniff was already handling typed class constants correctly and no change to the sniff code is needed.
This commit adds a few tests using type class constants to the `WordPress.WP.CapitalPDangit` tests. This is just to ensure that the part of the sniff code that checks for `T_CONST` tokens to ignore constant declarations using the `const` keyword works correctly with typed class constants added in PHP 8.3. The sniff was already handling typed class constants correctly, and no change to the sniff code is needed.
While adding a new test to `CapitalPDangitUnitTest.1.inc`, I noticed unnecessary trailing spaces in this file. Instead of removing them just for this one test, I opted to create this commit removing unnecessary trailing spaces from all test files using `Squiz.WhiteSpace.SuperfluousWhitespace`. I'm including only the files where it was easy to check that the spaces were not added intentionally.
Before this commit, `AbstractClassRestrictionsSniff::is_targetted_token()` would name an anonymous class as "\class" or "\readonly" (in the case of readonly anonymous classes). While this would not cause false positives as it is not possible for a class to be named "class" or "readonly", it is not the correct behavior. This commit improves how this method handles anonymous classes by returning `false` early as those classes don't have a name. Includes tests for readonly anonymous classes. It was not necessary to include more tests for normal anonymous classes as the existing tests are already enough.
Co-authored-by: Juliette <663378+jrfnl@users.noreply.github.com>
Co-authored-by: Juliette <663378+jrfnl@users.noreply.github.com>
Update list based sniffs for WP 6.8.1
The minimum version should be three versions behind the latest WP release, so what with 6.8.2 being the latest release, it should now become 6.5. Includes updating the tests to match. Previous: 2121, 2321. 2436
…2544) ... but pass them to a dedicated `process_first_class_callable()` method instead to allow sniffs to decide whether to flag these or not. Typical use-case for why first class callables should not be ignored by default: A sniff which ALWAYS flags the use of a certain function, but has different error messages depending on whether parameters are passed or not. In that situation, I believe first class callables should be treated the same as other uses of the target function. First class callables are basically syntax sugar for closures (example: https://3v4l.org/cra8s) and if the sniff would flag the use of the target function within a closure, it is only reasonable to also flag the use of the target function as a first class callable. This commit implements this. The commit does not include tests as there are no sniffs in WPCS for which the above would apply. However, I have manually tested this change via a sniff in an external standard for which this change is relevant.
…sion Update the `minimum_wp_version` to WP 6.5
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please do add approvals if you agree as otherwise we won't be able to release.
PR for tracking changes for the 3.2.0 release. Target release date: Thursday July 24, 2025.
Release checklist
General
composer.json- PR Composer: raise the minimum supported PHPCSUtils version to 1.1.0 + fix CI #2532, Composer: bump PHP Parallel Lint #2533MinimumWPVersionTrait::$default_minimum_wp_versionand if so, action it - PR Update theminimum_wp_versionto WP 6.5 #2553✏️ Make sure the "last updated" annotation in the docblocks for these lists has also been updated!
List based sniffs:
WordPress.WP.ClassNameCase- PR Update list based sniffs for WP 6.8.1 #2537WordPress.WP.DeprecatedClasses- N/AWordPress.WP.DeprecatedFunctions- PR Update list based sniffs for WP 6.8.1 #2537WordPress.WP.DeprecatedParameters- PR Update list based sniffs for WP 6.8.1 #2537WordPress.WP.DeprecatedParameterValues- PR Update list based sniffs for WP 6.8.1 #2537$allowed_core_constantsinWordPress.NamingConventions.PrefixAllGlobals- N/A$pluggable_functionsinWordPress.NamingConventions.PrefixAllGlobals- PR Update list based sniffs for WP 6.8.1 #2537$pluggable_classesinWordPress.NamingConventions.PrefixAllGlobals- N/A$target_functionsinWordPress.Security.PluginMenuSlug- N/A$reserved_namesinWordPress.NamingConventions.ValidPostTypeSlug- N/A$wp_time_constantsinWordPress.WP.CronInterval- N/A$known_test_classesinIsUnitTestTrait- N/ARelease prep
✏️ Remember to add a release link at the bottom!
README(if applicable) - PR #xxxRelease
main(careful, GH defaults todevelop!) & copy & paste the changelog to it.✏️ Check if anything from the link collection at the bottom of the changelog needs to be copied in!
developto be equal tomain.After release
Publicize