[huzaifaalmesbah]

What?

See #86088

Fixes docblocks in the Style Engine and the Navigation block reported by PHPStan, and removes the resolved entries from the PHPStan baseline.

Core backport: WordPress/wordpress-develop#15823

Why?

The @phpstan-consistent-constructor change is already in WordPress Core, so the Gutenberg copy was out of sync. The $style_value docblocks were inaccurate in both Gutenberg and Core, so they are corrected here and synced to Core in the backport above. The Navigation change is in a deprecated function whose documented return type did not cover every path. This addresses 3 of the 226 errors initially baselined in #66693.

How?

• WP_Style_Engine_CSS_Rules_Store calls new static() in get_store(), which PHPStan reports as unsafe unless subclasses are guaranteed a compatible constructor. Added @phpstan-consistent-constructor to the class docblock, matching Core. (new.static)
• WP_Style_Engine::get_classnames() documented $style_value as array, but passes it on to get_slug_from_preset_value(), which expected a string. (argument.type) Neither is accurate: parse_block_styles() calls get_classnames() for every style definition with whatever value is found at the definition's path, so spacing and border radius values arrive as arrays and numeric settings such as textColumns as integers. $style_value is now documented as mixed on get_classnames(), get_slug_from_preset_value() (which already narrows it with is_string()), is_valid_style_value(), and get_css_declarations(), the last matching Core.
• get_classnames() also gets a list<string> return type, replacing the redundant array|string[], and a PHPStan shape for the classnames key it reads from $style_definition.
• The deprecated block_core_navigation_get_classic_menu_fallback() fell off the end without a return value when there were no classic menus. It now returns null explicitly, and its @return is WP_Term|null. Its only caller, block_core_navigation_maybe_use_classic_menu_fallback(), already returns early when the result is falsy. (return.missing)
• Removed the 3 corresponding entries from tools/phpstan/baseline.neon.

There is no change in behavior.

Testing Instructions

1. Run composer phpstan and confirm it passes with no unmatched ignored errors.
2. Run composer phpstan:baselines and confirm tools/phpstan/baseline.neon has no further changes.
3. Run the Style Engine PHP unit tests: npm run test:php -- --filter Style_Engine.

Testing Instructions for Keyboard

Not applicable. There are no UI changes.

Screenshots or screencast

Not applicable.

Use of AI Tools

I used Claude Code to identify the affected occurrences and draft the change. I reviewed the diff and take responsibility for it. Follow-up commits correcting the $style_value types and adding the Core backport were made with Claude Code (Claude Opus 5.5, medium effort).

[github-actions]

🤖 PR meta 🤖

🎉 Props

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: huzaifaalmesbah <huzaifaalmesbah@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: Deepak-Bhojwani <deepakbhojwani@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

---

Props Bot commands

You can trigger Props Bot actions by commenting on this PR:

• @propsbot add <username> to give props to a GitHub user. Requires write access.
• @propsbot remove <username> to leave a user out of the props. Requires write access.
• @propsbot refresh to refresh this list. Adding the props-bot label works too.

Updated as activity occurs, without notifying anyone named here. Add the props-bot label to refresh.

[Copilot]

🟢 Approval recommended

No active review issues remain for the PHPStan typing and Navigation return-contract updates.

No open issues 🎉

What changed in this PR

Addresses three baselined PHPStan errors toward #86088 by aligning Style Engine docblocks with Core and clarifying the deprecated Navigation fallback’s return contract, without changing runtime behavior.

Changes:

• Corrects the Style Engine parameter type and adds a consistent-constructor annotation.
• Documents the Navigation fallback’s nullable return and explicitly returns null when no classic menus exist.
• Removes three resolved baseline entries and updates one affected diagnostic.

File	Description
tools/​phpstan/​baseline.neon	Removes resolved errors and updates inferred Navigation field types.
packages/​style-engine/​src/​class-wp-style-engine.php	Corrects the documented $style_value type to string.
packages/​style-engine/​src/​class-wp-style-engine-css-rules-store.php	Adds the consistent-constructor PHPStan annotation.
packages/​block-library/​src/​navigation/​index.php	Documents `WP_Term

_{Review effort: Balanced}

[Deepak-Bhojwani]

Tested this locally against current trunk (6504787).

The branch conflicts with trunk in tools/phpstan/baseline.neon, since other PRs for #86088 have since removed entries from it. To test, I merged this branch into trunk, kept trunk's baseline, and ran composer phpstan:baselines:

• The only change to the baseline from trunk is the removal of the 3 entries this PR targets (return.missing in navigation/index.php, new.static in class-wp-style-engine-css-rules-store.php, and argument.type in class-wp-style-engine.php). The baseline goes from 13 to 10 errors, with no new ones.
• composer phpstan then passes with no errors and no unmatched ignored errors.
• The wp_insert_post() baseline entry updated in e2e2cae is no longer in trunk's baseline, so that change drops out when resolving the conflict.

I also compared the Style Engine changes with Core: the @param string $style_value docblock on get_classnames() and @phpstan-consistent-constructor on WP_Style_Engine_CSS_Rules_Store match wordpress-develop trunk. get_slug_from_preset_value() already guards with is_string( $style_value ), so documenting it as string doesn't change behavior.

For the Navigation change, returning null explicitly is equivalent to the previous implicit return, and the only caller, block_core_navigation_maybe_use_classic_menu_fallback(), returns early on a falsy result.

So this looks good to me once it is rebased on trunk and the baseline is regenerated.

Environment: Windows 11, PHP 8.2.29, Composer 2.11.1, stubs generated from wordpress-develop@27307a20f9ba. I did not run the Style Engine PHPUnit tests, since I don't have wp-env available here.