Block Hooks: Wrongly typed context when updating wp_navigation post meta

[Bernhard Reiter]

update_ignored_hooked_blocks_postmeta passes a $context argument to apply_block_hooks_to_content that is used by the hooked_block_types, hooked_block, and hooked_block_{$hooked_block_type} filters, if any.

Those filters allow extenders to conditionally insert hooked blocks, based on criteria that might involve the $context argument. For example, a filter might check if ( $context instanceof WP_Post && 'wp_navigation' === $context->post_type ) to limit insertion of a hooked block to Navigation blocks only.

While other functions that also call apply_block_hooks_to_content pass a correctly typed $context, update_ignored_hooked_blocks_postmeta passes a stdObject rather than a WP_Post instance. As a result, a criterion like in the above filter example will fail -- thus not correctly setting ignoredHookedBlocks metadata for the wp_navigation post object in question.

Discovered while working on #7898. Details to follow.

Trac ticket: https://core.trac.wordpress.org/ticket/62639

[Bernhard Reiter]

Noting that the bug is present in 6.7.x, but not in 6.6.x. It was caused by [58578].

[Bernhard Reiter]

In 59482:

Block Hooks: Fix context in update_ignored_hooked_blocks_postmeta.

Ensure that the $context arg passed from update_ignored_hooked_blocks_postmeta to apply_block_hooks_to_content (and from there, to filters such as hooked_block_types and hooked_block) has the correct type (WP_Post).

Filters hooked to hooked_block_types etc can typically include checks that conditionally insert a hooked block depending on $context. Prior to this changeset, a check like if ( $context instanceof WP_Post ) would incorrectly fail, as $context would be a stdClass instance rather than a WP_Post. As a consequence, a hooked block inside of a Navigation post object that was modified by the user would not be marked as ignored by update_ignored_hooked_blocks_postmeta, and thus be erroneosly re-inserted by the Block Hooks algorithm.

Props bernhard-reiter.
Fixes #62639.

Committed to Core trunk in https://core.trac.wordpress.org/ticket/62639.

[Bernhard Reiter]

Replying to Bernhard Reiter:

Noting that the bug is present in 6.7.x, but not in 6.6.x. It was caused by [58578].

Reopening to solicit approval by another Core Committer for backporting to the 6.7 branch.

[cbravobernal]

Reviewed and work as expected. Backporting to 6.7 branch.

[cbravobernal]

In 59487:

Block Hooks: Fix context in update_ignored_hooked_blocks_postmeta.

Ensure that the $context arg passed from update_ignored_hooked_blocks_postmeta to apply_block_hooks_to_content (and from there, to filters such as hooked_block_types and hooked_block) has the correct type (WP_Post).

Filters hooked to hooked_block_types etc can typically include checks that conditionally insert a hooked block depending on $context. Prior to this changeset, a check like if ( $context instanceof WP_Post ) would incorrectly fail, as $context would be a stdClass instance rather han a WP_Post. As a consequence, a hooked block inside of a Navigation post object that was modified by the user would not be marked as ignored by update_ignored_hooked_blocks_postmeta, and thus be erroneosly re-inserted by the Block Hooks algorithm.

Reviewed by cbravobernal.
Merges [59482] to the 6.7 branch.

Props bernhard-reiter.
Fixes #62639.