Present Blocks outside of post_content

[brentjett]

There's been a lot of talk about how to best handle metaboxes going forward, and while this doesn't directly address that, I think it's worth considering expanding the Block metaphor to content that isn't necessarily post_content. There are many plugins and themes that declare custom post types where a freeform stack of blocks may not be appropriate, or might be used but as secondary descriptive content. The main content consists of multiple meta fields that the plugin will use to assemble it's template. In those situations, I would propose allowing for blocks to present that content and allow focusing into them to trigger their respective settings in the sidebar. Because these blocks are not optional to the post type, and should not be rearranged, they would not be deletable or movable. Because they aren't intended to be output in the content, they would have an alternate means of storage. Here's an example using Easy Digital Downloads.

In this custom post type, the details about the Download make up the primary content. The post can't function without them so the block appears first. Because the plugin also supports descriptive text, the freeform block stack could still appear below it, but the initial download details block should NOT be a member of the post_content when it gets output. Rather, it should be a way to access post metadata. In this way, a content block is essentially acting to inform the user of the primary purpose of the post and give access to multiple metaboxes worth of settings fields. For reference, here's what a standard EDD post looks like today:

Another example where a content block would be appropriate but not as part of the content output is The Events Calendar by Modern Tribe. In this situation the event details are the primary content of the post. The user should not be required to insert this necessary block to begin editing, and the plugin author shouldn't have to jump through any hoops to get to this data or delete the block from being output by the_content(). Its acting as a mechanism to inform the user and provide access to the available settings.

I think we should consider a block to be an element that establishes the user experience apart from where or how it's backing data gets stored.

Like I said, this kind of block doesn't eliminate the need for "meta" UI. This is for content-focused post types. This probably wouldn't be appropriate for post types that have utilitarian UIs like form builders.

[westonruter]

@brentjett I think this is what we've been talking about just now in #952 (comment):

Abstract settings can still be considered content, but of a different kind: it's all data. Every block needn't have a visual representation in “the content”. I think there could very much be “metablocks” as well, storing data in postmeta instead of post_content. Blocks being edited can by styled to have headings/labels similar to how metaboxes are presented today.

Custom post types, post formats, and page templates could all simply involve the concept of required blocks that are “locked”, unable to be removed or reordered. One example of this would be a block for the post excerpt: #1288 (comment)

Most blocks today store their data in HTML inside the post_content but they do not have to. For example, in #1288 you can see discussion of an Excerpt block storing its content in post_excerpt and a Featured Image block storing its content in postmeta. So you definitely should be able to have an event-details block that has a start and end date that get stored in postmeta.

Per above, the data can be sourced from and saved out into post_content, postmeta, terms, or any other place. The idea of being “block first” is to have a common building block that everything uses and in doing so the block components can be maximally re-used across WordPress.

It would be helpful to have some design guidelines for how such “metablocks” are styled.

[StaggerLeee]

I wonder what would it look a like for WooCommerce.
"shop_order" post type does not have content element, or editor. Nowhere to click on to trigger right sidebar options.

[brentjett]

I've been trying to flesh this idea out further just to see where it leads. Below is a fictitious example of a custom post type for a movie review. In this situation the developer has created a custom "Movie Details" block that is required for this post type, but could very well be an available block on a standard post.

There seems to be a need for "Sections" to help inform the user what's happening. In this scenario the only blocks that should be considered post_content are in the "Review Content" section. Below it there could be a settings section (or other sections added by plugins) to hold additional "meta" blocks. Here's the structure as I'm imaging it, from the point of view of registering a new post type.

It may be helpful to imagine that certain situations might require multiple freeform/open block sections, but only one of those would correspond to the post_content. Another might be stored as meta, or persisted in a custom datastore.

Here's an example with the Settings section supporting a variable number of blocks. I'm wondering if we could use the same UI pattern as the block picker for the content blocks to accomplish what the Screen Options tab (top right, standard edit screens) does now. Here the picker is showing available "meta" blocks.

If I have time I'll try to do a WooCommerce example. There's a lot going on there, so it's a bit time consuming.

[youknowriad]

related #2065

[benhuson]

For me this is the main requirement for fully being able to transition away from meta boxes to blocks.

I'm currently experimenting with how to port over some plugin meta box functionality to Gutenberg blocks.

I have been able to create a block that saves as post meta so it can continue to use the existing data structure. I have also defined a block template so that the block is shown by default.

The meta fields block is required for all posts in the post type and should be locked so it cannot be deleted. It should also be shown in a consistent non-moveable place when editing.

Currently if I set template_lock to "all" it locks all blocks for the post type. If I set template_lock to "insert" it allows moving but not deleting. Both these prevent the user from being able to add additional post content blocks.

What is required is to be able to lock just a specific block to prevent it being moved/deleted while continuing to be able to add/insert/move other blocks in the editor?

This could work using a separate section as outlined above by @brentjett , or perhaps be defined by a block template that allows the meta block to be position where desired in the template, above or below the main content blocks area, and just lock that block.

It feels list some implementation of blockList outlined in #3588 may be a way of implementing this somehow?

Possibly also related: #1754, #1684, #3686

[youknowriad]

What is required is to be able to lock just a specific block to prevent it being moved/deleted while continuing to be able to add/insert/move other blocks in the editor?

This will be possible using nested blocks, where you add can add a "container" block allowing the user to add/remove/insert any block inside this container block while the others remain locked.

[benhuson]

... will be possible ...

Thanks @youknowriad. I had read a bit about nested blocks but couldn't find an examples at present.
Is this possible now, or just on the 'things to do' list - guessing #3745?

The only example of block locking I found was at a template level where you can specify $post_type->template and $post_type->template_lock`. Template locking here seems to be at a full template level rather than a block/block list level?

[youknowriad]

@benhuson Yes but if you think about it, it's enough for all use-cases. While the container block can't be moved/removed, you can still insert/remove blocks inside it. You could imagine having a "lock" attribute in the container block allowing you to "sub lock" parts of the editor.

This is just ideas for now, once #3745 lands we'll experiment with this more.

[danielbachhuber]

@brentjett @benhuson Any remaining actionable items out of this issue or can it be closed?