Fix code issues identified by PHPStan

[johnbillion]

In #51423 several issues were identified with function argument types that were detected by PHPStan.

There are other issues that PHPStan detects too such as potentially undefined variables, functions called with incorrect number of parameters, access to undefined properties, and more as you increase the level of checking performed.

We can scan core using the level 1 checks and catch quite a few low hanging fruit, and then go from there.

Follow-up task: Consider whether it's beneficial to add PHPStan (or Psalm or Phan) analysis to the build tooling and CI.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This introduces config for PHPStan with plenty of exclusions so we can identify real issues that need to be fixed.

[jorbin]

Left one comment about where we put the bootstrap file, otherwise, love this idea.

Consider whether it's beneficial to add PHPStan (or Psalm or Phan) analysis to the build tooling and CI.

I lean towards yes

[szepe.viktor]

to add PHPStan (or Psalm or Phan) analysis to the build tooling and CI.

Let's lean towards PHPStan.

written by a PHPStan Advocate

[johnbillion]

In 49936:

Docs: Corrections and improvements to types used in various docblocks.

See #51800, #52217

[johnbillion]

In 49946:

Plugins: Replace usage of $this in action and filter parameter docblocks with more appropriate variable names.

See #51800, #52217

Fixes #52243

[jrf]

FYI: I've done a detailed review of the patch on GH and left extensive comments.

I don't think this can be introduced as a dependency, if for no other reason than a mismatch in minimum PHP requirements.

Valid fixes found through scans with PHPStan, however, should, of course, be committed.

### Problems of using PHPStan as an inline continuous tool

PHPStan - and Psalm as well for that matter - work best with well-typed code bases, the stricter the better.

WordPress is most definitely not such a code base, so the noise from false positives will be huge.

I agree. I'd like to echo and add to @jrfnl's concerns.

PHPStan will generate a huge volume of false positives. Why is this a problem?

• Significant effort will be needed to investigate each PHPStan incident to determine if it's a valid positive AND if it's something that could or should be changed for WordPress specifically without causing a backwards-compat issue.

I've witnessed this with the work being done in Trac ticket 51423. It's time-consuming work and the type of work that requires deep knowledge about not only PHP but also WordPress itself.

• Risk of changing the codebase to make PHPStan happy without adding value to the codebase.

• Bottlenecks in the workflow for contributors, maintainers, and committers.

• Frustration pain point for contributors in figuring out how to make PHPStan happy.

### Where does PHPStan fit into the project?

I do think it's a good idea to do intermittent, ad-hoc runs with tools like PHPStan, Psalm, Exakat and other tools

I agree. This tool and others can serve WordPress as a _periodic auditing tool_.

### What about this PR?
There are valid fixes and improvements in this PR:

• Some look like bug fixes

These could be broken out into separate tickets for tracking, history, and isolated discussion and testing.

• Some are potential code improvements, though many need testing to ensure each is valid and does not cause a backwards compat issue.

These could be also be broken out from the PHPStan work as a separate ticket and PR.

By splitting out the work we can ensure these are not lost (along with the extensive code reviews) in the debate about whether to use PHPStan as an inline CI tool or not.

[hellofromTonya]

Consider whether it's beneficial to add PHPStan (or Psalm or Phan) analysis to the build tooling and CI.

Using it as a periodic auditing tool is valuable for the project.

Caution: Using it will be expensive in terms of effort and time. Why? PHPStan will generate significant false positives. Many of these will not be fixable in WordPress due to backwards-compat. Many may not be valid for WordPress. As a result, each incident reported by PHPStan requires a deep review and knowledge to do the review to determine if it's a valid report that needs fixing.

I agree with @jrf that it's not well suited as part of an inline CI workflow that runs on every PR. ​Left a comment in the PR to share reasoning.

[hellofromTonya]

Related #51423

[szepe.viktor]

Replying to hellofromTonya:

