Create a system for inserting site/post metadata into generic blocks

[cbirdsong]

• Part of Block API #41236.
• Related to:
  • Block Bindings API iteration for 6.5 #54536.
  • Connecting block attributes and custom fields & Block Bindings API for WP 6.5 #53300.

---

What problem does this address?

A lot of the theme blocks are simply bits of text, like Post Title, Site Title and Site Tagline. Most of these are variations on the heading and paragraph block, but they have lots of individual quirks. For instance, the Site Title and Post Title blocks have a bunch of typography controls that are not available to the Site Tagline or Post Date. Additionally, if I'm creating a theme and I register a style on the heading or paragraph block it can't easily be used for any of these theme blocks unless I register it for all of them.

Lots of similar things are happening with images. The Featured Image block lacks the border radius and resizing options present in the Image Block. Additionally, special-case options to use a post’s featured image are already proposed for every basically other block that accepts an image:

• [Block] Media + Text: Support featured image #35221
• Allow using featured image as background for a group block #24660
• Add option to set as feature image to image / cover block #13795

Soon there will be a Post Author Image block, which will face the same issues. This does not seem like a system that will scale.

What is your proposed solution?

Instead of making tons of individual blocks for this sort of thing, it seems like it would be better to create systems for using site/post metadata within existing generic blocks.

For text, if you could just insert text metadata freely (maybe as an inline element?) then any functionality added to the core paragraph/heading blocks or by theme/plugin authors would automatically be available to use with the site title, post title, excerpt, date and anything else.

For images, it would be much cleaner if you could just select the featured image, author image or whatever else as the source anywhere any block accepts an image. A similar solution has been proposed in #31849, but only for the featured image. Ideally, these systems would scale to accommodate additional sources for data instead of narrowly addressing issues related to the featured image or other core functionality.

[gziolo]

I landed on this proposal thanks to the WP Tavern article by @justintadlock. I wanted to share that @dmsnell is actively exploring how we could formalize the concept of dynamic tokens in blocks. There is a related discussion on that topic: #39831.

Regarding this issue:

A lot of the theme blocks are simply bits of text, like Post Title, Site Title and Site Tagline. Most of these are variations on the heading and paragraph block, but they have lots of individual quirks.

Instead of making tons of individual blocks for this sort of thing, it seems like it would be better to create systems for using site/post metadata within existing generic blocks.

I like your idea. In fact, I was thinking the same when those blocks were introduced, but I didn’t have any alternative to propose at that time. There is this challenge that dynamic content, when marked as editable, has to get updated on the server - if we would like to replace the existing blocks.

The concept of dynamic tokens described by @dmsnell in the discussion I shared can mean different things depending on what use cases people think of. In this case I would like us to explore a way to extend the concept of block variations. To give an example for the Site Title block, it could be a Heading block’s variation exposed in the inserter that has:

• the level attribute set to 1
• the content the attribute would get connected with the site’s title from REST API in some way

Still, the question would be what to do about the optional wrapping link to the homepage.

[cbirdsong]

If “Site Title” was a token that you could insert into a Heading block then adding a link could still be an option there, but that’s still ultimately a special case. A better solution might a way to select metadata like “home URL” as part of adding a link to any bit of text, which could then be applied to the site title or any other bit of text.

[talldan]

I closed a duplicate issue - #47528.

That proposed an alternative solution of a text block.

[gziolo]

The improved Pattern block, as described in #48458, might also need integration with a similar system as covered in this issue. It gets even more interesting when you pair Pattern block with the idea from #44581 of shuffling content blocks when its templateLock attribute is set to contentOnly. It raises the question of how you can automatically annotate dynamic elements in a way that reordering blocks still allows the system to correctly inject data into blocks.

[draganescu]

When I worked on adding featured image option to the cover block I too have explored similar concepts. The idea was to bind block attributes to data that may be available in whatever the instances of the block editor that uses these blocks. I had a long intertwined discussion with @dmsnell too about using tokens for placeholders in text vs using them for attribute binding.

See:

• Bind featured image to cover and image blocks
• Try/use featured image attribute

I still think binding is a good direction for attributes and tokens for on the fly insertion of dynamic data into static text.

[gziolo]

@mtias and @SantosGuillamot, how much the new Custom fields 🔗 Blocks project relates to this issue? It seems the goals for block attributes align. There is also Tracking issue: Connecting block attributes and custom fields.

[SantosGuillamot]

If I understood correctly, I believe the Custom Fields solution should solve this issue. The idea is to connect block attributes and meta fields exactly for that, to show the value of any meta field in core blocks like paragraph/heading/image. This would reduce the need for extra blocks. Not only for core blocks but also for custom blocks consuming meta data. Once the implementation is ready, we should explore the possibility of migrating some of the core blocks:

• Post Title block -> Heading connected to the post_title field.
• Post Featured Image block -> Image connected to the post_featured_image field.
• Post Author block -> Paragraph connected to the post_author field.

[tresorama]

Related
#53891

[cr0ybot]

Related to @SantosGuillamot's suggestion, and maybe this is obvious, but it should be possible to create a block variation for these things so that the "Post Title" block would still be selectable in the list of available blocks.

I do think that the example of the post author block could be tricky though. You may need to handle multiple data sources, including author avatar image and author page link, not just their display name.

[gziolo]

The initial rollout in the WordPress 6.5 release introduces a way to define the bindings with block attributes and supporting API on the server that allows registering sources on the server that inject the dynamic data in HTML output for blocks. As part of that, the source for Post Meta is going to be available out of the box.

Related resources that cover how to connect Post Meta:

• New Feature: The Block Bindings API
• Introducing Block Bindings, part 1: connecting custom fields
• Introducing Block Bindings, part 2: Working with custom binding sources

The same work is planned for Site Metadata, and you can follow the progress in #53300 that will server as a epic issues for WordPress 6.6 release. I'm closing this issue to consolidate the efforts in one place given that most of the required work has been already done in WordPress 6.5 cycle. It should be also possible to register a Site Metadata with the existing API before it's going to be available in WP core.