Block Supports: Allow skipping serialization of individual features #36293
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -28,14 +28,15 @@ function gutenberg_register_layout_support( $block_type ) { | |
| /** | ||
| * Generates the CSS corresponding to the provided layout. | ||
| * | ||
| * @param string $selector CSS selector. | ||
| * @param array $layout Layout object. The one that is passed has already checked the existence of default block layout. | ||
| * @param boolean $has_block_gap_support Whether the theme has support for the block gap. | ||
| * @param string $gap_value The block gap value to apply. | ||
| * @param boolean $should_skip_gap_serialization Whether to skip applying the user-defined value set in the editor. | ||
|
There was a problem hiding this comment. Should we not also allow skipping serialization for the whole layout feature too? The Navigation block already implements custom logic to apply the layout styles to its inner elements and blocks, so there's definitely a use case. There was a problem hiding this comment.
Good point! Thanks for mentioning it. I think this would be a good follow up PR. I'm guessing @aaronrobertshaw started the work here with a view of extending block supports (border, spacing et. al) that already use The layout implementation, being a little "different" might also need a level of testing that might be more suited to a dedicated PR. 😄 There was a problem hiding this comment. Yup, layout is complex enough that a follow-up PR sounds right. There was a problem hiding this comment. I'm only just getting up to speed after some recent AFK so might be missing some context. When originally creating this I found a few block supports that simply didn't maintain/add the ability to skip serialization as per other block supports. Layout was one example of this. It also changed several times during the long life span of this PR. Early on, I had a skip for the entire layout feature but the support was reworked which, from memory, removed the code where that could easily be performed. I think a separate PR would definitely be a good idea given how complicated layout support is and how much it's already changed in its relatively short life. |
||
| * | ||
| * @return string CSS style. | ||
| */ | ||
| function gutenberg_get_layout_style( $selector, $layout, $has_block_gap_support = false, $gap_value = null, $should_skip_gap_serialization = false ) { | ||
| $layout_type = isset( $layout['type'] ) ? $layout['type'] : 'default'; | ||
|
|
||
| $style = ''; | ||
|
|
@@ -69,7 +70,7 @@ function gutenberg_get_layout_style( $selector, $layout, $has_block_gap_support | |
| if ( is_array( $gap_value ) ) { | ||
| $gap_value = isset( $gap_value['top'] ) ? $gap_value['top'] : null; | ||
| } | ||
| $gap_style = $gap_value && ! $should_skip_gap_serialization ? $gap_value : 'var( --wp--style--block-gap )'; | ||
|
There was a problem hiding this comment. If we're skipping serialization would we still expect there to be an output on the front end, even if it's a default value? There was a problem hiding this comment. Yeah, this is another tricky one. 🤣 I agree in principle, and it did cross my mind, however there's a consideration that caused me to hesitate: So my reasoning at the time was, since Skipping serialization, as far as I understand it, skips user-facing block customization, that is the editor styles controls. Aside from all that, Hopefully we can consolidate/homogenize the use of layout and blockGap in the effort to make styles and layouts consistent. See #39336 There was a problem hiding this comment. Yeah this is a tough one. On the whole I'm more inclined to leave it out because the theme only defines the variable value, not where to use it, and I'd expect skipSerialization to not output anything. But I think we can leave it as is and revisit later; outputting a couple of default styles shouldn't be a huge deal. |
||
| $style .= "$selector > * { margin-block-start: 0; margin-block-end: 0; }"; | ||
| $style .= "$selector > * + * { margin-block-start: $gap_style; margin-block-end: 0; }"; | ||
| } | ||
|
|
@@ -99,7 +100,7 @@ function gutenberg_get_layout_style( $selector, $layout, $has_block_gap_support | |
| $gap_column = isset( $gap_value['left'] ) ? $gap_value['left'] : '0.5em'; | ||
| $gap_value = $gap_row === $gap_column ? $gap_row : $gap_row . ' ' . $gap_column; | ||
| } | ||
| $gap_style = $gap_value && ! $should_skip_gap_serialization ? $gap_value : 'var( --wp--style--block-gap, 0.5em )'; | ||
| $style .= "gap: $gap_style;"; | ||
| } else { | ||
| $style .= 'gap: 0.5em;'; | ||
|
|
@@ -172,7 +173,10 @@ function gutenberg_render_layout_support_flag( $block_content, $block ) { | |
| $gap_value = preg_match( '%[\\\(&=}]|/\*%', $gap_value ) ? null : $gap_value; | ||
| } | ||
|
|
||
| // If a block's block.json skips serialization for spacing or spacing.blockGap, | ||
| // don't apply the user-defined value to the styles. | ||
| $should_skip_gap_serialization = gutenberg_should_skip_block_supports_serialization( $block_type, 'spacing', 'blockGap' ); | ||
| $style = gutenberg_get_layout_style( ".$class_name", $used_layout, $has_block_gap_support, $gap_value, $should_skip_gap_serialization ); | ||
| // This assumes the hook only applies to blocks with a single wrapper. | ||
| // I think this is a reasonable limitation for that particular hook. | ||
| $content = preg_replace( | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| <?php | ||
| /** | ||
| * Block support utility functions. | ||
| * | ||
| * @package gutenberg | ||
| */ | ||
|
|
||
| /** | ||
| * Checks whether serialization of the current block's supported properties | ||
| * should occur. | ||
| * | ||
| * @param WP_Block_type $block_type Block type. | ||
| * @param string $feature_set Name of block support feature set.. | ||
| * @param string $feature Optional name of individual feature to check. | ||
| * | ||
| * @return boolean Whether to serialize block support styles & classes. | ||
| */ | ||
| function gutenberg_should_skip_block_supports_serialization( $block_type, $feature_set, $feature = null ) { | ||
| if ( ! is_object( $block_type ) || ! $feature_set ) { | ||
| return false; | ||
| } | ||
|
|
||
| $path = array( $feature_set, '__experimentalSkipSerialization' ); | ||
| $skip_serialization = _wp_array_get( $block_type->supports, $path, false ); | ||
|
|
||
| if ( is_array( $skip_serialization ) ) { | ||
| return in_array( $feature, $skip_serialization, true ); | ||
| } | ||
|
|
||
| return $skip_serialization; | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a thought: I'm wondering what this might look like if elements is made generic as mentioned in #31524. If we can use it with any element in any style, perhaps skipping serialization will be redundant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good question, and one I can't answer, though from a superficial reading of the supports file and the conversation of the PR you linked to, I'd probably side with you on that assumption. 😄
I'm not sure there are any plans slated for the future of the elements mechanism 🤔
cc @jorgefilipecosta
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now we are artificially limiting to some elements like links but the mechanism is generic and we can expand it. I'm not sure if someone is working on that.
I agree ideally the elements mechanism would remove the need to skip serialization but I guess until that mechanism is expanded we can have experimental flags to skip serializtion and then we check if we can use elements for these cases.