Caution: Using it will be expensive in terms of effort and time.

PHPStan has a feature called "baseline" all false positives, todos, anything can go into the baseline file.
It makes it possible to keep further development at high quality.

[johnbillion]

Thanks for the comments! I'll go through the comments on the PR shortly and respond there, but I just wanted to say that any additional tooling or testing we introduce into WordPress will require significant configuration and, as evidenced by the phpstan.neon.dist file in my PR, a significant number of exceptions. This should not be a reason to discount introducing tooling that can identify bugs.

As Viktor mentioned, PHPStan has a specific solution for introducing its analysis into a legacy codebase. You can generate a baseline report which represents the current state of the project, and then you can configure the level of checking for any newly introduced code. Docs: ​https://phpstan.org/user-guide/baseline.

PHPStan works great on strictly typed codebases but it does much more than type checking. In fact it doesn't do any type checking until you configure it to use level 3 or higher. At level 1, which I've used in my PR, it checks for unknown symbols, wrong numbers of arguments, and undefined variables. Docs: ​https://phpstan.org/user-guide/rule-levels.

All of the errors that are flagged by PHPStan at level 0 and 1 are legitimate code errors that need to be fixed. Only once you move into level 2 and above does it tackle errors that are based on the validity of type hints, return types, and PHPDoc tag types.

Ticket #51423 is a rabbit hole. This ticket is much more narrowly focused.

@hellofromtonya I've addressed your main concern about the impact of introducing static analysis in the comments on https://core.trac.wordpress.org/ticket/52217, but in short I don't believe that it introduces the sort of significant burden and large number of false positives that you've seen on https://core.trac.wordpress.org/ticket/51423 . This ticket aims to start at level 1, whereas 51423 aims to tackle type related problems that are several steps ahead of where we are now.

I'm going to update the description of this PR with notes about each change. I realise that it's not clear why quite a few of these changes have been made.

[hellofromTonya]

Replying to johnbillion:

This should not be a reason to discount introducing tooling that can identify bugs.

I agree that it can help identify bugs, which is why we saw it as a good ad-hoc and auditing tool. I wonder if I might have misunderstood how this ticket is proposing it be used. So let me ask:

@johnbillion Do you envision wiring PHPStan as another inline CI dependency like we do for running phpcs and phpunit?

If yes:

• How do we help contributors analyze incidents reported by it to determine if it's a real and fixable issue and then resolve each?
• Do you foresee it becoming a pain point for contributors?

[johnbillion]

My original proposal was going to be to configure and run PHPStan on core (at level 1 or 2) and fix the issues it raises, then circle back at a later point to consider whether implementing it as part of our tooling and CI would be a good idea. Jorbin and Viktor made positive sounding noises in the comments above so I just went with it.

From my experience with PHPStan at levels 0 and 1, once you get the exclusions and configuration in place that you need then it only warns about real code problems, and as I mentioned it won't consider anything relating to types.

How do we help contributors analyze incidents reported by it to determine if it's a real and fixable issue and then resolve each?

I would say the PHPStan error messages are similar in terms of technical complexity and language to PHPCS. The errors you'll see from levels 0 and 1 relate to undefined variables, unknown functions and methods, and incorrect parameter counts. I would say these are on par with PHPCS in terms of how experienced you need to be to understand and fix the problem.

PHPStan has a documentation section specifically for writing PHP code correctly, for example ​solving undefined variables.

Do you foresee it becoming a pain point for contributors?

Potentially yes, but I'm of the opinion that errors from ​levels 0 and 1 are manageable now the initial configuration is in place. It's not going to report anything opinionated, nor is it going to report problems with types.

From reading through the conversation and PRs on #51423 I think it's trying to tackle too much at once and is probably the source of the pain points you mention. In that situation I don't think implementing PHPStan at the level that reports those problems is realistic, certainly not at the moment anyway.

