[wp-trac] [WordPress Trac] #60506: Block Hooks: Newly inserted anchor block doesn't ignore hooked blocks set by filter

WordPress Trac noreply at wordpress.org
Mon Feb 12 13:56:32 UTC 2024


#60506: Block Hooks: Newly inserted anchor block doesn't ignore hooked blocks set
by filter
-----------------------------+-----------------------------
 Reporter:  Bernhard Reiter  |      Owner:  Bernhard Reiter
     Type:  defect (bug)     |     Status:  assigned
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  General          |    Version:  trunk
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 Per [57594], hooked blocks will be injected into modified templates and
 template parts. This has one side effect: If a new instance of an anchor
 block is inserted into the editor, it either needs its hooked blocks
 inserted alongside it, or at least its `ignoredHookedBlocks` attribute set
 (to prevent the Block Hooks mechanism running on the frontend, and
 inserting hooked blocks that aren't present in the editor, which would
 violate editor/frontend parity, a core tenet for Block Hooks).

 https://github.com/WordPress/gutenberg/pull/58553 (which is included in GB
 17.7 RC1 and thus will be in WP 5.6) partly resolves this issue by setting
 the `ignoredHookedBlocks` attribute for newly inserted anchor blocks based
 on the `blockHooks` field set in a block's `block.json` (and exposed via
 the `block-types` REST API endpoint).

 However, that approach has one shortcoming: It is unaware of any hooked
 blocks added ''conditionally'', i.e. via the `hooked_block_types` filter,
 as the latter isn't reflected in the `block-types` endpoint (and cannot be
 by design, as it can limit hooked blocks to a given context -- such as a
 specific template or template part).

 As a result, the `ignoredHookedBlocks` metadata will ''not'' be set on a
 newly inserted anchor block for any hooked blocks that were added by the
 `hooked_block_types` filter, resulting in a violation of aforementioned
 parity. In practice, this means that the hooked block will not show up in
 the editor, but will be present in the frontend. Editing the affected
 template can then also be somewhat confusing. Here's a small screencast to
 illustrate: https://github.com/WordPress/wordpress-
 develop/pull/5712#issuecomment-1838758546

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60506>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list