Repository navigation
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
andrewserong
left a comment
There was a problem hiding this comment.
This is smoke testing well for me, adds some good hardening IMO, and is a faithful backport of the GB PR.
LGTM!
| $base_spacing_scale = _wp_array_get( $this->theme_json, $scale_path, array() ); | ||
| if ( is_array( $base_spacing_scale ) ) { | ||
| $flattened_spacing_scale = array_replace( $flattened_spacing_scale, $base_spacing_scale ); | ||
| } | ||
|
|
||
| $spacing_scale = _wp_array_get( $incoming_data, $scale_path, null ); | ||
| if ( ! isset( $spacing_scale ) ) { | ||
| if ( ! is_array( $spacing_scale ) ) { |
aaronrobertshaw
left a comment
There was a problem hiding this comment.
This is looking pretty close to me 👍
✅ Matches #84523 and #84529
✅ New test cases are easy to follow
There are only a couple of things I noticed this time around:
The root styles.css guard in get_stylesheet() is the only new check without a test.
Maybe we could we add a root case to the new data provider?
E.g. array( 'styles' => array( 'css' => array( 'color' => 'red' ) ) )
The last one is pretty minor but the deprecated get_custom_css() still reads root styles.css without a type check. An array there would still trigger a warning.
Prevents `WP_Theme_JSON` from throwing fatal `TypeError`s when theme.json or global styles data contains values of the wrong type. Sanitization keeps schema leaves such as `css` and `spacingScale` whatever their type, so, for example, an array `css` value reached `explode()` in `process_blocks_custom_css()`. Values of unexpected types are now ignored: non-string `css` and `ref` values, a non-array `spacingScale` or non-string `spacingScale.unit`, shared block style variations that are not arrays, and `blockTypes` items that are not strings. Backports WordPress/gutenberg#84523. See #66286.
Backports WordPress/gutenberg@ba8f807c5f from WordPress/gutenberg#84523. See #66286.
…ging.
`WP_Theme_JSON::merge()` passed per-origin `spacingScale` values straight to `array_replace()`, so a scale such as `{ "theme": "1.5" }` caused a fatal `TypeError`. Base and incoming per-origin spacing scales that are not arrays are now skipped.
Backports WordPress/gutenberg#84529.
See #66286.
Adds a root `styles.css` case to the unexpected types data provider and requests the `custom-css` type from `get_stylesheet()`, which the root custom CSS check only runs for. See #66286.
f915516 to
f73b2da
Compare
This commit prevents `WP_Theme_JSON` from throwing fatal TypeErrors when theme.json or global styles data contains values of the wrong type. Those values could be user- or AI-generated. The checks in this commit cover spacing scale arrays, block variation selectors, and custom block CSS processing. The motivation arose from a real-life PHP fatal where `WP_Theme_JSON::process_blocks_custom_css` attempted to explode a non-string. Developed in: #14190 Props ramonopoly, aaronrobertshaw, andrewserong. Fixes #66286. git-svn-id: https://develop.svn.wordpress.org/trunk@64309 602fd350-edb4-49c9-b593-d223f7449a82
This commit prevents `WP_Theme_JSON` from throwing fatal TypeErrors when theme.json or global styles data contains values of the wrong type. Those values could be user- or AI-generated. The checks in this commit cover spacing scale arrays, block variation selectors, and custom block CSS processing. The motivation arose from a real-life PHP fatal where `WP_Theme_JSON::process_blocks_custom_css` attempted to explode a non-string. Developed in: WordPress/wordpress-develop#14190 Props ramonopoly, aaronrobertshaw, andrewserong. Fixes #66286. Built from https://develop.svn.wordpress.org/trunk@64309 git-svn-id: http://core.svn.wordpress.org/trunk@63459 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Trac ticket: https://core.trac.wordpress.org/ticket/66286
Backports WordPress/gutenberg#84523 and WordPress/gutenberg#84529
What
Stops
WP_Theme_JSONfrom throwing fatalTypeErrors when theme.json or global styles data contains values of the wrong type.Why
The Gutenberg report came from a live site where every front-end page fatalled:
sanitize()keeps schema leaves such ascssandspacingScalewhatever their type, so an arraycssvalue reachesexplode()inprocess_blocks_custom_css(). The same gap fatals in a few other places.What changed
Values of unexpected types are now ignored instead of crashing:
cssthat isn't a string produces no output (the reported crash).refthat isn't a string is ignored.spacingScalethat isn't an array, or aspacingScale.unitthat isn't a string, is ignored.blockTypesitems that aren't strings, are skipped.Valid data is unaffected.
Each case has a test. All nine new cases fail on trunk with a
TypeError.