I'm very happy to fix the actual errors that I've seen at level 1 and then open a separate ticket for implementing PHPStan into the tooling, it was just easier and more accessible to implement it all together in my PR.

[johnbillion]

In 51850:

General: Fix code quality issues which were identified by static analysis.

This fixes minor issues that could cause PHP notices under the right conditions, and fixes some general incorrectness.

Props jrf, hellofromTonya for review

See #52217

https://core.trac.wordpress.org/changeset/51850

[johnbillion]

In 51851:

Docs: Miscellaneous docblock corrections and improvements.

See #52217, #53399

https://core.trac.wordpress.org/changeset/51851

[hellofromTonya]

With 5.9 feature freeze tomorrow and Beta next week, moving this ticket to Future Release (as the next milestone is not yet opened). @johnbillion please feel free to move it into a future milestone.

This is an interesting point and seems easy to add to the project, what can we do to push it?

[westonruter]

Replying to johnbillion:

Follow-up task: Consider whether it's beneficial to add PHPStan (or Psalm or Phan) analysis to the build tooling and CI.

I've opened #61175 for this.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR adds missing void return types to (parent) methods that can _explicitly_ return void as one of their conditional paths.

While these issues were surfaced via PHPStan in #7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), they can be addressed independently of that ticket.

### Addressed methods:

• WP_Privacy_Requests_Table::column_status()
• WP_Recovery_Mode::handle_error()
• WP_Widget::form() - unlike the others, it's the _child classes_ that return void when the method is correctly implemented.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes an issue where our magic __isset() methods were potentially returning void (if the prop is not in an allow-listed array of fields ) instead of an explicit bool false.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

### Addressed methods

• WP_Comment::__isset()
• WP_Query::__isset()

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes an issue in WP_Navigation_Block_Renderer where ::get_inner_blocks_from_navigation_post() and block_core_navigation_get_classic_menu_fallback() could potentially return void instead of their documented return types.

The issue is remediated by explicitly returning null (how void gets naturally coerced when assigning to a variable), as the most minimal change to address the issue while still persevering backcompat.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes several instances of WP_Site_Health_Auto_Updates::test_*() potentially returning void instead of their documented return types.

Since these methods are public for some reason, null is used to represent a passed test for backwards-compatibility with the coersion of the previously-returned voids. Previous usage of false is preserved.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

[justlevine]

Using the refreshed report from ​https://github.com/WordPress/wordpress-develop/pull/7619 (from #61175), I've begun remediating errors surfaced by PHPStan in individual PRs, so they can be reviewed independently of the tooling, and hopefully reduce the chance of them going stale.

Will be rebasing that PR against trunk periodically, so the baselines there will reflect WordPress's overall progress towards passing the individual PHPStan Levels.

So far,

• ​https://github.com/WordPress/wordpress-develop/pull/7672
• ​https://github.com/WordPress/wordpress-develop/pull/7673
• ​https://github.com/WordPress/wordpress-develop/pull/7674
• ​https://github.com/WordPress/wordpress-develop/pull/7675

handle all the "easy-remediable" Level 0 violations, aka are independently justifiable from just trying to pass the level, and don't require what could be seen as an "unnecessary refactor"

