[wp-trac] [WordPress Trac] #62791: Could `pre_render_block` come later
WordPress Trac
noreply at wordpress.org
Wed Jan 8 21:19:44 UTC 2025
#62791: Could `pre_render_block` come later
----------------------------+-----------------------------
Reporter: helgatheviking | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: General | Version:
Severity: normal | Keywords:
Focuses: |
----------------------------+-----------------------------
In the course of some investigations, I noticed that
[`pre_render_block`](https://github.com/WordPress/wordpress-
develop/blob/d2a7bee9a6201f0276492ff29afd8c509480d266/src/wp-
includes/blocks.php#L2113) comes before [
`render_block_data](https://github.com/WordPress/wordpress-
develop/blob/d2a7bee9a6201f0276492ff29afd8c509480d266/src/wp-
includes/blocks.php#L2151)
and [`render_block_context`](https://github.com/WordPress/wordpress-
develop/blob/d2a7bee9a6201f0276492ff29afd8c509480d266/src/wp-
includes/blocks.php#L2187)
This means I am not able to conditionally use `pre_render_block` with
conditions based on either block context or programatically added
attributes. This seems limiting. (or at least it is in my current project,
where I am trying to modify an existing block when it's part of my block -
using my block's context)
Could `pre_render_block` come before actual rendering, but after these
other filters? Or could we add another filter at the beginning of
[`render()`](https://github.com/WordPress/wordpress-
develop/blob/287b2f8c961e8a67b2a232d37273b6ddfa611c28/src/wp-includes
/class-wp-block.php#L451)?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/62791>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list