Add: Frontend section presets output#42124
Conversation
2614fb1 to
51b5d5f
Compare
f8f9a66 to
dee4708
Compare
dee4708 to
97499c4
Compare
| foreach ( $selectors as $inner ) { | ||
| $outer = trim( $outer ); | ||
| $inner = trim( $inner ); | ||
| if ( empty( $outer ) ) { |
There was a problem hiding this comment.
This is purely a style choice, it's totally up to you. Personally, I find this more readable:
if ( empty( $outer ) && empty( $inner) ) { }
else if ( empty( $outer ) ) {}
else if ( empty( $inner ) ) {}
else {}| * // $merged is '.a > .x, .a .y, .b .c > .x, .b .c .y' | ||
| * </code> | ||
| * | ||
| * @since 5.9.0 |
There was a problem hiding this comment.
Is it removing this and add a comment with what changed? I understand the change is making sure no empty scope ends up being used, but not sure why we didn't that before.
There was a problem hiding this comment.
I don't think the changes we are making to the function are worth a comment. We are just fixing some cases with empty selectors.
|
It seems the selectors for the CSS Custom Properties are scoped the other way around: .wp-settings-4884af9a06466a917323943b61ae5826,
[class*="wp-block"] .wp-settings-4884af9a06466a917323943b61ae5826,
li .wp-settings-4884af9a06466a917323943b61ae5826,
.wp-block-button .wp-block-button__link .wp-settings-4884af9a06466a917323943b61ae5826,
h1 .wp-settings-4884af9a06466a917323943b61ae5826,
h2 .wp-settings-4884af9a06466a917323943b61ae5826,
h3 .wp-settings-4884af9a06466a917323943b61ae5826,
h4 .wp-settings-4884af9a06466a917323943b61ae5826,
h5 .wp-settings-4884af9a06466a917323943b61ae5826,
h6 .wp-settings-4884af9a06466a917323943b61ae5826,
ol .wp-settings-4884af9a06466a917323943b61ae5826,
ul .wp-settings-4884af9a06466a917323943b61ae5826,
p .wp-settings-4884af9a06466a917323943b61ae5826,
.wp-block-table > table .wp-settings-4884af9a06466a917323943b61ae5826,
.wp-settings-4884af9a06466a917323943b61ae5826 * {
--wp--preset--color--global-aquamarine: aquamarine;
--wp--preset--color--global-pink: pink;
}
.wp-settings-4884af9a06466a917323943b61ae5826 .wp-block-button .wp-block-button__link {
--wp--preset--color--button-red: red;
--wp--preset--color--button-blue: blue;
}``` |
| $style_nodes = static::get_style_nodes( $this->theme_json, $blocks_metadata ); | ||
| $setting_nodes = static::get_setting_nodes( $this->theme_json, $blocks_metadata ); | ||
|
|
||
| $root_style_key = array_search( static::ROOT_BLOCK_SELECTOR, array_column( $style_nodes, 'selector' ), true ); |
There was a problem hiding this comment.
Nice one ❤️ Wasn't super comfortable hard-coding the 0 index.
| } | ||
| $stylesheet .= $this->get_block_classes( $style_nodes ); | ||
| } elseif ( in_array( 'base-layout-styles', $types, true ) ) { | ||
| $root_selector = static::ROOT_BLOCK_SELECTOR; |
There was a problem hiding this comment.
This gist of code is not used at the moment, correct? My understanding is that it is just a way to make the scope and root_selector options work with this part of the code as well. I wasn't sure how to test this.
There was a problem hiding this comment.
Yes, it is not used at the moment, but it is to make sure the function also works with base-layout-styles origin. I don't think it will be needed but I preferred to make the function consistent.
| } elseif ( in_array( 'base-layout-styles', $types, true ) ) { | ||
| $root_selector = static::ROOT_BLOCK_SELECTOR; | ||
| $columns_selector = '.wp-block-columns'; | ||
| if ( ! empty( $options['scope'] ) ) { |
There was a problem hiding this comment.
Shouldn't this be?
| if ( ! empty( $options['scope'] ) ) { | |
| if ( ! empty( $options['root_selector'] ) ) { |
oandregal
left a comment
There was a problem hiding this comment.
Thanks for the quick turnaround, Jorge!
I've left some minor comments, but I won't be available tomorrow to review/re-approve, so I trust they'll be addressed.
I'm more comfortable with this approach, as it doesn't introduce new APIs just yet. Through the conversations in this thread, I've learned that WP_Theme_JSON is no longer agnostic of the context it runs into, and the changes here go a step in the direction of making them agnostic again. It's far for complete, though.
|
Thank you a lot for the review @oandregal!
The parameters order was wrong on the last commit. It is fixed. All the feedback was applied! |
|
IIUC, we'll want to include this in GB 14.2 in order to unblock this |
|
Cherry-picked this into |
|
Hey, while working on #46579 I realized this PR was not backported to WordPress 6.1. When we land that PR and then backport to WordPress 6.2 everything will be fine, but I wanted to raise in case you think this should be ported for a potential WordPress 6.1.X release. |
|
@jorgefilipecosta, does this change have a WP core backport PR? Unfortunately, I wasn't able to find any. |
Part of #40318.
This PR allows a block to define the preset settings of its nested blocks using the same shape as theme.json.
Continuation of #40547.
Shape
Formatted json:
Engine output
What?
It follows what was defined in #40547. The presets of a section overwrite everything set on the theme.json, even block-specific presets, so for the global presets of a section, we need to overwrite any block-specific settings as discussed in the other PR, which makes a complex CSS rule.
It follows the algorithms that were discussed with @oandregal and @youknowriad.
Testing
I pasted the group block above in the editor and verified the output on the front was the one also shared above and identical to the following screenshot:
