-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support skipping serialization in the color hook (block supports mechanism) #29142
Conversation
Dynamic blocks that do not want serialization could avoid it by not calling get_block_wrapper_attributes. However, there may be cases in which some attributes should be serialized and others should not.
Size Change: +260 B (0%) Total Size: 1.38 MB
ℹ️ View Unchanged
|
One thing I've noticed by trying this out in the social links block is that the current color panel uses "Icon color" and "Icon background color" as names while the block supports mechanism uses "Text color" and "Background color" (and doesn't allow blocks to change it), see:
Given the current direction (allow the serialization from block attributes => DOM to be up to the block), I think we need the ability for blocks to change the names of this as well. Was thinking about how to integrate this into the supports mechanism. We are also going to need to declare "selectors" per property as per #28913
|
I'm not sure I like the "meta" indirection. The labels could be just |
@youknowriad makes sense. So, this should be ready to land then. I can work on adding the labels and selectors as follow-ups PRs, to keep PRs very small and focused to reduce the reviewer's time required to land them. |
I've added the list of tasks at #28913 Will keep it updated as things evolve. |
lib/block-supports/colors.php
Outdated
@@ -60,6 +60,14 @@ function gutenberg_register_colors_support( $block_type ) { | |||
*/ | |||
function gutenberg_apply_colors_support( $block_type, $block_attributes ) { | |||
$color_support = gutenberg_experimental_get( $block_type->supports, array( 'color' ), false ); | |||
|
|||
if ( array_key_exists( 'skipSerialization', $color_support ) && $color_support['skipSerialization'] ) { | |||
return array( |
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.
We can probably return an empty array here, don't you think?
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.
Oh, yes, it doesn't make sense as it was. Fixed in 29d4578
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.
This is looking good to me, I was wondering whether we should start using an experimental flag or maybe this is something we're certain of at this point?
You mean |
I will push that change after lunch and will merge. |
This PR implements the first step in supporting a more fine-grained block supports mechanism as described at #28913
Follow-up PRs should be created to migrate specific blocks to use this. The testing steps illustrate a use case for this: make the social links use the colors from the block support mechanism, so they are exposed from theme.json.
How has this been tested?
Using the TT1-blocks:
Compile this branch.
Go to the post editor and create a social links block with some icons:
textColor
andbackgroundColor
attributes and they have the same value as the color you selected.