[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