Make WordPress Core

#58699 closed defect (bug) (fixed)

Post ID and post type block context no longer available to all 'render_block_context' filters

Reported by: dlh's profile dlh Owned by: bernhard-reiter's profile Bernhard Reiter
Milestone: 6.3 Priority: normal
Severity: normal Version: 6.3
Component: Editor Keywords: gutenberg-merge has-patch
Focuses: Cc:

Description

In GB 50313 (synced to core in [56065]), the post template block was updated so that the postType and postId context values are provided via the render_block_context filter, rather than passed directly to the WP_Block instance.

This change is not fully compatible with existing code that filters render_block_context and targets the post template block. Previously, it was always possible to derive additional context for the block from the post ID or type because those values were already in the block context when render_block_context was applied. Now, the post ID and type aren't available to filters until, realistically, priority 11 or later, since the new filter is hooked into render_block_context "just in time" at priority 10, making it likely to be the last function added to the filter and the last to run.

I recognize the benefits of the filter outlined in the GB PR and can understand that those benefits might be worth incurring some backwards incompatibility. Still, I think a good-faith effort can be made to minimize that incompatibility by using a low priority such as 0 for the new filter. This lower priority would help ensure that most existing render_block_context filters, including those at the default priority of 10, continue to have access to the post ID and type values in the context array.

The linked PR changes the priority for the context filter in the post template block. I have no experience with the comment template filter, but, seeing a similar update to that block in the same core commit, I've made the same change in priority there.

Change History (12)

This ticket was mentioned in PR #4780 on WordPress/wordpress-develop by dlh01.


11 months ago
#1

  • Keywords has-patch added

This ticket was mentioned in Slack in #core-editor by dlh. View the logs.


11 months ago

@Bernhard Reiter commented on PR #4780:


11 months ago
#3

Good catch; this admittedly didn't occur to me when working on https://github.com/WordPress/gutenberg/pull/50313.

I think your solution makes sense; I was briefly debating whether we should use a slightly higher value (e.g. 5) for priority in order to allow other filters to kick in earlier, but I think it's true that from a backwards-compat point-of-view, using the lowest possible value is the closest we can get to retain the previous behavior.

However, this change will need to go "through" Gutenberg: As the e2e tests are flagging, blocks' dynamic PHP code is synced from the @wordpress/block-library npm package at build time in Core -- any changes made directly to that Code in Core will be flagged as a collision.

I'll go ahead and will file a GB PR 😊

@Bernhard Reiter commented on PR #4780:


11 months ago
#4

I'll go ahead and will file a GB PR 😊

https://github.com/WordPress/gutenberg/pull/52364

#5 @Bernhard Reiter
11 months ago

  • Owner set to Bernhard Reiter
  • Status changed from new to accepted

#7 @Bernhard Reiter
11 months ago

  • Component changed from General to Editor
  • Milestone changed from Awaiting Review to 6.3

#8 @azaozz
11 months ago

The PR makes sense here too.

However, this change will need to go "through" Gutenberg: As the e2e tests are flagging, blocks' dynamic PHP code is synced from the @wordpress/block-library npm package at build time in Core

Yep, just a quick reminder 6.3 RC is in few days. Also guessing there would probably be other fixes that would require new Gutenberg packages, can probably be combined.

Last edited 11 months ago by azaozz (previous) (diff)

This ticket was mentioned in Slack in #core by oglekler. View the logs.


11 months ago

#10 @oglekler
11 months ago

  • Keywords gutenberg-merge added

This ticket was mentioned in Slack in #core by mukeshpanchal27. View the logs.


11 months ago

#12 @isabel_brison
11 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

This one can be closed as the fix for it in Gutenberg: https://github.com/WordPress/gutenberg/pull/52364 was added to the npm package updates for Beta 4 last week.

Thanks everyone!

Note: See TracTickets for help on using tickets.