Make WordPress Core

Opened 3 weeks ago

Last modified 2 days ago

#63608 new defect (bug)

Hooked blocks not inserted

Reported by: leewillis77's profile leewillis77 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 6.8
Component: Editor Keywords:
Focuses: Cc:

Description

Hooked blocks (whether registered via block.json or the hooked_block_types filter) are registered correctly, but are not inserted.

To reproduce:

  • Create a new block plugin using npx @wordpress/create-block copyright-date-block --template @wordpress/create-block-tutorial-template
  • Edit the block.json (copyright-date-block/src/block.json) and add the following:

"blockHooks": {"core/post-author": "after"},

  • Build the plugin using npm run build
  • Log into WordPress and activate the Copyright Date Block plugin
  • Create a new post or page, insert the "Author" block into the content and save the post

At this point, the copyright date block should have been automatically added after the author block, however that doesn't happen.

The post content in the database will look something like this:

<!-- wp:post-author {"metadata":{"ignoredHookedBlocks":["create-block/copyright-date-block"]}} /-->

ie, the ignoredHookedBlocks metadata has been added, but the actual block has not.

Change History (6)

#1 @karthikeya01
8 days ago

Hi @leewillis77

Thanks for raising the ticket. After reviewing and testing the information provided in this article https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/, I found that Block Hooks don't work within post content. Instead, they only function in templates, template parts, and patterns defined by the theme.

Please refer to this:
https://make.wordpress.org/core/2023/10/15/introducing-block-hooks-for-dynamic-blocks/#:~:text=Block%20hooks%20are%20limited%20to%20templates%2C%20template%20parts%2C%20and%20patterns%20(i.e.%2C%20the%20elements%20that%20define%20the%20layout%20of%20the%20theme)

#3 @karthikeya01
8 days ago

Thanks, I have missed it.

#4 @Bernhard Reiter
2 days ago

This is expected behavior. The crucial part is that the anchor block is inserted after the plugin that contains the hooked block is activated. If that order is reversed (i.e. a post containing the anchor block is created before the plugin is activated), the hooked block should be inserted correctly. @leewillis77 Would you mind testing that order? (You'll need to temporarily disable the plugin when inserting the anchor block into a post.)

This behavior was originally due to technical reasons, but we eventually decided that it made enough sense from a UX perspective for us not to change it (which would've been fairly complicated). The underlying idea is that Block Hooks were always meant as a way to auto-insert blocks upon plugin activation into existing layout and content, but not necessarily if a user adds a new anchor block "after the fact" (at which point they can arguably also add the otherwise hooked block while they're in the editor).

@leewillis77 Is that an acceptable limitation for your use case, or does it make Block Hooks unviable for you?

#5 @leewillis77
2 days ago

This is expected behavior. The crucial part is that the anchor block is inserted after the plugin that contains the hooked block is activated.

Thanks for clarifying. I've tested and confirm that in the case you described, the hooked blocks do appear.

The underlying idea is that Block Hooks were always meant as a way to auto-insert blocks upon plugin activation into existing layout and content, but not necessarily if a user adds a new anchor block "after the fact" (at which point they can arguably also add the otherwise hooked block while they're in the editor). @leewillis77 Is that an acceptable limitation for your use case, or does it make Block Hooks unviable for you?

It makes it unviable for us I'm afraid (and creates a confusing experience for the user IMHO).

What we're trying to replicate with hooked blocks is simply to replicate the same effect as you'd get by using add_action() to attach a callback to a do_action() in a theme template file - e.g. the hooked output is added automatically *wherever* that template is used. It seems there's still no mechanism to do that with blocks.

If you'd like more context, feel free to check out this related discussion: https://github.com/woocommerce/woocommerce/discussions/44776#discussioncomment-11302618

#6 @leewillis77
2 days ago

Of course, since this appears to be working as intended (if not as-needed), I'm happy for this to be closed/convert to a feature request, or whatever the applicable trac etiquette is for such things?

Note: See TracTickets for help on using tickets.