WordPress.org

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #51612, comment 29


Ignore:
Timestamp:
11/24/2020 10:31:03 AM (3 months ago)
Author:
azaozz
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #51612, comment 29

    initial v1  
    11May 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.
    22
    3 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.).
     3This seems to bring a lot of complexity/possible confusion when using it, and some back-compat concerns. Before [49608] WP_Block 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.).
    44
    55Not 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.