Metaboxes: Try showing the metaboxes under the editor's content

[youknowriad]

This tries something close to this design #952 (comment)

The metaboxes are shown under the content and not hidden under a panel

closes #3141

[mtias]

This seems like a good iteration to me—the current expandable box just feels a bit clunky.

[karmatosed]

I have a concern on how this looks visually with the flow and also on mobile:

A question, do we need to say 'Extended Settings'? What about no text and just having this:

We could experiment with a fully across line or a partial one.

[youknowriad]

Updated this to usee only a partial border separator

[jasmussen]

I appreciate the work gone into this! I also like the direction, generally. By the way credit goes to @brentjett for this concept.

I do think we need to think this through, plot the path forward. In a way, this design asks the question: what is a metabox? Is it content, or is it metadata? — I know that it's often being used as content, despite the "meta" in its name. But this design squarely makes it content, which in the case of Yoast makes it a little weird, as that's definitely metadata.

It also has implications for what we do with theoretical modern JS metaboxes in that space. Do we write such an API or do we keep suggesting the block itself as the modern iteration of this interface? If we do the latter and don't allow JS metaboxes there, we'll implicitly be forcing developers to write PHP metaboxes because it's absolutely going to be a popular area to put stuff in.

It also affects our fundamental structure that allows a distraction free environment to take place if you toggle off the sidebar. In the current design that also hides the Extended Settings. In this design it would not hide metaboxes.

The chief benefit of this is that it can plot a path forward for implementations, chiefly from plugins like ACF and others, that rely on metaboxes only for content, perhaps creating custom post types that hide the input field (in this case block editor) entirely, in favor of just a series of metabox input fields. For such setups, this design can make that experience first class in Gutenberg.

All in all, this is a harder problem than I expected it to be. As it stands, I'm rather concerned about the simple writing flow, the one where you can get all your work done without ever seeing any advanced settings.

The obvious solution to this would be to find a design that keeps the metaboxes inline like this, but allows them to be hidden with the sidebar like they do in master currently. But I'm not sure how intuitive this is, and it breaks the flow where metaboxes are content.

Another solution could involve the rebirth of "Screen Options".

Yet another solution could be to find a design that's a hybrid of what's in master currently, and this inline version. What's in master, by the way, was not a 1:1 implementation of the initial design:

My original intention was for extended settings to expand downwards, not to cover any content above. And so expanding that box would make the scrollbar longer — it would technically let the metaboxes sit inline with the content, in a way, but it would still have the gray collapsible header, separating the block editor from metaboxes. This would allow the cog to still toggle off that section, which is my chief concern with this implementation.

Here's a quick and dirty mockup to clarify — here's the full page of content:

Here's what it would roughly look like when scrolled to the bottom, notice that the metaboxes are inside the content area so they don't cover content, just sit after it:

We could look at making this design more light weight, but the key would be that Extended Settings are hidden when the sidebar is hidden.

[youknowriad]

In a way, this design asks the question: what is a metabox? Is it content, or is it metadata?

I think the answer to this question should be given by the plugin author. We should be trying to answer, how does a plugin author communicate that its metabox is content or metadata.

The content area of the editor should be pluggable regardless of the "how" (metaboxes or something else).

In the current metaboxes world, we have the "context" property. Correct me if I'm wrong but most plugin authors using "normal/advanced" are explicitly stating that this metabox is "content" and should be inlined. And they can use "side" for expandable metaboxes on the sidebar.

[BE-Webdesign]

In the current metaboxes world, we have the "context" property. Correct me if I'm wrong but most plugin authors using "normal/advanced" are explicitly stating that this metabox is "content" and should be inlined. And they can use "side" for expandable metaboxes on the sidebar.

Not 100% sure what you mean, but to clarify meta box uses, all meta boxes as long as they use the core style and structure will be expandable/collapsible in the classic editor. The context property just tells where they should go. advanced: after title (eeek). normal: after content. side: in the sidebar. Most uses of normal/advanced are for meta boxes that need more space than the sidebar.

[StaggerLeee]

Tested few days ago Gutenberg auto height on new post load and looks nice. Show metaboxes if Gutenberg does not have any blocks. When blocks are there move metaboxes under, it is normal.

Some other problem I noticed. You get now 2 login popups when session goes out. One normally for backend, and second inside iframe for metaboxes.

[aduth]

I've not been following along in the discussions, but should I expect to see an "Extended settings" label on the meta box separator as in the screenshot of the original comment?

[aduth]

Minor: To avoid the duplication, we could do the reverse and apply the panel as a wrapper:

let element = <MetaBoxesIframe location={ location } />;

if ( usePanel ) {
	element = <MetaBoxesPanel>{ element }</MetaBoxesPanel>;
}

return element;

[youknowriad]

but should I expect to see an "Extended settings" label on the meta box separator as in the screenshot of the original comment?

No, it has been removed per @karmatosed's suggestion above

[codecov]

Codecov Report

Merging #3147 into master will increase coverage by 0.39%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #3147      +/-   ##
==========================================
+ Coverage   31.12%   31.52%   +0.39%     
==========================================
  Files         230      230              
  Lines        6444     6535      +91     
  Branches     1150     1182      +32     
==========================================
+ Hits         2006     2060      +54     
- Misses       3722     3740      +18     
- Partials      716      735      +19

Impacted Files	Coverage Δ
editor/sidebar/post-settings/index.js	0% <ø> (ø)	⬆️
editor/layout/index.js	0% <ø> (ø)	⬆️
editor/meta-boxes/index.js	0% <0%> (ø)	⬆️
editor/writing-flow/index.js	0% <0%> (ø)	⬆️
editor/reducer.js	92.44% <0%> (+2.38%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update b3df37b...4c1b496. Read the comment docs.

[StaggerLeee]

Right of Tammie to remove it.
Metaboxes and fields are not "settings", but "content".

[aduth]

Might consider some sort of loading indicator, or at least hiding the line while loading occurs, since it can be jarring to have the meta boxes load in suddenly.

Also per @karmatosed design, the line here now extends full width, not... ~90%ish as in those mockups.

[karmatosed]

👍 this looks good to me.

[benhuson]

@youknowriad Was just testing with one of my plugins and noticed that I was using advanced position for meta box and nothing showed.

Above, @BE-Webdesign mentioned that advanced goes after title and normal after content.

Currently in the classic editor, advanced meta boxes still appear below the content, but below normal meta boxes (If you want to add content below the title I believe you have to use the edit_form_after_title hook).

So I would expect the advanced meta boxes to show below the normal ones in Gutenberg too, unless they go in a collapsable Extended section?

I know it's work in progress, but just mentioning here :)

[youknowriad]

@benhuson Thanks for the feedback, I'll take a look at this soon.