The remaining ones IMO really on make sense in the context of passing PHPStan (mostly undiscovered symbols - ​https://github.com/justlevine/wordpress-develop/blob/e14ac75beac7dd157ac2b9750b5b98d70926a5d4/tests/phpstan/baseline/level-0.php ), but if you see something on that list that you think makes sense to remediate independently of PHPStan getting merged, please lmk or open a PR against trunk.

Moving on to Level 1 ( ref: ​https://github.com/WordPress/wordpress-develop/blob/2dd671c8cc23a9ab8b002024246594433c78868a/tests/phpstan/baseline/level-1.php )

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes several invalid PHPDoc @params.

More specifically:

• Removed @params for non-existent parameters on:
  • render_block_core_button()
  • render_block_core_file()
  • render_block_core_search()
• Renamed the @param in untrailingslashit() to match the parameter name used in the signature.
• Fixed the @param type on fix_phpmailer_message_id() to refer to the PHPMailer class instead of the namespace.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR removes invalid @throws WP_Error annotations from the doc-blocks of the following functions:

• register_block_core_home_link()
• register_block_core_navigation_link()
• register_block_core_navigation_submenu()

These annotations are invalid for a few reasons:

• WP_Error is returnable, not Throwable
• WP_Error is not returned.
• A review of the functions' internals and render_callbacks doesn't show any attempts to either return a WP_Error or throw anything else.

( It's possible I missed something, but I'm pretty confident, as these are the only register_() functions in blocks/ that have any @throws annotation )

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes the PHPDoc @var type used for WP_HTML_Processor_State::$context_node to "correctly" indicate that it is an array where the first item is a string and the second is an array.

"Correctly" in this context means recognized by IDEs and tooling and following preexisting code patterns for array shapes (e.g. ​https://github.com/WordPress/wordpress-develop/blob/695476ea5e51d1c92f389ac236b138ceeaee8a99/src/wp-includes/interactivity-api/class-wp-interactivity-api.php#L104).

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

wp-includes/blocks is not controlled by this repo

wp-includes/blocks is not managed by this repo

Rebased to remove changes in wp-includes/blocks, which arent managed in this codebase.

[SergeyBiryukov]

In 59333:

Docs: Correct @param tag in untrailingslashit() to match the parameter name.

Follow-up to [54927].

Props justlevine.
See #52217, #62281.

[SergeyBiryukov]

In 59334:

Docs: Correct @param type in fix_phpmailer_messageid().

Follow-up to [48033].

Props justlevine.
See #52217, #62281.

Thanks for the PR! Merged in r59333 and r59334.

[SergeyBiryukov]

In 59336:

Docs: Add missing void to DocBlock @return types.

This commit adds missing void return types to (parent) methods that can explicitly return void as one of their conditional paths.

Addressed methods:

• WP_Privacy_Requests_Table::column_status()
• WP_Recovery_Mode::handle_error()
• WP_Widget::form() — unlike the others, it's the child classes that return void when the method is correctly implemented.

Note: @return void (where void is the single type returned) should not be used outside the default bundled themes and the PHP compatibility shims included in WordPress Core, as per the ​documentation standards.

Follow-up to [30382], [42967], [43256], [44973], [45448].

Props justlevine.
See #52217, #62281.

Thanks for the PR! Merged in r59336.

[SergeyBiryukov]

In 59337:

Coding Standards: Explicitly return false in magic __isset() methods.

This commit fixes an issue where some magic __isset() methods were potentially returning void (if the prop is not in an allow-listed array of fields) instead of an explicit boolean false.

Addressed methods:

• WP_Comment::__isset()
• WP_Query::__isset()

Follow-up to [28523], [31151], [34583], [34599].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59337.

[SergeyBiryukov]

In 59340:

Coding Standards: Use explicit returns in WP_Site_Health_Auto_Updates::test_*().

This commit corrects several instances of test_*() methods potentially returning void instead of their documented return types.

Since these methods are public, null is used to represent a passed test for backward compatibility with the coercion of the previously-returned void. Previous usage of false is preserved.

Includes updating some @return tags for clarity.

Follow-up to [44986], [46276], [49927].

Props justlevine, apermo, SergeyBiryukov.
See #52217.

Thanks for the PR! Merged in r59340.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes an issue with the usage of the new $wp_style->get_etag() in load-styles.php, where the $wp_version is passed as the first arg instead of $load being used as the _only_ arg.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it _should_ be remediated independently of that issue as it's a novel bug getting shipped in WP 6.7

Nice catch @justlevine, @SergeyBiryukov could you please take a look.

Added it https://core.trac.wordpress.org/ticket/61485

cc @peterwilsoncc

[SergeyBiryukov]

In 59341:

Script Loader: Correct the number of arguments passed to WP_Styles::get_etag().

This fixes an issue with the usage of the new $wp_styles->get_etag() method in wp-admin/load-styles.php, where $wp_version is passed as the first argument instead of $load being used as the only argument.

Follow-up to [58935].

Props justlevine, mukesh27, swissspidy.
See #52217, #61485.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes an issue where the private property WP_User_Query::$results is accessed directly in WP_REST_Users_Controller::get_items() instead of via the ::get_results() method.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes a call to WP_HTML_Tag_Processor::get_tag() with an argument passed to the method as ::get_tag() accepts no arguments.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes an issue in wp_user_settings() where a string ($current) is compared to an int ($last_saved). The issue is resolved by casting the results of preg_replace() to type int when $current is defined.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes an issue in get_taxonomy_labels(), where the template_name was accessed as an object property on $tax->labels instead of as an array property.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Not sure why this is breaking things. $tax->labels is coerced into an array at the top of the function 🤔

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes an issue in wp_update_user(), where time() is subtracted from the $logged_in_cookie['expiration'] of type string.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR removes a redundant isset( $HTTP_RAW_POST_DATA ) from xmlrpc.php, as the variable gets set in the code block immediately preceding the affected line.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

[peterwilsoncc]

In 59343:

Script Loader: Correct the number of arguments passed to WP_Styles::get_etag().

This fixes an issue with the usage of the new $wp_styles->get_etag() method in wp-admin/load-styles.php, where $wp_version is passed as the first argument instead of $load being used as the only argument.

Follow-up to [58935].

Reviewed by swissspidy.
Merges [59341] to the 6.7 branch.

Props justlevine, mukesh27, swissspidy, SergeyBiryukov.
See #52217, #61485.

Committed in https://core.trac.wordpress.org/changeset/59341

Nice catch!

Introduce in [57514] / #60282

[SergeyBiryukov]

In 59357:

Coding Standards: Use WP_User_Query::get_results() instead of a private property.

This resolves an issue where the private property WP_User_Query::$results is accessed directly in WP_REST_Users_Controller::get_items() instead of via the ::get_results() method.

Follow-up to [38832].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59357.

[SergeyBiryukov]

In 59361:

Editor: Correct the number of arguments for WP_HTML_Tag_Processor::get_tag().

This resolves an issue with ::get_tag() being called in WP_Block::replace_html() with an extra argument, as the method accepts no arguments.

Follow-up to [57514].

Props justlevine, mukesh27.
See #52217.

Thanks for the PR! Merged in r59361.

[SergeyBiryukov]

In 59373:

Coding Standards: Ensure $current cookie time is int in wp_user_settings().

This addresses an issue where a string ($current) is compared to an integer ($last_saved). The issue is resolved by casting the results of preg_replace() to type int when $current is defined.

Follow-up to [8784], [10083], [25109].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59373.

[SergeyBiryukov]

In 59376:

Coding Standards: Remove unnecessary isset() from xmlrpc.php.

This removes a redundant isset( $HTTP_RAW_POST_DATA ) from xmlrpc.php, as the variable is already set in the code block immediately preceding the affected line.

Follow-up to [3498], [5445], [47926].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59376.

[SergeyBiryukov]

In 59377:

Coding Standards: Ensure cookie expiration value is an integer in wp_update_user().

This addresses an issue in wp_update_user(), where time() is subtracted from the $logged_in_cookie['expiration'] of type string.

Follow-up to [29043].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59377.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes two instances where a function that is documented as returning {someType}|null doesn't explicitly return null.

Affected functions:

• array_key_first()
• WP_REST_Posts_Controller::handle_terms()

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR updates WP_Theme_JSON::get_svg_filters() to use WP_Duotone::get_filter_svg_from_preset() instead of the deprecated (since v6.3) wp_get_duotone_filter_svg() function.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR removes an extraneous unset( $args[0] ) in rest_handle_options_request().

$args is defined in the immediate-preceding codeblock, and only contains non-integer keys, so there is never an $args[0] to unset.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes an issue in wp_validate_auth_cookie() where the (string) $expired is used both in a comparison and addition with int values in .

The issue is fixed by casting $expired to an int when it is defined.

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes two instances of the (numeric string) return value from wp_count_terms() being used directly in ceil(), which ​expects an `int|float`.

Affected methods:

• WP_Sitemaps_Taxonomies::get_max_num_pages()
• wp_nav_menu_item_taxonomy_meta_box()

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes two instances of the (numeric string ) gmdate( 'Z' ) being added to an int value.

Affected functions:

• upgrade_110()`
• WP_Date_Query::validate_date_values()

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

Trac ticket: https://core.trac.wordpress.org/ticket/52217

This PR fixes several instances of gmdate( 'W' ) being used directly as an integer, when it's actually a numeric string. The issue is remediated by casting the value to ( int ) before use.

Affected functions:

• get_calendar()
• get_weekstartend()

While this issue was surfaced via PHPStan in ​https://github.com/WordPress/wordpress-develop/pull/7619 (trac: https://core.trac.wordpress.org/ticket/61175 ), it can be remediated independently of that ticket.

[SergeyBiryukov]

In 59453:

Coding Standards: Explicitly return null instead of coercing void.

This addresses two instances where a function that is documented as returning {someType}|null doesn't explicitly return null.

Affected functions:

• array_key_first()
• WP_REST_Posts_Controller::handle_terms()

Follow-up to [38832], [52038].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59453.

[SergeyBiryukov]

In 59455:

Coding Standards: Replace usage of deprecated wp_get_duotone_filter_svg().

This updates WP_Theme_JSON::get_svg_filters() to use WP_Duotone::get_filter_svg_from_preset() instead of the wp_get_duotone_filter_svg() function, deprecated in WordPress 6.3.

Follow-up to [52757], [56101].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59455.

[SergeyBiryukov]

In 59456:

Coding Standards: Remove extra unset() in rest_handle_options_request().

$args is defined in the immediately preceding code block, and only contains non-integer keys, so there is never an $args[0] to unset.

Follow-up to [44933].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59456.

[SergeyBiryukov]

In 59459:

Coding Standards: Cast $expired to an integer in wp_validate_auth_cookie().

This resolves an issue where the string $expired value is used both in a comparison and addition with integer values.

Follow-up to [6387], [28424], [45590].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59459.

[SergeyBiryukov]

In 59462:

Coding Standards: Cast wp_count_terms() result to int before using in ceil().

This addresses two instances of the (numeric string) return value from wp_count_terms() being used directly in ceil(), which expects an int|float.

Affected methods:

• WP_Sitemaps_Taxonomies::get_max_num_pages()
• wp_nav_menu_item_taxonomy_meta_box()

Reference: ​PHP Manual: ceil().

Follow-up to [14248], [14291], [14569], [14943], [48072], [57648].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59462.

[SergeyBiryukov]

In 59465:

Coding Standards: Cast gmdate( 'Z' ) to an integer before addition.

This addresses two instances of the (numeric string) gmdate( 'Z' ) being added to an int value.

Affected functions:

• upgrade_110()
• WP_Date_Query::validate_date_values()

Follow-up to [942], [29925], [45424].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59465.

[SergeyBiryukov]

In 59471:

Coding Standards: Cast gmdate( 'w' ) to int before using as integer.

This addresses several instances of gmdate( 'w' ) being used directly as an integer, when it's actually a numeric string. The issue is remediated by casting the value to int before use.

Affected functions:

• get_calendar()
• get_weekstartend()

Follow-up to [508], [1632].

Props justlevine.
See #52217.

Thanks for the PR! Merged in r59471.