[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 commit  |     Focuses:
---------------------------------------------+-------------------------
Changes (by azaozz):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 May be overthinking this but [49608] seems to introduce two "states" of
 WP_Block. When it is instantiated it has unfiltered (wrong?) data, then
 after `render()` is run the data is reset to the filtered values.

 This seems to bring a lot of complexity/possible confusion when using it,
 and some back-compat concerns. Before [49608] was instantiated with the
 filtered data that was (more or less) immutable while the instance is
 used. Now the data is mutated after `render()` (hence the need for
 `WP_Block::reset()`, `__get()`, etc.).

 Not sure if this is a good change going forward. It's true that
 `WP_Block::$parsed_block` is public and plugins can "hack it" at any time
 (that btw doesn't seem like a good idea too), but having an instance with
 unfiltered data doesn't seem useful/helpful.

 A possible solution may be to run the existing filters as soon as WP_Block
 is instantiated (in the constructor, as mentioned above) and perhaps
 introduce new filter(s) in `render()` that only affect the output HTML, if
 needed.

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