[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