Skip to content

Cast the parsed hue to a float in WP_Duotone_Gutenberg::colord_parse_hsla_string() - #68405

Merged
westonruter merged 3 commits into
WordPress:trunkfrom
justlevine:fix/string-param_colord_parse_hue
Oct 25, 2026
Merged

westonruter merged 3 commits into
WordPress:trunkfrom
justlevine:fix/string-param_colord_parse_hue

Conversation

@justlevine

Copy link
Copy Markdown
Contributor

What?

This PR fixes an issue in WP_Duotone_Gutenberg::colord_parse_hsla_string() where the string results of preg_match() are passed to ::colord_parse_hue() which expects a float for its first parameter.

Why?

While this issue was surfaced by PHPStan (via #66693) it can be remediated independently as part of #66598

How?

Testing Instructions

Testing Instructions for Keyboard

Screenshots or screencast

Before After

@carolinan carolinan added the [Type] Code Quality Issues or PRs that relate to code quality label Jan 27, 2025
@carolinan carolinan added the Needs PHP backport Needs PHP backport to Core label Jan 27, 2025
@carolinan

Copy link
Copy Markdown
Contributor

@justlevine
justlevine force-pushed the fix/string-param_colord_parse_hue branch from 5a08e56 to 265654d Compare April 18, 2025 23:05
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The fix is being brought to core in WordPress/wordpress-develop#14862,
along with the related PHPStan fixes from three other Gutenberg PRs, which
share this entry.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@westonruter westonruter changed the title fix: cast $match[1] to float in WP_DuotoneGutenberg::colord_parse_hsla_string() Cast the parsed hue to a float in WP_Duotone_Gutenberg::colord_parse_hsla_string() Oct 25, 2026
@westonruter

Copy link
Copy Markdown
Member

🤖 Comment by Claude Opus 5.5

trunk was merged in, and a backport changelog entry was added for WordPress/wordpress-develop#14862, which applies the same cast in WP_Duotone::colord_parse_hsla_string() in core, along with three related PHPStan fixes, under Core-65817.

@github-actions

Copy link
Copy Markdown

🤖 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: justlevine <justlevine@git.wordpress.org>
Co-authored-by: westonruter <westonruter@git.wordpress.org>
Co-authored-by: carolinan <poena@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.

@westonruter

westonruter commented Oct 25, 2026 •

Copy link
Copy Markdown
Member

@westonruter
westonruter merged commit 4f99823 into WordPress:trunk Oct 25, 2026
78 checks passed
@github-actions github-actions Bot added this to the Gutenberg 24.4 milestone Oct 25, 2026
wporg-sync pushed a commit to WordPress/wordpress-develop that referenced this pull request Oct 26, 2026
These fixes were made in Gutenberg while resolving the PHPStan errors in the plugin, ahead of adding PHPStan to its CI, and are brought to core to keep the two codebases in sync. They were developed in:

* WordPress/gutenberg#68398
* WordPress/gutenberg#68404
* WordPress/gutenberg#68405
* WordPress/gutenberg#68407

The first one fixes a bug in core. Since r56046 the `array_key_exists()` checks in `wp_register_shadow_support()` have lacked their negation, so a block type with shadow support but no `style` or `shadow` attribute never had them registered, while one that already defined them had its definitions replaced, dropping any `default`. Gutenberg already had the negation. Tests are added for the attribute registration.

The others make implicit type conversions explicit in the layout and duotone code, and narrow the types used by `WP_Theme_JSON::get_feature_declarations_for_node()` so that it reports no errors even at PHPStan rule level 10. Since the node comes from `theme.json` data, that method now also checks that a feature is an array before reading its subfeatures. This fixes a fatal error ("Cannot unset string offsets") when a feature's value is a string, such as a `shadow`, and the block's selectors for that feature are a list rather than keyed by subfeature name, since each numeric key then reads a character of the string instead of a subfeature. The baseline entries for the resolved errors are removed.

Developed in #14862.
Follow-up to r56046, r56058, r56101, r62478, r63426.

Props justlevine, westonruter, poena, ramonopoly.
See #65817.


git-svn-id: https://develop.svn.wordpress.org/trunk@64727 602fd350-edb4-49c9-b593-d223f7449a82
wporg-sync pushed a commit to WordPress/WordPress that referenced this pull request Oct 26, 2026
These fixes were made in Gutenberg while resolving the PHPStan errors in the plugin, ahead of adding PHPStan to its CI, and are brought to core to keep the two codebases in sync. They were developed in:

* WordPress/gutenberg#68398
* WordPress/gutenberg#68404
* WordPress/gutenberg#68405
* WordPress/gutenberg#68407

The first one fixes a bug in core. Since r56046 the `array_key_exists()` checks in `wp_register_shadow_support()` have lacked their negation, so a block type with shadow support but no `style` or `shadow` attribute never had them registered, while one that already defined them had its definitions replaced, dropping any `default`. Gutenberg already had the negation. Tests are added for the attribute registration.

The others make implicit type conversions explicit in the layout and duotone code, and narrow the types used by `WP_Theme_JSON::get_feature_declarations_for_node()` so that it reports no errors even at PHPStan rule level 10. Since the node comes from `theme.json` data, that method now also checks that a feature is an array before reading its subfeatures. This fixes a fatal error ("Cannot unset string offsets") when a feature's value is a string, such as a `shadow`, and the block's selectors for that feature are a list rather than keyed by subfeature name, since each numeric key then reads a character of the string instead of a subfeature. The baseline entries for the resolved errors are removed.

Developed in WordPress/wordpress-develop#14862.
Follow-up to r56046, r56058, r56101, r62478, r63426.

Props justlevine, westonruter, poena, ramonopoly.
See #65817.

Built from https://develop.svn.wordpress.org/trunk@64727


git-svn-id: http://core.svn.wordpress.org/trunk@63877 1a063a9b-81f0-0310-95a4-ce76da25c4cd
@ingeniumed ingeniumed added the [Feature] Colors Color management label Nov 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Feature] Colors Color management Needs PHP backport Needs PHP backport to Core [Type] Code Quality Issues or PRs that relate to code quality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants