Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
cbirdsong opened this issue Jan 6, 2022 · 10 comments
Closed

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

cbirdsong opened this issue Jan 6, 2022 · 10 comments
Labels
Developer Experience Ideas about improving block and theme developer experience [Feature] Block API API that allows to express the block paradigm. [Type] Discussion For issues that are high-level and not yet ready to implement. [Type] Enhancement A suggestion for improvement.

Comments

@cbirdsong
Copy link

cbirdsong commented Jan 6, 2022


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:

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.

@annezazu annezazu added [Type] Discussion For issues that are high-level and not yet ready to implement. [Type] Enhancement A suggestion for improvement. Developer Experience Ideas about improving block and theme developer experience labels Jan 6, 2022
@gziolo
Copy link
Member

gziolo commented Apr 7, 2022

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
Copy link
Author

cbirdsong commented Apr 7, 2022

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.

@ararTP ararTP mentioned this issue Jan 30, 2023
@talldan
Copy link
Contributor

talldan commented Jan 30, 2023

I closed a duplicate issue - #47528.

That proposed an alternative solution of a text block.

@gziolo gziolo added the [Feature] Block API API that allows to express the block paradigm. label Jan 30, 2023
@gziolo gziolo mentioned this issue Jan 30, 2023
67 tasks
@gziolo
Copy link
Member

gziolo commented Mar 3, 2023

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
Copy link
Contributor

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:

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

@gziolo
Copy link
Member

gziolo commented Aug 30, 2023

@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
Copy link
Contributor

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
Copy link

Related
#53891

@cr0ybot
Copy link
Contributor

cr0ybot commented Sep 13, 2023

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
Copy link
Member

gziolo commented Mar 13, 2024

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:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Developer Experience Ideas about improving block and theme developer experience [Feature] Block API API that allows to express the block paradigm. [Type] Discussion For issues that are high-level and not yet ready to implement. [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

8 participants