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

[dlh]

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.

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 😊

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

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

Per ​https://github.com/WordPress/wordpress-develop/pull/4780#issuecomment-1623268596, I'll go ahead and close this PR.

The suggested fix is over at ​https://github.com/WordPress/gutenberg/pull/52364 😊

[azaozz]

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.

[isabel_brison]

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!