[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 azaozz):

 Replying to [comment:48 gaambo]:

 Thanks for the excellent break-down!

 > 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.

 Right, this needs to be fixed, one way or the other.

 > 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.

 Yes, seems that way especially around "top level block" vs. "nested
 block".

 > 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

 As far as I see that's correct.

 > To keep the interface similar to posts, I would suggest making
 `WP_Block_Type` a final class

 That's a good idea but not really sure it can be "pulled off". As there is
 only one plugin (and the author(s) can probably be contacted) perhaps this
 can be done. Still, the possibility of a fatal error in custom
 themes/plugins is pretty "scary" :)

 > 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.

 Yes, my thoughts too. Unfortunately don't think it can be made `final`
 now. I would have really liked if that `render()` method wasn't in there
 and the class was implemented as "data store" similarly to `WP_Post`.

 On the other hand `WP_Block` can also be a "container" for other instances
 of `WP_Block` which makes it more complicated to work with. Thinking that
 needs to be documented well.

 > 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.

 Yeah, thinking that can be done.

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