[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:32 TimothyBlynJacobs]:
 > I think this should probably be reverted and tried again in 5.7-early.
 This has more ramifications than was previously thought, that should be
 resolved in Beta not RC.

 Yeah, starting to look that way.

 > > When it is instantiated it has unfiltered (wrong?) data
 >
 > IMO this isn't incorrect data. I think it would be incorrect if the
 render filters were used when the block wasn't in a render context.

 Yeah, the render filters would ideally run while the block is being
 rendered (judging by their names). However before this change they were
 running before WP_Block was even instantiated. Running them "late" seems
 to bring unneeded complexity and problems.

 One possible solution could be to deprecate these filters and leave them
 in place, then introduce new "render" filters that run in `render()` and
 do not mutate the block properties. On the other hand deprecating
 something and leaving it in place means plugins that already use these
 filters would likely never change...

 Another (preferable?) solution would be to remove (and shim)
 `WP_Block::render()`, i.e. do the rendering as soon as WP_Block is
 instantiated. Seems this will bring WP_Block more inline with WP_Post,
 WP_Term, etc.

 > I think this is analogous to `WP_Post::filter` and `WP_Term::filter`.
 Maybe we should make the `WP_Block` follow that filter API pattern instead
 to be more clear.

 `WP_Post::filter` seems to hold the level of sanitization of the post,
 doesn't seem to affect specifically the hooks/filters.

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