Release WordPressCS 3.3.0

.github/CONTRIBUTING.md

@@ -1,6 +1,8 @@
+# Contributing to the WordPress Coding Standards
+
 Hi, thank you for your interest in contributing to the WordPress Coding Standards! We look forward to working with you.
 
-# Reporting Bugs
+## Reporting Bugs
 
 Please search the repo to see if your issue has been reported already and if so, comment in that issue instead of opening a new one.
 
@@ -9,48 +11,69 @@ Running `phpcs` with the `-s` flag will show the name of the sniff with each err
 
 Bug reports containing a minimal code sample which can be used to reproduce the issue are highly appreciated as those are most easily actionable.
 
-## Upstream Issues
+### Upstream Issues
 
 Since WordPressCS employs many sniffs that are part of PHP_CodeSniffer itself or PHPCSExtra, sometimes an issue will be caused by a bug in PHPCS or PHPCSExtra and not in WordPressCS itself.
 If the error message in question doesn't come from a sniff whose name starts with `WordPress`, the issue is probably a bug in PHPCS or PHPCSExtra.
 
 * Bugs for sniffs starting with `Generic`, `PEAR`, `PSR1`, `PSR2`, `PSR12`, `Squiz` or `Zend` should be [reported to PHPCS](https://github.com/PHPCSStandards/PHP_CodeSniffer/issues).
 * Bugs for sniffs starting with `Modernize`, `NormalizedArrays` or `Universal` should be [reported to PHPCSExtra](https://github.com/PHPCSStandards/PHPCSExtra/issues).
 
-# Contributing patches and new features
+## Contributing patches and new features
+
+### Tips for Successful PRs
+
+We welcome contributions from everyone, and want your PR to have the best chance of being reviewed and merged. To help with this, please keep the following in mind:
+
+* **Respect copyright and licensing.**
+  Only submit code that you have written yourself or that comes from sources where the license clearly allows inclusion. Submitting code that infringes on copyright or licensing terms puts both you and the project at legal risk, and such contributions cannot be accepted.
+
+* **Do not submit AI-generated code.**
+  Pull requests containing AI-generated code are not acceptable. Beyond copyright and licensing uncertainties, AI-generated contributions consistently require disproportionate amounts of maintainer time to review, correct, or rewrite. This wastes limited project resources and slows progress for everyone. Submitting AI-generated code may be treated as a violation of our [Code of Conduct](../CODE_OF_CONDUCT.md).
 
-## Branches
+* **Focus on quality and clarity.**
+  Take time to explain *why* the change is needed, and include tests or examples where appropriate. Clear, self-written explanations make it more straightforward for reviewers to understand what you are trying to achieve.
+
+* **Think about long-term maintainability.**
+  Code should align with WordPress Coding Standards and be written in a way that others can readily read, understand, and maintain.
+
+* **Be collaborative.**
+  If you're unsure about an approach, open an issue first to start a conversation.
+
+By following these tips, you'll save time for both yourself and the maintainers — and increase the likelihood that your contribution can be merged smoothly.
+
+### Branches
 
 Ongoing development will be done in the `develop` branch with merges to `main` once considered stable.
 
 To contribute an improvement to this project, fork the repo, run `composer install`, make your changes to the code, run the unit tests and code style checks by running `composer check-all`, and if all is good, open a pull request to the `develop` branch.
 Alternatively, if you have push access to this repo, create a feature branch prefixed by `feature/` and then open an intra-repo PR from that branch to `develop`.
 
-# Considerations when writing sniffs
+## Considerations when writing sniffs
 
-## Public properties
+### Public properties
 
 When writing sniffs, always remember that any `public` sniff property can be overruled via a custom ruleset by the end-user.
 Only make a property `public` if that is the intended behavior.
 
 When you introduce new `public` sniff properties, or your sniff extends a class from which you inherit a `public` property, please don't forget to update the [public properties wiki page](https://github.com/WordPress/WordPress-Coding-Standards/wiki/Customizable-sniff-properties) with the relevant details once your PR has been merged into the `develop` branch.
 
-# Unit Testing
+## Unit Testing
 
-## Pre-requisites
+### Pre-requisites
 * WordPress-Coding-Standards
-* PHP_CodeSniffer 3.13.0 or higher
+* PHP_CodeSniffer 3.13.4 or higher
 * PHPCSUtils 1.1.0 or higher
-* PHPCSExtra 1.4.0 or higher
-* PHPUnit 4.x - 9.x
+* PHPCSExtra 1.5.0 or higher
+* PHPUnit 8.x - 9.x
 
 The WordPress Coding Standards use the `PHP_CodeSniffer` native unit test framework for unit testing the sniffs.
 
-## Getting ready to test
+### Getting ready to test
 
 Presuming you have cloned WordPressCS for development, to run the unit tests you need to make sure you have run `composer install` from the root directory of your WordPressCS git clone.
 
-## Custom develop setups
+### Custom develop setups
 
 If you are developing with a stand-alone PHP_CodeSniffer (git clone) installation and want to use that git clone to test WordPressCS, there are three extra things you need to do:
 1. Install [PHPCSUtils](https://github.com/PHPCSStandards/PHPCSUtils).
@@ -73,7 +96,7 @@ If you are developing with a stand-alone PHP_CodeSniffer (git clone) installatio
         </php>
     ```
 
-## Running the unit tests
+### Running the unit tests
 
 From the root of your WordPressCS install, run the unit tests like so:
 ```bash
@@ -85,32 +108,32 @@ phpunit --filter WordPress /path/to/PHP_CodeSniffer/tests/AllTests.php
 
 Expected output:
 ```
-PHPUnit 9.6.15 by Sebastian Bergmann and contributors.
+PHPUnit 9.6.26 by Sebastian Bergmann and contributors.
 
-Runtime:       PHP 8.3.0
+Runtime:       PHP 8.4.12
 Configuration: /WordPressCS/phpunit.xml.dist
 
-.........................................................         57 / 57 (100%)
+............................................................      60 / 60 (100%)
 
-201 sniff test files generated 744 unique error codes; 50 were fixable (6%)
+210 sniff test files generated 775 unique error codes; 50 were fixable (6%)
 
-Time: 10.19 seconds, Memory: 40.00 MB
+Time: 00:03.396, Memory: 60.00 MB
 
-OK (57 tests, 0 assertions)
+OK (60 tests, 6 assertions)
 ```
 
-## Unit Testing conventions
+### Unit Testing conventions
 
-If you look inside the `WordPress/Tests` subdirectory, you'll see the structure mimics the `WordPress/Sniffs` subdirectory structure. For example, the `WordPress/Sniffs/PHP/POSIXFunctionsSniff.php` sniff has its unit test class defined in `WordPress/Tests/PHP/POSIXFunctionsUnitTest.php` which checks the `WordPress/Tests/PHP/POSIXFunctionsUnitTest.inc` test case file. See the file naming convention?
+If you look inside the `WordPress/Tests` subdirectory, you'll see the structure mimics the `WordPress/Sniffs` subdirectory structure. For example, the `WordPress/Sniffs/PHP/TypeCastsSniff.php` sniff has its unit test class defined in `WordPress/Tests/PHP/TypeCastsUnitTest.php` which checks the `WordPress/Tests/PHP/TypeCastsUnitTest.inc` test case file. See the file naming convention?
 
-Lets take a look at what's inside `POSIXFunctionsUnitTest.php`:
+Lets take a look at what's inside `TypeCastsUnitTest.php`:
 
 ```php
 namespace WordPressCS\WordPress\Tests\PHP;
 
 use PHP_CodeSniffer\Tests\Standards\AbstractSniffUnitTest;
 
-final class POSIXFunctionsUnitTest extends AbstractSniffUnitTest {
+final class TypeCastsUnitTest extends AbstractSniffUnitTest {
 
 	/**
 	 * Returns the lines where errors should occur.
@@ -119,58 +142,59 @@ final class POSIXFunctionsUnitTest extends AbstractSniffUnitTest {
 	 */
 	public function getErrorList() {
 		return array(
+			10 => 1,
+			11 => 1,
 			13 => 1,
-			16 => 1,
-			18 => 1,
-			20 => 1,
-			22 => 1,
-			24 => 1,
 			26 => 1,
+			27 => 1,
+			28 => 1,
 		);
 	}
 
     ...
 }
 ```
 
-Also note the class name convention. The method `getErrorList()` MUST return an array of line numbers indicating errors (when running `phpcs`) found in `WordPress/Tests/PHP/POSIXFunctionsUnitTest.inc`. Similarly, the `getWarningList()` method must return an array of line numbers with the number of expected warnings.
+Also note the class name convention. The method `getErrorList()` MUST return an array of line numbers indicating errors (when running `phpcs`) found in `WordPress/Tests/PHP/TypeCastsUnitTest.inc`. Similarly, the `getWarningList()` method must return an array of line numbers with the number of expected warnings.
 
 If you run the following from the root directory of your WordPressCS clone:
 
 ```sh
-$ "vendor/bin/phpcs" --standard=Wordpress -s ./WordPress/Tests/PHP/POSIXFunctionsUnitTest.inc --sniffs=WordPress.PHP.POSIXFunctions
-...
---------------------------------------------------------------------------------
-FOUND 7 ERRORS AFFECTING 7 LINES
---------------------------------------------------------------------------------
- 13 | ERROR | ereg() has been deprecated since PHP 5.3 and removed in PHP 7.0,
-    |       | please use preg_match() instead.
-    |       | (WordPress.PHP.POSIXFunctions.ereg_ereg)
- 16 | ERROR | eregi() has been deprecated since PHP 5.3 and removed in PHP 7.0,
-    |       | please use preg_match() instead.
-    |       | (WordPress.PHP.POSIXFunctions.ereg_eregi)
- 18 | ERROR | ereg_replace() has been deprecated since PHP 5.3 and removed in
-    |       | PHP 7.0, please use preg_replace() instead.
-    |       | (WordPress.PHP.POSIXFunctions.ereg_replace_ereg_replace)
- 20 | ERROR | eregi_replace() has been deprecated since PHP 5.3 and removed in
-    |       | PHP 7.0, please use preg_replace() instead.
-    |       | (WordPress.PHP.POSIXFunctions.ereg_replace_eregi_replace)
- 22 | ERROR | split() has been deprecated since PHP 5.3 and removed in PHP 7.0,
-    |       | please use explode(), str_split() or preg_split() instead.
-    |       | (WordPress.PHP.POSIXFunctions.split_split)
- 24 | ERROR | spliti() has been deprecated since PHP 5.3 and removed in PHP
-    |       | 7.0, please use explode(), str_split() or preg_split()
-    |       | instead. (WordPress.PHP.POSIXFunctions.split_spliti)
- 26 | ERROR | sql_regcase() has been deprecated since PHP 5.3 and removed in
-    |       | PHP 7.0, please use preg_match() instead.
-    |       | (WordPress.PHP.POSIXFunctions.ereg_sql_regcase)
---------------------------------------------------------------------------------
+$ "vendor/bin/phpcs" --standard=Wordpress -s ./WordPress/Tests/PHP/TypeCastsUnitTest.inc --sniffs=WordPress.PHP.TypeCasts
 ...
+----------------------------------------------------------------------------------------------------
+FOUND 6 ERRORS AND 4 WARNINGS AFFECTING 10 LINES
+----------------------------------------------------------------------------------------------------
+ 10 | ERROR   | [x] Normalized type keywords must be used; expected "(float)" but found "(double)"
+    |         |     (WordPress.PHP.TypeCasts.DoubleRealFound)
+ 11 | ERROR   | [x] Normalized type keywords must be used; expected "(float)" but found "(real)"
+    |         |     (WordPress.PHP.TypeCasts.DoubleRealFound)
+ 13 | ERROR   | [ ] Using the "(unset)" cast is forbidden as the type cast is removed in PHP 8.0.
+    |         |     Use the "unset()" language construct instead.
+    |         |     (WordPress.PHP.TypeCasts.UnsetFound)
+ 15 | WARNING | [ ] Using binary casting is strongly discouraged. Found: "(binary)"
+    |         |     (WordPress.PHP.TypeCasts.BinaryFound)
+ 16 | WARNING | [ ] Using binary casting is strongly discouraged. Found: "b"
+    |         |     (WordPress.PHP.TypeCasts.BinaryFound)
+ 17 | WARNING | [ ] Using binary casting is strongly discouraged. Found: "b"
+    |         |     (WordPress.PHP.TypeCasts.BinaryFound)
+ 26 | ERROR   | [x] Normalized type keywords must be used; expected "(float)" but found "(double)"
+    |         |     (WordPress.PHP.TypeCasts.DoubleRealFound)
+ 27 | ERROR   | [x] Normalized type keywords must be used; expected "(float)" but found "(real)"
+    |         |     (WordPress.PHP.TypeCasts.DoubleRealFound)
+ 28 | ERROR   | [ ] Using the "(unset)" cast is forbidden as the type cast is removed in PHP 8.0.
+    |         |     Use the "unset()" language construct instead.
+    |         |     (WordPress.PHP.TypeCasts.UnsetFound)
+ 29 | WARNING | [ ] Using binary casting is strongly discouraged. Found: "(binary)"
+    |         |     (WordPress.PHP.TypeCasts.BinaryFound)
+----------------------------------------------------------------------------------------------------
+PHPCBF CAN FIX THE 4 MARKED SNIFF VIOLATIONS AUTOMATICALLY
+----------------------------------------------------------------------------------------------------
 ```
 You'll see the line number and number of ERRORs we need to return in the `getErrorList()` method.
 
 The `--sniffs=...` directive limits the output to the sniff you are testing.
 
-## Code Standards for this project
+### Code Standards for this project
 
 The sniffs and test files - not test _case_ files! - for WordPressCS should be written such that they pass the `WordPress-Extra` and the `WordPress-Docs` code standards using the custom ruleset as found in `/.phpcs.xml.dist`.

.github/dependabot.yml

@@ -15,3 +15,9 @@ updates:
       prefix: "GH Actions:"
     labels:
       - "Type: Chores/Cleanup"
+    groups:
+      action-runners:
+        applies-to: version-updates
+        update-types:
+          - "minor"
+          - "patch"

.github/pull_request_template.md

@@ -0,0 +1,34 @@
+<!-- Provide a general summary of your changes in the title above. -->
+
+<!--
+============================================================================================
+Please read the CONTRIBUTING guide before submitting your pull request.
+
+- Warning: AI-generated PRs are NOT welcome and may result in a ban from this repository.
+- Small PRs using atomic, descriptive commits are hugely appreciated, as it will make
+  reviewing your changes easier for the maintainers.
+- Ensure that the code you are submitting meets copyright and licensing requirements to be included in this codebase.
+
+Also, please make sure your pull request passes all continuous integration checks.
+PRs which are failing their CI checks will likely be ignored by the maintainers.
+
+============================================================================================
+-->
+
+# Description
+<!--
+What problem does this PR solve?
+Describe the purpose of your changes in detail explaining which choices you have made and why.
+-->
+
+
+## Suggested changelog entry
+<!--
+Please provide a short description of the change for the changelog.
+See the https://github.com/WordPress/WordPress-Coding-Standards/blob/develop/CHANGELOG.md file if you need examples.
+-->
+
+
+## Related issues/external references
+
+Fixes #

.github/release-checklist.md

@@ -36,6 +36,7 @@ PR for tracking changes for the x.x.x release. Target release date: **DOW MONTH
 
 ### Release prep
 
+- [ ] Double-check that all PRs which were merged since the last release have a milestone attached to it.
 - [ ] Add changelog for the release - PR #xxx
     :pencil2: Remember to add a release link at the bottom!
 - [ ] Update `README` (if applicable) - PR #xxx
@@ -45,7 +46,7 @@ PR for tracking changes for the x.x.x release. Target release date: **DOW MONTH
 
 - [ ] Merge this PR.
 - [ ] Make sure all CI builds are green.
-- [ ] Tag and create a release against `main` (careful, GH defaults to `develop`!) & copy & paste the changelog to it.
+- [ ] Tag and create a release against `main` (careful, GH defaults to `develop`!) & copy & paste the changelog to it.  
     :pencil2: Check if anything from the link collection at the bottom of the changelog needs to be copied in!
     - Remove square brackets from all ticket links or make them proper full links (as GH markdown parser doesn't parse these correctly).
     - Change all contributor links to full inline links (as GH markdown parser on the Releases page doesn't parse these correctly).
@@ -62,13 +63,16 @@ PR for tracking changes for the x.x.x release. Target release date: **DOW MONTH
 ### Publicize
 
 - [ ] [Major releases only] Publish post about the release on Make WordPress.
-- [ ] Tweet, toot, etc about the release.
-- [ ] Post about it in Slack.
-- [ ] Submit for ["Month in WordPress"][month-in-wp].
+- [ ] Tweet, toot, etc about the release from your personal account (there is no official WPCS account).
+- [ ] Post about it in #core channel on the WordPress.org Slack.  
+    :pencil2: No need to post in the #core-coding-standard channel as that gets an automated release notification anyway.
+    - [ ] Optionally post in #plugin-review if a sniff was added in a release which was requested by the plugin review team.
+    - [ ] Optionally post in #core-docs if significant updates were made to the documentation ruleset.
+- [ ] Create a Marketing team ["amplify request"][amplify-request].
 - [ ] Submit for the ["Monthy Dev Roundup"][dev-roundup].
 
 [phpcs-releases]:      https://github.com/PHPCSStandards/PHP_CodeSniffer/releases
 [phpcsutils-releases]: https://github.com/PHPCSStandards/PHPCSUtils/releases
 [phpcsextra-releases]: https://github.com/PHPCSStandards/PHPCSExtra/releases
-[month-in-wp]:         https://make.wordpress.org/community/month-in-wordpress-submissions/
+[amplify-request]:     https://github.com/WordPress/Marketing-Team/issues/new?template=2-request-for-amplification-template.yml
 [dev-roundup]:         https://github.com/WordPress/developer-blog-content/issues?q=is%3Aissue+label%3A%22Monthly+Roundup%22