[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