Conversation
| } | ||
|
|
||
| $block_content = call_user_func( | ||
| $block_support_config['render_block'], |
There was a problem hiding this comment.
So far the block supports were only used to actually add classnames or inline styles to the wrapper, this PR is changing that by allowing them to register a generic hook for render_block.
The use-case for these is to potentially support static blocks (adding style and classes to static blocks that don't explicitly call the get_block_wrapper_attributes but also to allow adding style tags in addition to the block markup. These are needed by two Gutenberg PRs. WordPress/gutenberg#26752 and WordPress/gutenberg#29335
It's not entirely clear why this hook is better than just using render_block directly though.
There was a problem hiding this comment.
A bit late... but I see that the parent PR (WordPress/gutenberg#26752) is progressing nicely without this. Yes, I'm more in favour of not adding a new indirect API, just recommend render_block. If later we find that we have more compelling use cases for custom server rendering in block-supports, we can reassess.
Trac ticket: https://core.trac.wordpress.org/ticket/52476#ticket
In conjunction with WordPress/gutenberg#26361 for adding block supports for duotone filters, this adds a render hook for block supports.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.