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

WordPress Trac noreply at wordpress.org
Fri Nov 6 00:08:08 UTC 2020


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

Comment (by noisysocks):

 > Do you think it should be called in WP_Block::construct or
 WP_Block::render?

 No preference 🙂

 > I think render makes a little more sense, that would mean extracting
 this filters from render_block - which makes this function very thin.
 Would that be okay?

 Maybe in an ideal world we'd delete `render_block` but because WordPress
 is committed to backwards compatibility we're forced to keep it around
 forever.

 But that's OK. I view `render_block` as a convenience function that wraps
 `new WP_Block(...)->render()`.

 > Gotta admit I'm a little overwhelmed with this function and all the
 context stuff happing, so can't really help with a patch here, but can
 help with testing.

 No worries at all. Block context is definitely tricky and hard to reason
 about, though worth noting that there are unit tests for `WP_Block` which
 ought to catch any accidental regressions.

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


More information about the wp-trac mailing list