[wp-trac] [WordPress Trac] #51612: `render_block_data` for nested blocks - WP_Block::render vs render_block

[WordPress Trac]

#51612: `render_block_data` for nested blocks - WP_Block::render vs render_block
----------------------------------------+-----------------------------
 Reporter:  gaambo                      |       Owner:  (none)
     Type:  defect (bug)                |      Status:  assigned
 Priority:  normal                      |   Milestone:  Future Release
Component:  Editor                      |     Version:  5.5
 Severity:  normal                      |  Resolution:
 Keywords:  has-unit-tests needs-patch  |     Focuses:
----------------------------------------+-----------------------------

Comment (by gaambo):

 This is still (WP 5.7) a very big problem for nearly every project I build
 with the block editor. As soon as you put a block into any "wrapper" (eg
 Media & Text, Group, etc.) `pre_render_block` and `render_block_data` do
 not get called.
 A few use cases I see:
 - I often use `pre_render_block` to call a function which adds an action/a
 filter into a more generatel hook but only needed for this specific block
 (e.g. if I want to filter the Latest Posts Blocks query with
 `pre_get_posts`)
 - Use `pre_render_block` to short-circuit rendering of a nested block for
 non-loggedin-users (eg. on a member site)
 - Use `render_block_data` to pass additional data to the block (maybe this
 could be done with context, but often times I'm using these hooks to add
 to third party blocks).

 I don't see any reason for these hooks not to be called for nested blocks,
 especially with FSE on the way there will be more complex layouts which
 need nesting.

 I read through all the comments here and it seems the biggest problem is
 that `WP_Block` was introduced without a real reason and it is not clearly
 defined how `WP_Block` should be used. In this case I think it's important
 to define the usecase and document it clearly very soon. Because when more
 and more theme and plugin developers will build blocks and there are no
 clear guidelines for its usage, we'll see more different usages and it
 will be harder to have a well defined interface.

 My findings so far:

 - `WP_Block_Type` represents a block **type** (similar to `WP_Post_Type`)
 - `WP_Post_Type` is a final class and not intended to be subclassed for
 registration etc.
 - A `WP_Block` instance is only created when a parsed block should be
 rendered (from `render_block`). For each parsed innerBlock a new instance
 is created as well.
 - `WP_Block_List` is an array interface for all the innerBlocks of a
 `WP_Block` instance

 To keep the interface similar to posts, I would suggest making
 `WP_Block_Type` a final class - there is one plugin (and no theme) in the
 repository right now which extends this class (see
 [https://wpdirectory.net/search/01F37VWFKJ46B1Z7YVMHKXFC9F| wpdirectory
 search for `extends WP_Block_Type`]). Therefore I assume there are little
 to none premium plugins/themes which extend it, a dev-note should be
 enough imho.
 I've ran a few searches: `extends WP_Block_Type`, `extends
 \WP_Block_Type`, `new WP_BlockType` (there are a few cases of that, but I
 don't see any problem with that).

 I'm not sure about `WP_Block`. It's kind of similar to `WP_Post` in a
 sense that it has data from the database set as properties. But it has one
 method which generates dynamic output (`render`) and a constructor which
 initialized other objects (`WP_Block_List` with `WP_Block` instances). I
 think `WP_Block` should be final as well and all the render logic should
 be put back to the `render_block` function as in before #49926 . Therefore
 the `WP_Block` constructor doesn't have to do some complex juggling of
 filtered/parsed/non-filtered data.

 There were thoughts about just implementing `WP_Block` as an ArrayAcces
 data object in the [https://github.com/WordPress/gutenberg/pull/21467|
 original Gutenberg PR].
 The issue of filters only running on top-level-blocks was even mentioned
 in [https://github.com/WordPress/gutenberg/pull/21921| a related PR].
 I've got to admin I'm a little confused to what was changed and reverted
 when 😅
 I've also searched
 on wpdirectory.net for `extends WP_Block` and only Blocksy extends
 `WP_Block_Parser`.

 I think extracting the `render` method back to `render_block` should be an
 easier fix, but someone with more experience and knowledge of block
 context/globals etc would have to check for that.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51612#comment:48>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform