[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:  noisysocks
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  5.6
Component:  Editor                    |     Version:  5.5
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:34 TimothyBlynJacobs]:
 > But only if `render_block` is the only consumer of `WP_Block`, which I
 don't think we want to constrain in that way.
 > ...
 > if someone is trying to use `WP_Block` as a data structure, and they
 don't need the rendered content...

 Right. In this case guessing plugins and themes will have to learn to live
 with the fact that WP_Block is different than WP_Post and is "mutable".
 Still thinking this should be described in more details, perhaps in the
 top docblock.

 However thinking that resetting the properties after rendering (i.e. the
 class properties are different before running render(), while running
 render(), and after running render()) makes things more complex, and hard
 to understand and work with. Same for the magic `__get()`.

 Probably missing something but what purpose/use case does this solve?
 Seems these properties can be instantiated with `null`, then set during
 `render()`. Why do they need to be unset/reset after that?
 `render_block()` calls `$block->render()` immediately after instantiating
 WP_Block, so these will be (should be) correct there.

 > Right but the sanitization is a series of filters on the individual post
 fields. Including a `display` filter.

 Right, the difference is not to misunderstand that "filter" in
 `WP_Post::filter` means filtering/sanitization of the post object values,
 nothing to do (directly) with hooks.

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