Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #45471, comment 17


Ignore:
Timestamp:
01/15/2025 02:23:56 PM (4 weeks ago)
Author:
justlevine
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #45471, comment 17

    initial v1  
    11Related: https://core.trac.wordpress.org/ticket/49442
    22
    3 While it doesn't specifically handle caching, the existing of a `parse_blocks` filter would make it straightforward to implement, as well as provide a pathway to solve the issue that prompted this ticket - Core does a lot of attribute manipulation when it's rendering (more so with Block Supports), so if you need to get those attributes programmatically there's no choice but to hit render_blocks() again. And if those _arent_ cached, then it's not just a performance issue; you also have to deal with things like static `wp_unique_(prefixed)_id()` and other "fun" issues with layout styles, modals, etc.
     3While it doesn't specifically handle caching, adding a `parse_blocks` filter would make caching straightforward to implement (you can't blindly extend someone else's `block_parser_class` override).
     4
     5It would also provide a holistic pathway to solve the issue that prompted this ticket - Core does a lot of attribute manipulation in an impure `render()` step (more so now with Block Supports), so if you need to get those attributes programmatically there's no choice but to hit render_blocks() again. And if those _arent_ cached, then it's not just a performance issue; you also have to deal with things like static `wp_unique_(prefixed)_id()` and other "fun" issues with layout styles, modals, etc.