Post Excerpt: Displays the post type name as preview in the editor

[gigitux]

What problem does this address?

Currently, in the editor, the preview of the Post Excerpt is hard coded and it is:

This is the Post Excerpt block, it will display the excerpt from single posts.

If there are any Custom Post Types with support for excerpts, the Post Excerpt block can display the excerpts of those entries as well.

The preview is clear for advanced users, but it could create some confusion for newcomers.

A better preview could be:

This is the Post Excerpt block, it will display the excerpt from single {post_type}.

For instance, in the image below, I'm editing the Single Template for the post type Movie. The Post Excerpt Block should show:

This is the Post Excerpt block, it will display the excerpt from single movies.

I created a similar issue for the Post Title block #48963

[carolinan]

How about 'This is the Post Excerpt block, it will display the excerpt.'

The block description is still 'Display a post's excerpt.' though.

[gigitux]

Digging into the repo, I found this issue #44322. I did some explorations in the code, but it isn't possible to retrieve the post type in the block.

Even if the block has:

"usesContext": [ "postId", "postType", "queryId" ],

templates don't inject the data into the context.

[carolinan]

Yes, correct, the post type is in a different package. This is not the only time we need a post type in a block, I don't know how to fix it though.

[gigitux]

@carolinan Thanks for the feedback! I opened a PR with another approach! Let me know what you think!

[gigitux]

@carolinan I created a PR to improve the preview #50167

Also, I created a tracking issue to keep track of all core blocks that could have a better preview using the post type of the template #49108

[nerrad]

One difficulty with solving this is how to retain allowance in layouts for use cases where multiple post types might be in the layout. That consideration potentially eliminates some of the more obvious solutions (i.e. just use template or block context).

There is also the issue of discoverability. When users are looking for a block related to a specific post type (such as "movies" or "products"), how will they know that "Post Title", "Post Excerpt" or even "Query Loop" blocks are available for those post types (not to mention the average user might not even know or care that "movie" or "product" are post types)?

I can think of a few ways to handle this (as ideas):

• The generic name of the post-type powered blocks is improved (but not sure what would be better in this case).
• GB automatically generates variations for all the registered post types so they are available via the selector in a more user-friendly way.
• Or, as a variation of the above, we're able to somehow dynamically change the dynamic pieces of these blocks (block title, description, placeholder) based on user intent. For example, searching for a post-type's registered name (i.e. "product", or "movie") would surface the Post Title Block but it would be dynamically updated to display in the search results with the registered post-type labels and then on insert the block details will utilize that post type's labels.

[gigitux]

Hey @nerrad, thanks for your feedback!

GB automatically generates variations for all the registered post types so they are available via the selector in a more user-friendly way.

I implemented this suggestion (0e8f4038068428de8106222f336299765afdf4a0) by taking inspiration from the core/post-terms block (source code).

The downside is that the block will always be visible in the inserter (like the post terms block):
https://github.com/WordPress/gutenberg/assets/4463174/37f2f2f5-ce74-42a6-8518-7019dcf7600e

Also, another downside, I added a new attribute to determine which is the active variation (source code). What do you think?