[wp-trac] [WordPress Trac] #51850: WP_Block: Inner blocks not being set
WordPress Trac
noreply at wordpress.org
Tue Nov 24 10:01:55 UTC 2020
#51850: WP_Block: Inner blocks not being set
--------------------------------------+-------------------------
Reporter: noisysocks | Owner: noisysocks
Type: defect (bug) | Status: assigned
Priority: normal | Milestone: 5.6
Component: Editor | Version: 5.6
Severity: normal | Resolution:
Keywords: has-patch has-unit-tests | Focuses:
--------------------------------------+-------------------------
Comment (by azaozz):
Replying to [comment:5 noisysocks]:
> We want to call `pre_render_block`, `render_block_data`, and
`render_block_context` in `WP_Block::render()` as it is not intuitive for
these "render" filters to be called in the constructor.
`WP_Block::$inner_blocks`, `WP_Block::$inner_html`, and
`WP_Block::$inner_content` are all derived from the result of calling
these filters.
Thanks for the explanation :)
That seems to introduce two states of `WP_Block`, one with data from
before the filters are run, and another after the filters (after
`render()`). This seems to bring some back-compat problems: filters were
run on the block data before WP_Block was instantiated, so the filtered,
"correct" data was in the instance from the beginning. Now the "correct"
data is available only after `WP_Block::render()` has been run.
Then as far as I see the magic `__get()` and `__isset()` are needed to
support getting pre-filtered (wrong?) data?
Going to reopen #51612 with the above questions.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/51850#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list