Data storage for non-content meta blocks, and differences between optional and required

[westonruter]

Outside of the discussions about “metablocks” in #1684 and #952 and #1288 (comment), I wanted to jot down a few thoughts in a separate issue regarding how we handle blocks that are not stored in content. Namely I have in mind a block that is used to manage:

• The post excerpt, where the block's data is stored in the excerpt post field instead of content.
• The featured image, where ht block's data is stored in the featured_media field (the _thumbnail_id postmeta.
• A custom post type which has blocks for managing its unique properties, such as a product's variations.

In the first two instances, the blocks are optional and they needn't be shown in the editor when creating a new post. Blocks for Excerpt and Featured Image could be listed in the Inserter, but they would have useOnce (#1661) to ensure that only one of them are added at a time. As noted, these blocks would store their data in excerpt and featured_media fields, respectively, and not content. As such, the ordering of these blocks would be undefined in relation to the other blocks that do exist in content. As such, meta blocks should perhaps have a separate position property for where they should display in relation to content blocks. This is similar to how metaboxes in WP today have properties for context and priority, though we'd want something much better in how we determine placements for such “locked” blocks.

When loading a post that has an Excerpt and Featured Image defined, the Editor will need to know that the blocks for these need to be added to the editor. When registering a block, there would seem to be a need to define a way for it to inspect the post state to see if it needs to be instantiated. This could perhaps be related to the attributes property which defines how to query the content for its props. The api component could be extended so that the query could add meta in addition to attr and children.

In the case of a custom post type, like product which has a block for managing its product variations, the post type should be able to define this block as required. Even though this metablock does not get stored in content it should know where to locate itself in relation to content blocks, and since it is required it should be automatically added when creating a new post.

[StaggerLeee]

Please do leave Fetaured metabox where it is now. I see you mention "optional", leave it like this.
Moving it to the content area would make huge confusion. All users beginners have no problem to use Featured Image. They get it even without screenshots and tutorials. No matter how you would style this block and put it first after Title it is confusing because there are other Post images in editor content area.

Second problem making confusion for beginners would be different visual results on the front and backend, because themes handle and display featured image very differantly.

Third problem, I am using snippet to set default featured image from Media Library. It would be shown allways in Gutengebrg "content area". After some time pretty boring sight (Metabox image is much smaller and not sticking to eyes so).

All Users beginners I had to teach how to use WP regard featured image as something for Blog/Archive list. And it is for theme to handle that, not Gutenberg.

Excerpt is very different thing, for various reasons, and would be desirable to have it as Gutenberg block.

[davekiss]

Gutenberg seems to cover the use case of managing an individual post's related metadata, but what about managing children or 1:n relationships of that post?

Metaboxes as they exist now allow for a natural spot to show and manage content related to the post currently loaded in the editor. With the addition of the authenticated REST API, it became very easy to create child posts within a context that made sense (think of a Course, where a Metabox allows for creating child Lessons)

I can't help but feel that removing a hookable content area that could have been used for anything since WordPress 2.5 is going to have some pretty significant consequences. It's effectively the same as blindly removing a div, hoping that the user's implementation can technically and logistically be migrated to this new framework.

[JoshuaMcKendall]

@westonruter Would it be easier to just add a featured "status" to the preexisting image block rather than introduce an entirely new block? Where the user can add an image to a post and mark it as the featured image.

To expand on that thought, would it be possible to add that featured status to certain blocks beyond just an image. By that I mean you could set a featured video, or a featured gallery etc. This could be especially useful for different post formats. I know that in #1722 You have plans to make post formats selectable, the user could select a video post format, and a default video block would appear in the editor that they could upload or embed a video within, and would have a featured "status" by default.

I guess I was just curious and am asking if that's what you meant by featured_media? Not in regards to post formats necessarily, but in regards to different featured blocks beyond just featured image.

Select a format:

Default image post format view

Image selected and automatically set as featured (for corresponding post format)

[JoshuaMcKendall]

@StaggerLeee I think adding a featured image block within the content area is a far better user experience than keeping it as a metabox. Your featured image is a part of your post, thus it is content, and content should be with content.

If there is a different user procedure for adding an image to a post vs. setting a featured image for that post that creates an inconsistent experience. It may not be a bad user experience, but it's discombobulated. A good user experience should be consistent.

By adding featured image as a block, nothing has actually changed. At the end of the day you are still choosing an image that you wish to use as your featured image. It's just now its with your content, where it always should have been in the first place.

[StaggerLeee]

I do understand Joshua. But, imagine when developers set default featured image via code, and it stretch wide on desktop screens.

Next problem is many themes remove featured image from post content view. There is no logic in forcing it in Gutenberg content editor area,

I remove featured image from Post view on all websites, on all 100%.
Simple reason is Users/Owners dont have all the time so huge image available. To stretch small image is out of question.

Ot the other side, small images allways work on Blog/Archive template, even if there is need to enlarge it a bit.

[westonruter]

I didn't intend to derail the conversation to talk about Featured Image (featured_media in REST API terminology). Please consider Featured Image to be an example, something that could be managed by a block that is optionally added one time. My discussion topic in this issue is regarding the mechanics of such metablocks.

[buzztone]

I see Blocks for Excerpt and Featured Image as 2 historic items added for good reason using the best options available at the time. I expect going forward with the approach suggested would yield other useful blocks which fit this pattern.

[tharsheblows]

In the case of a custom post type, like product which has a block for managing its product variations, the post type should be able to define this block as required. Even though this metablock does not get stored in content it should know where to locate itself in relation to content blocks, and since it is required it should be automatically added when creating a new post.

What about a filter on _wpGutenbergPost.content before the editor gets created? With some sort of ordering. That way there could be not only be non-content "metabox" blocks but custom post types and plugins could define default templates.

(Here is where the editor gets created -- it'd have to happen after the blocks are loaded, probably right before the editor is created.)

[ChemicalSailor]

Set block as featured within the block; a nice idea. Imagine a featured quote.

Of course would have to only allow one featured block so need to work out UX around that. Perhaps the sidebar previews the featured block, and can toggle a 'featured block picker'

[benhuson]

Feature Images and excerpts is that they are more like meta data that are separate from the main content content - you often don't see either of these items on the actual front-end page.

For example, a featured image may be used as a preview on an archive/category page, but not actual feature on the page itself. Consider a shop where you want specific featured images to appear in the category view, but maybe show a different image, or gallery of images when you click in to view the product.

Similarly with excerpt, this content does not below as part of the main page content. It is used to provide custom text that in general is used on archive pages and may not feature on the actual page.

For me, these elements would cause confusion if they appeared to be part of the main content blocks, but didn't actually display on the page.

[benhuson]

@JoshuaMcKendall Allow a normal Image block to have a toggle to set it as featured don't make sense to me.

Imagine having a product post type where the featured image is shown on th archive/category page. If the product content had many image blocks it would be difficult to tell at a glance which was the featured image in order to change it.

If meta blocks has a set position as per @westonruter 's opening issue that would work as it would make it clear that these elements do not necessarily display in the flow of the page.

[youknowriad]

Going to close this issue as with FSE, we now have several blocks that behave that way (featured image, excerpt...)