New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release version 2.2.0 #1828
Merged
Release version 2.2.0 #1828
Conversation
This file contains 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
Travis now offers stages. Using stages we can: - Run the code style related checks before running any unit tests and stop the build early if any are detected. - Remove the duplicate unit test runs - i.e. previously we had an extra (third) build against PHP 7.2 (now changed to 7.3) which would run the code style related checks, but would also re-run the unit tests. This extra build will now no longer run the unit tests. While this does mean that the unit tests will run with a slight delay (the `Sniff` and `Rulesets` stages have to finish before they start), it also means that we: * Get code style errors reported earlier as it's been moved to be the first stage and the build will just stop if any are found. * We won't be wasting Travis's resources on builds which will have to be re-run anyway. Ref: https://docs.travis-ci.com/user/build-stages/ Note that `Allowed failures` is no longer listed as a separate block in the Travis result overview, but is _is_ respected. For more discussion about this: * travis-ci/travis-ci#7789 * https://travis-ci.community/t/always-show-allow-failures-allowed-failures-when-build-stages-are-used/217 * https://travis-ci.community/t/work-out-kinks-in-interactions-between-stages-allow-fail-and-fast-finish/1090 * travis-ci/travis-ci#9677
…ges (#1711) Travis: run the code style related and ruleset checks in separate stages Co-authored-by: Stephen Edgar <stephen@netweb.com.au>
String array keys for variable array access would also be examined as part of the hook name, while those should be skipped over as they are not part of the _hook_name. This fixes that. Includes unit test. This commit also lowers the nesting level of the loop by continuing early whenever possible.
…dhookname-bugfix ValidHookName: bug fix / skip over array keys
Add RECOVERY_MODE_COOKIE to whitelisted core constants
The repo has moved organization within GitHub.
Composer: Update repo URL references
The "quicktest" stage will only run a CS check, ruleset check, linting and the unit tests against low/high PHP/PHPCS combinations. This should catch most issues. The more comprehensive complete build against a larger combination of PHP/PHPCS combination will now only be run on PRs and merges to `develop`/`master`.
…d-stage Travis: add "quicktest" stage for non-PR/merge builds
As this sniff is already included in the WP Core ruleset and the enhancement request is about PHP native functions, this seemed liked a logical sniff to add this to. I've elected to make this an `error` instead of a `warning` as the code within WP Core has been cleaned up for this issue now and it would be good to prevent new instances of `date()` creeping in. Fixes 1713
…ctions-add-date RestrictedPHPFunctions: add error for use of date()
The GitHub repository has moved from the dedicated `WordPress-Coding-Standards` organisation to the `WordPress` organisation. This: * Updates all links which pointed to the old repo on GH to the new one. * Updates the badges in the Readme to pick up things up correctly again for the new repo. * Updated all links to Travis from `.org` to `.com` as the build CI has moved as well.
Add `$plugin` to the list of global variables that shouldn't be overridden
Added remaining plugin load globals
Rulesets are processed top-to-bottom, one rule at the time. For the `WordPress` ruleset, this means that PHPCS would first load the `WordPress-Core` ruleset and process all rules in that file, then read the `WordPress-Docs` ruleset and lastly, the `WordPress-Extra` ruleset. As the `WordPress-Extra` ruleset includes `WordPress-Core`, it would re-process the `WordPress-Core` ruleset a second time and then process the additional rules in the `Extra` ruleset. This means that in effect, the `WordPress-Core` ruleset is processed twice when using the `WordPress` ruleset which is inefficient. By commenting that rule out, we still document that the `WordPress` ruleset includes `WordPress-Core` without double processing the ruleset.
…-fix WordPress ruleset: efficiency fix
Adds documentation for the WordPress.WhiteSpace.CastStructureSpacing Related to #1722
Adds documentation for the WordPress.WhiteSpace.PrecisionAlignmentSniff Related to #1722
Adds documentation for the WordPress.WhiteSpace.DisallowInlineTabs sniff Related to #1722
… in combination with a spread operator Includes updated docs. Related 1762 Related 1524
This new sniff addresses the new "_The short ternary operator must not be used._" rule which was recently added to the handbook. The sniff has been added to the `WordPress-Core` ruleset. Refs: * https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/#ternary-operator * https://make.wordpress.org/core/2019/07/12/php-coding-standards-changes/ Includes unit tests. Includes documentation.
Recently a new section has been added to the handbook which forbids the use of short arrays. > Using long array syntax ( array( 1, 2, 3 ) ) for declaring arrays is generally more readable than short array syntax ( [ 1, 2, 3 ] ), particularly for those with vision difficulties. Additionally, it’s much more descriptive for beginners. > > Arrays must be declared using long array syntax. https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/#declaring-arrays This PR add an existing upstream sniff which addresses this. Includes auto-fixer. Also see: https://make.wordpress.org/core/2019/07/12/php-coding-standards-changes/ Loosely related to 764
* Trim whitespace off the "expected" and "found" values which are used in the error messages. * Ignore comments and PHPCS annotations when building up the "expected" and "found" values. * Improve line precision by throwing the error on the line where the hook name starts, not the line containing the function call. Includes unit test. The unit test basically only tests part 3 of the change. The error message improvement needs visual inspection as the message content is not tested.
Similar to 1815, but then for the `PrefixAllGlobals` sniff, allowing it to fail earlier for calls to deprecated hooks.
…-error-messages ValidHookName: improve error messages
…tamp-sniff New DateTime.CurrentTimeTimestamp sniff
PrefixAllGlobals: minor efficiency tweak
What with the target release date for WPCS 2.2.0 being November 11 and the target release date of WP 5.3 being November 12, updating this property before the release is probably a good idea.
Update WordPress/Docs/WP/CronIntervalStandard.xml Co-Authored-By: Juliette <663378+jrfnl@users.noreply.github.com> Update WordPress/Docs/WP/CronIntervalStandard.xml Co-Authored-By: Juliette <663378+jrfnl@users.noreply.github.com> Update WordPress/Docs/WP/CronIntervalStandard.xml Co-Authored-By: Juliette <663378+jrfnl@users.noreply.github.com> Update WordPress/Docs/WP/CronIntervalStandard.xml Co-Authored-By: Juliette <663378+jrfnl@users.noreply.github.com> Update WordPress/Docs/WP/CronIntervalStandard.xml Co-Authored-By: Juliette <663378+jrfnl@users.noreply.github.com> Seperates function definition
Adds a new `WordPress.NamingConventions.ValidPostTypeSlug` sniff. Checks if the first parameter given to a register_post_type() call is actually a valid value.
…sion-property Update default minimum supported WP version
Adds documentation for WordPress.WP.CronInterval
Docs: Add PostsPerPage XML doc
... picked up along the way.
Various minor documentation fixes
…dResources Adds documentation for WordPress.WP.EnqueuedResources.
Adds WP.Security.SafeRedirect documentation.
* Release date set at this **Monday November 11th**. * Includes all currently merged changes.
@WordPress/wpcs Could I have some approval(s) please ? |
Changelog for WPCS 2.2.0
dingo-d
approved these changes
Nov 11, 2019
GaryJones
approved these changes
Nov 11, 2019
Release tweet: https://twitter.com/jrf_nl/status/1193875824832843778 |
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.
PR for tracking changes for the 2.2.0 release. Target release date: Monday November 11.
DeprecatedFunctions
and the other deprecated WP feature sniffs need updating and if so, action it - DeprecatedClasses: update the sniff #1809, DeprecatedFunctions: update function list #1810master
(careful, GH defaults todevelop
!) & copy & paste the changelog to itOpen PR to mergemaster
intodevelop
to get rid of the This branch is out-of-date with the base branch messages on each release. (only after major releases)