Supporting Metaboxes

[jasmussen]

Gutenberg is written in JS, as are the metaboxes in the Settings sidebar.

There are many plugins that add metaboxes in PHP. To allow these to work in the new editor, we should consider adding a space for these to live. One example is an "Extended Settings" panel. Mockup:

Edit: This ticket has been rephrased to add a little clarity. Metaboxes are here to stay. See also https://github.com/WordPress/gutenberg/issues/952#issuecomment-320644682

[androb]

FWIW when I talked to web developers they all use metaboxes for content so that they have maximum control. I am not sure metaboxes are going to be considered "legacy" for a lot of people but rather part of the future. It might be worth reaching out to the WordPress VIP folk to get their take.

[jasmussen]

I am not sure metaboxes are going to be considered "legacy" for a lot of people but rather part of the future. It might be worth reaching out to the WordPress VIP folk to get their take.

My apologies, that phrasing was bad. Metaboxes are here to stay. That's why the metabox sidebar is getting an upgrade in the form of the new "Post Settings" sidebar.

What I meant to say was that new metaboxes should be written in JS, and will appear in the Post Settings sidebar alongside the stock ones. Metaboxes written in PHP should ideally be upgraded to be JS, but should continue to work in their PHP form also. That's what the "Extended Settings" panel is for, and it sits there at the bottom not because we don't want them to be part of the sidebar, but rather that it's very difficult to mix PHP and JS metaboxes in a sidebar.

[westonruter]

There are some big challenges with submitting PHP-managed metaboxes via JS and Ajax, particularly in how to handle updating the metabox render to reflect the newly-saved state: https://core.trac.wordpress.org/ticket/7756

I wonder if embedding a legacy metabox via an iframe could be a solution here, where the iframe src is something like /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings and only outputs that one metabox into the document.

[braders]

What I meant to say was that new metaboxes should be written in JS, and will appear in the Post Settings sidebar alongside the stock ones.

Does this mean JavaScript metaboxes can only go in the sidebar, and cannot be part of the "extended settings" section? Just of the top of my head I can think of lots of plugins where the sidebar won't really provide enough space & make the sidebar potentially cluttered. Just a few plugins which might have issues with this approach:

• Yoast SEO: provides a large number of fields, which probably won't fit in the sidebar - could maybe have a sidebar metabox which opened a modal for more options, but this feels like working around an unnecessary limitation

• Custom field plugins/ drag & drop page builders - these replace or partially replace the main content area & so need plenty of screen real estate. Full page builders potential warrant them building their own totally custom interface as a separate view, but in some cases a number of extra structured fields are required in addition to the main content area (and I appreciate Guttenburg​ should reduce the need for these types of plugin, but equally it can't cover every use-case)

• WooCommerce - adds metaboxes for order & line item data, whilst removing the main editor (Woo plan to eventually build their own custom interface, but I suspect this is a long way off, and other plugins will be in a similar situation)

(I'm assuming Guttenburg is planned to eventually replace the current post-new/post-edit.php views, rather than simply being an alternative?)

[hedgefield]

Ha thanks @braders - Yoast UX-er checking in here with the same question :)

Our metabox is indeed pretty big and wide right now, as it does a lot of things. We wouldn't mind working those features more into the different metaboxes in the sidebar to offer a tighter integration, but I was wondering if that will be possible? For instance, can we add SEO scores to the Publish box like we do currently? And if not, can we still hook into the extended settings box even if our metabox is coded in JS?

[jasmussen]

We should absolutely look at making the new Post Settings pluggable, so that you can add javascript metaboxes to the sidebar. Perhaps it's time to open a ticket for that. This ticket is mostly for metaboxes written in PHP, that need to work in a transitional way.

[brentjett]

Along the same lines as metaboxes in the extended section, has there been any discussion or mockups done for how a post type that does not support post content editing would be presented? In those cases, the metaboxes in the middle area are relied on for the primary editing experience. Should Gutenberg present a "Title-Only" mode? Or should the post title be handled differently in the absence of the editor.

[jasmussen]

Along the same lines as metaboxes in the extended section, has there been any discussion or mockups done for how a post type that does not support post content editing would be presented? In those cases, the metaboxes in the middle area are relied on for the primary editing experience. Should Gutenberg present a "Title-Only" mode? Or should the post title be handled differently in the absence of the editor.

This would be good to create a separate ticket for! With screenshots of the existing post type, if you have it! ✨

[kevinwhoffman]

I also want to emphasize that many plugins use custom post types that rely on meta boxes without a content editor at all. If the post type is registered without support for editor, there should be a title-only mode that opens up the full canvas for use by meta boxes.

[davisshaver]

+1 to reaching out to WordPress VIP. This is also an issue on the Calypso thread: https://github.com/Automattic/wp-calypso/issues/587

Really important feature for the top of market!

[nylen]

I wonder if embedding a legacy metabox via an iframe could be a solution here, where the iframe src is something like /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings and only outputs that one metabox into the document.

I had this same idea too. It's also a good idea for sandboxing and session management reasons. Then we can identify common use cases of this feature and implement an API to handle them.

[Shelob9]

I wanted to way in as a plugin developer and as someone who uses WordPress mainly as an eCommerce tool. Also beacuse @kevinwhoffman told me to.

I tired Gutenberg today and I literally can't process this as being WordPress without seeing how metaboxes and editor buttons (added via media_buttons hook) being a part of this.

I also am not a huge fan of the current state of the WordPress editor and the metabox-palooza. I just counted and in the download (Easy Digital Download's product post type) single post view I have 14 custom meta boxes added by Yoast, Easy Digital Downloads and my own custom code using CMB2. It's a lot, but I need those. WordPress is pretty pointless without that interface and what it exposes.

I'm concerned that this wasn't considered from the beginning as I've worked on so many sites where the custom fields interface added with ACF, Pods, CMB2 etc was the entire editing experience.

Here are my technical concerns: 1) Buttons added via the media_buttons. In my plugin Caldera Forms (80K+ active installs), we use this action to add a form insert button that brings up a modal to insert the shortcode into the post editor. Maybe we would move to a custom block in Gutenberg. 2) How does the save_post action remain backwards compatible? So many plugins, themes and custom code hooks in at save_action and accesses $_POST super global. That's not good design, but its a technical debt affecting millions of sites. 3) There was a suggestion to render legacy metaboxes in an iFrame. This worries me as accessing an iFrame's content via JavaScript isn't possible.

[westonruter]

@Shelob9 hi!

There was a suggestion to render legacy metaboxes in an iFrame. This worries me as accessing an iFrame's content via JavaScript isn't possible.

Accessing an iframe's content via JavaScript is possible, as long as it is on the same domain, as they would be in this case.

How does the save_post action remain backwards compatible? So many plugins, themes and custom code hooks in at save_action and accesses $_POST super global. That's not good design, but its a technical debt affecting millions of sites.

There's only so much we can do to ease the transition of legacy metaboxes to Gutenberg. There's a fundamental difference in how data is modeled in Gutenberg vs the current post edit screen. That is to say, data is now actually modeled for the first time. With data modeling, we can finally use JavaScript interfaces for manipulating the state of posts and postmeta in ways that are impossible using $_POST and the save_post action, let alone being able to preview changes to postmeta. By routing postmeta changes through the model, this will allow for postmeta to be previewed for the first time. So even though Gutenberg can include legacy metaboxes whenever possible, they will always be inherently limited in how much they can take advantage of the new interface. I think that's as much of a reality as the reality that we have technical debt.

I think it's the intentional and conscious decision of Matt that the technical debt must be cancelled if WordPress is to evolve in the way that it will remain relevant in the future. The more that we can get ACF, Pods, and CMB2 updated to use the data model being introduced by Gutenberg, the easier this transition will be I think. There will no doubt be a lot of challenges and hard work ahead!

[buzztone]

@westonruter thanks that makes the purpose of the Extended Settings area much clearer.

I suspect some of the discussion here is at also partly about available screen real estate.

It looks like Gutenberg JS metaboxes can get access to the toggle-able side bar (which is fine by me) while legacy PHP metaboxes get access to the much wider area available at the bottom of the screen (which is also fine by me).

Unfortunately I expect that this desire for available screen real estate may interfere with the intended discussion on how to effectively handle legacy PHP metaboxes.

[hedgefield]

I agree that instead of supporting all the old ways, plugin makers should reconsider their metaboxes and how they can better integrate with the new layout. At the same time, I also agree that similar possibilities to integrate should also be offered in the new editor (and I trust that they will). I believe #1352 is the main place to discuss that currently. This issue is for discussing the way we'll provide backward compatibility for non-updated PHP metaboxes at launch.

[afercia]

I wonder if embedding a legacy metabox via an iframe could be a solution here

Accessing iframes is not a super exciting experience for screen reader users. Any other options?

[kevinpmiller]

Just wanted to chime in here, the sidebar is simply not big enough for most meta boxes that we see in plugins and themes. Forcing us to cram things into this small space is a setback in my opinion. I think this new editor is great, however not if it means sacrificing how we use meta boxes today.

[Shelob9]

I agree with @kevinpmiller strongly. Metaboxes need a lot of real estate and can't be hidden into a sidebar. The current state of metaboxes is disjointed and bad design, but they also reflect what WordPress is -- a highly extensible CMS.

In reply to @westonruter thanks for clarifying about backwards compatibility. I think that needs to be made VERY clear that WordPress 5.0 or where ever this lands isn't backwards compatible since that's been the user expectation.

[ScottDeLuzio]

I'm also concerned about how metaboxes will be handled, especially in certain Custom Post Types where the content editor may not be the primary focus of the CPT. I'm going to pick on WooCommerce here because it's a well-known plugin, but there are a lot of other plugins and themes that have similar issues.

For example, WooCommerce orders have no content editor - it simply isn't needed. Details about the order are what is important, not content editing, and rightfully should be the primary focus of that page.

Will CPTs like this have the ability to remove the editor if it isn't needed? The plugin doesn't seem to be fully integrated with custom metaboxes in CPTs so it's hard to tell if this has been considered or not.

WooCommerce products also bring up another issue where there are two content areas - one for the product's description and another for the product's short description. Will one need to take precedence over the other in the "main" editor area, while the other gets stuck in the sidebar? It seems like a less than optimal editing experience for the one that is in the sidebar.

Can there be an option to intentionally register these settings in the area below (or above?) the editor as opposed to cramming them all in the sidebar? This could be similar to the current add_meta_box context and priority parameters. Perhaps, even toggle between several content editors (or other metaboxes) that belong in the wider section of the page.

Maybe I'm missing something here (please correct me if I'm wrong), but it seems like a huge push is being made for a better editor when in reality, not all uses of WordPress require anything different than what's in use today.

[steveangstrom]

QUESTION how do we define a CPT to not use Gutenberg (equivalent of no editor), and ONLY show the full width metaboxes our businesses rely on. I rely on metaboxes. Most often my CPTs looklike this 'supports' => array( 'title' ) And are extended from there. Please consider those of us who have built business tools for clients using CPTs with metaboxes as constrained and guided form data entry, rather than for article writing. My work is mostly custom extensions to CMB2 which interface with client systems. EG real estate listings which call on 3rd party systems.

I don't want to sound dramatic, but I will be sticking on WP4.9 untill this is resolved and I am very concerned about the future. I understand that Gutenberg is "cancelling the debt to the past"! But the debt falls on people like me.

[braders]

The theme here seems to be that the issue is not with Guttenburg, but rather with the lack of backwards compatibility.

There are some actual Guttenburg issues, for which seperate tickets should possibly be raised (allow metaboxes to use full width, mock-up Guttenburg with no editor support), but Gutturnberg can't totally replicate the current screens and nor should it try IMHO.

However, I do wonder if more should be done to make Guttenburg opt-in/ opt-out. A few ideas:

• I would guess most current CPTs make heavy use of metaboxes over the main editor. So maybe plugin authors should opt into Gutturnberg with 'supports' => array( 'gutenburg' ) or similar

• For posts and pages, Guttenburg should maybe be optional as a site setting. It would even be possible to ask users if they wish to use Guttenburg after the 5.0 update and store this choice in the DB.

• Or alternatively, themes could declare support via post_type_supports(), but this could seriously harm uptake - or themes could opt-out that would not help users of legacy, unmaintained themes which are no longer updated. (Maybe a remove-guttenburn plugin would be sufficient for users of legacy themes though?)

But, regardless of implementation, I do think that the current view should remain, even if it is increasingly hidden from the majority of users...

[steveangstrom]

I like the theoretical idea of CPTs explicitly requesting 'supports' => array( 'gutenberg' ) to maintain existing functionality in the case that the 'gutenberg' support flag is not defined. It would save me a lot of work fixing old sites for angry clients who updated to WP5.

I note that the existing 'supports' => features (title, editor, author, ...) have very self-descriptive names, Gutenberg stands out as a project name here. I wonder if a more descriptive feature name would be considered for that use; perhaps "block-editor"? 'supports' => array( 'block-editor' )

Of course there would need to be a strategy to catch mistakes such as 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . I'd assume the 'block-editor' flag would simply over-ride the older 'editor' mode.

[davekiss]

Another plugin dev here with concerns.

If sidebar meta is only accessible via JS, what does this mean for PHP-registered metaboxes with a context of side? Moving those to the proposed Extended Settings section revokes the idea that those metaboxes are contextual.

As we're all aware, sidebars aren't only a good-looking design decision; they frequently hold relational content in a way that helps the user understand the priority of its contents and the relationship to the main content. Assigning a side metabox a different context due to a technical barrier seems a bit misguided.

Considering the progressive JS-ification of the admin area, these "legacy" metaboxes also provide plugin and theme developers a natural mounting point for self-contained React/Vue/other apps to provide additional functionality to the edit page.

The editor looks great, but please don't forget about the rest of the page.

[kevinpmiller]

I have had a chance to think about this a little more and with some context shared by others here I think there is yet another issue. This new editor is forcing us into a single layout and workflow; why are we removing customization? The ability to sculpt data entry on a per client basis is what makes WordPress and most other solutions really great. The more I play with this editor the more it feels like a bloated version of the Customizer where the preview area has been replaced with an editor and the sidebar just switched sides.

It's also been mentioned that we could use this for writing posts, but allow CPTs to add support for this. I don't think that will really work either. News organizations would love this type of editor but also have a requirement for custom workflows around additional content, scheduling, embeds, infographics, and other data needed.

What about making this editor behave like the full-screen/distraction-free editor? This way we could have the best of both worlds without sacrificing functionality and "legacy" code. (BTW - I think it's ridiculous that the way we currently build meta boxes is now being referred to as "legacy ..." in this project).

Thanks for your time guys, it's appreciated.

[sbruner]

What about making this editor behave like the full-screen/distraction-free editor?

+1

[steveangstrom]

I'm going to reiterate my primary concern: CPTs often don't require the 'editor' because the post is built from large and dynamically grouped metaboxes in a guided user workflow (for example WooCommerce Product data).

Such metaboxes are not going to fit in the proposed "extended settings" drawer because they form primary content entry elements and need to be prominent in the post editor, full width and open. With that in mind, #952 seems too small a concession as it relegates important data entry into a closed drawer.

If we developers are expected to refactor all our old metabox solutions into blocks then somebody from Automaticc needs to state that clearly and publically before the hammer falls in 5.0. I don't see any sign that the team has considered this part of the market and the implications for business.

[JasonTheAdams]

A lot of good thoughts have already been added here, so I'll just throw in these simple thoughts:

Instead of having an "Extended Settings" expander on the bottom for all the legacy stuff, why not just make an expander for each metabox that rests on the bottom exactly like that, when the metabox is in the normal and advanced contexts, and then use the side settings for the side context?

It doesn't seem like we're that far off from a solution. And if the post type doesn't support the editor, then just hide the editor but have everything else show up the same way. It's a reasonable layout. Just give options such as setting the default expanded metabox.

I certainly don't mind the idea of considering the current method of rendering metaboxes legacy and providing a new, js-driven and preferred method of building the fields out. We can then switch over gradually without having to panic about things breaking immediately in 5.0.

Hope these thoughts help. If someone else has already said something to this effect, just take this as agreement. 😄

[kai-jacobsen]

I'd like to add two other valueable hooks to the discussion: edit_form_after_title and edit_form_after_editor which currently provide complete control over the post-edit UI. Obviously Gutenberg is not just a replacement for "wp_editor", it's a complete different take on the UI (and as it currently looks, its future modular expandability).

I see that issues like this are trying to adress the problem but I feel it's not about "what happens to our metaboxes", it's more about the question where WordPress is heading as a "product".

It's easy to spot the mid-term goal of establishing such a solution: it will be quite easy to move this to the frontend (and maybe get closer to some competitors).

From a developers/business/planning perspective it'd would be helpful to understand the (future) intention of 'Gutenberg', or can someone point me to such a mission statement or something similar?

[braders]

Some more opinions from me...

I note that the existing 'supports' => features (title, editor, author, ...) have very self-descriptive names, Gutenberg stands out as a project name here. I wonder if a more descriptive feature name would be considered for that use; perhaps "block-editor"? 'supports' => array( 'block-editor' )

I agree - this sounds like a detail that can be sorted once the approach is agreed though 😄

Of course there would need to be a strategy to catch mistakes such as 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) . I'd assume the 'block-editor' flag would simply over-ride the older 'editor' mode.

I would see Gutenberg as extending the current post type supports - so if there was no editor support then Gutenburg would just show title/ sidebar/ extended options​. So maybe Gutenburg support would be better handled as a seperate CPT registration argument, rather than being part of the supports array?

Instead of having an "Extended Settings" expander on the bottom for all the legacy stuff, why not just make an expander for each metabox that rests on the bottom exactly like that, when the metabox is in the normal and advanced contexts, and then use the side settings for the side context?

I personally like this idea - If these panels could be reordered, and hidden as is possible at the moment, that could be an idea solution...

Possibly, there should also be a way to set one (or more?) or these as open on page load - especially if the post type does not support the main editor.

It's also been mentioned that we could use this for writing posts, but allow CPTs to add support for this. I don't think that will really work either. News organizations would love this type of editor but also have a requirement for custom workflows around additional content, scheduling, embeds, infographics, and other data needed.

If the new react-based screen is as plugable as the old edit screens then there is no reason why these custom workflows cannot be added to the top of the page/ sidebar/ below the editor or elsewhere on the page. (Disclaimer: I don't have a deep understanding of React, so it remains to be seen how much more complex hooks will be outside of PHP). Also #1352

[westonruter]

I think the confusion here is due to there being a fundamental difference in how Gutenberg is re-imagining the editor to be block first. In other words, we should move away from thinking about adding metaboxes and instead think about adding blocks. Fields that you would formerly be putting into metaboxes you will now moving forward instead be putting into blocks.

When you define a custom post type, this would likely include the blocks that are required and which blocks are merely allowed. For a custom post type that does not have editor support would still have the “editor” displayed in Gutenberg, but it could essentially disable the inserter. The blocks that appear in the editor would be locked in place according to what the post type requires. If the blocks had not been populated then they would appear as placeholders. Note that these blocks can then store their properties in postmeta just like metaboxes do currently, but they would be doing so in a normalized way instead of ad hoc via the save_post action and $_POST global.

So I think the end result here will be largely the same. Plugin authors will continue to get a “box” to put custom fields into. It's just they will appear in blocks instead of metaboxes.

[davisshaver]

I think the confusion here is due to there being a fundamental difference in how Gutenberg is re-imagining the editor to be block first. In other words, we should move away from thinking about adding metaboxes and instead think about adding blocks. Fields that you would formerly be putting into metaboxes you will now moving forward instead be putting into blocks.

@westonruter This seems sensible enough for content-containing metaboxes, but many metaboxes service specific post meta that would not make sense in post content.

[cbergen]

Thanks @westonruter for clarification but this raises a couple of new questions for me.

Blocks which store their data as post_meta seem like a fundamentally different type of block than what I've seen so far in the demo. Would this data also be stored redundantly in the flow of the post content?

Is there anything stopping an author from adding more than an acceptable number of blocks to a post? (Adding multiple post_meta fields when only one makes sense)

[brentjett]

I would tend to agree with @westonruter about exploring blocks as a gateway to metadata. What I would suggest, though, is decoupling the idea of a block from the post_content. A block on a custom post type should not necessarily be a member of what comes out of post_content on the front end. Here's an example using The Events Calendar (my interpretation) plugin by modern tribe.

In this situation, the primary content are the event details, not the freeform content area. The plugin will use the metadata from it's custom post type to assemble it's own markup and the post_content is merely the descriptive text that prints at the bottom of the page. Because of this, the event details block should not be movable, deletable, or really be part of the content output at all. It should, however, appear first, because it represents the primary content for this post type.

WooCommerce would be another example where one or more product information blocks should take precedence over the descriptive text on a Product post type, but they shouldn't be optional blocks that the user is expected to insert themselves.

I think the fundamental concept for blocks should be to assemble the proper user interface for the post and not necessarily imply where that data will be stored or rendered on the frontend.

[kevinwhoffman]

...we should move away from thinking about adding metaboxes and instead think about adding blocks.

That makes sense for content, but many plugins use custom post types for non-content such as forms or payments. These post types don't in any way resemble a blog post, nor would their abstract meta fields benefit from a block editor. Forcing all configuration to be done by blocks removes the open canvas that plugin developers have come to rely on, the same open canvas which has made the plugin ecosystem what it is today.

The current approach seems to be block-first with meta boxes confined to a supporting role. While blocks will benefit many content-focused plugins, the need to define abstract settings will still benefit from the obvious labels and familiar inputs that meta boxes provide. In those cases, developers should have the freedom to use the entire canvas.

[Shelob9]

@westonruter Can you please clarify that what your saying is that if my custom post type required certain extra fields, I would have that data entered in a block?

If so, I have a few follow up questions:

1) Would I be able to make that block a default? IE it always showed on that post type and couldn't be removed. For example, if my plugin created events and each event had a start and end date, would the block for start and end date be required and in the post content when editing the event custom post type by default?

2) How would data get saved from that block? As I understand it, right now the data from blocks is stored as an HTML comments in post_content. How would we get the data from these blocks to post meta? For example, for my hypothetical event plugin, how would I get start and end date into post meta so I could query by them?

3) What is the rationale for this everything goes in main content editor direction and having it apply to custom post types? Is there any user testing that backs up this design direction, especially regarding custom post types that don't represent a blog post/ article?

[westonruter]

@kevinwhoffman I still don't see a fundamental conflict for blocks. 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.

[westonruter]

@Shelob9 yes, if your custom post type required extra fields then I think they would be presented in a block. If you have a “product” custom post type then there could be a singular product-details block that has fields for the price, variations, and so on.

1. Would I be able to make that block a default? IE it always showed on that post type and couldn't be removed. For example, if my plugin created events and each event had a start and end date, would the block for start and end date be required and in the post content when editing the event custom post type by default?

Yes, exactly. 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: https://github.com/WordPress/gutenberg/issues/1288#issuecomment-310544967

2. How would data get saved from that block? As I understand it, right now the data from blocks is stored as an HTML comments in post_content. How would we get the data from these blocks to post meta? For example, for my hypothetical event plugin, how would I get start and end date into post meta so I could query by them?

Most blocks today store their data in HTML inside the post_content but they do not have to. For example, in https://github.com/WordPress/gutenberg/issues/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.

3. What is the rationale for this everything goes in main content editor direction and having it apply to custom post types? Is there any user testing that backs up this design direction, especially regarding custom post types that don't represent a blog post/ article?

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. That's my understanding.

[Shelob9]

@westonruter - Thank you for the clarification. This is very useful as there is not a lot of information as to how this editor relates to post types that are not blog posts/ articles, etc.

I hope we'll see documentation on how to write a "metablock" soon.

[kevinwhoffman]

We should consider what we are teaching the user through the Post editing experience and how that maps to custom post types.

When editing a default Post in the block editor, the user learns that each block represents content. Settings associated with the content are available in a panel/meta box that lives outside the block editor. Content lives in blocks. Settings live in panels. It's been said elsewhere that what the user sees in the block editor should be a preview of the page when published.

To then combine settings and content in the block editor for custom post types breaks the idea that the block editor is a preview. I think we ought to let the block editor do what it does best, which is to edit content, and empower developers to build settings interfaces that do not share the same requirements as a content block.

[ahmadawais]

I have had been working on an extensive plugin that adds meta boxes like WooCommerce and EDD do. Most of the times, I have removed the content editor from the screen since it's not needed. I am a bit concerned that it should not be something we should merge with Gutenberg. Otherwise, where would all of this go.

[brentjett]

I agree with @kevinwhoffman that if blocks are going to represent meta then they need a visual cue to the user that these are somehow different from post content and shouldn't be expected in the output. One way to address that is a divider. This is essentially just a reinterpretation of the way content is separated from metaboxes now.

This doesn't solve every issue for me, but i think it's an interesting way to give metaboxes a facelift and could probably be fairly backward compatible with existing plugins, but that wouldn't be a first-class experience for the user.

Here's one attempt to inform the user when a meta block is the primary content, the post content is used as description, and there are additional meta blocks.

[kevinwhoffman]

@brentjett Thanks for the mockups. As you point out the need to separate settings from content is important, but I don't see the benefit of requiring a settings box like Yoast to be a block in the first place.

• It does not represent content on the page, thus breaking the idea that the block editor is a preview of on-page content.
• It does not require multiple instances.
• It does not benefit from being repositioned in the middle of other content blocks.
• It should be present on the page by default.

Each of these traits runs counter to the default behavior of a block. Sure there are various discussions to make one-time use blocks that can be locked in position and present by default. But why twist a block into a meta box when we could instead focus on improving the meta box implementation that already serves this purpose?

[jasmussen]

I don't see the benefit of requiring a settings box like Yoast to be a block in the first place.

Let's step back here for a minute. Two things. One is support for old metaboxes written in PHP, for which we have the "extended settings" drawer mocked up in this post.

The other thing is answering the question: if we wanted to redesign this from the ground up, what would it look like today?

This is where we are proposing blocks, as a new interface that can unify many disparate ones. We are already suggesting that blocks can be superior to shortcodes, custom HTML, widgets, and an affordance for embeds. Depending on what the metabox does, there's no reason it couldn't subsume this interface also.

[hedgefield]

Agreed. And speaking for Yoast for a second, we plan to integrate into many places around the new editor, enhancing the experience that gutenberg is aiming for instead of building one big block to emulate our old metabox, but there have been other examples mentioned above that would work as a block too I think. Yeah it takes some work, but if it turns out that this editor will excite wordpress users once it gains a bit more traction, that's an exciting opportunity to rethink how we integrate with it, and I think our products will become better as a result.

[steveangstrom]

So, we have two legacy functional cases: MetaBoxes which handled meta-data (like Yoast), and we have MetaBoxes which were used to provide a structured interface to enter content (like WooCommerce).

Developing for the future If we started from a blank slate ("cancelling our debt to the past") then its true that putting meta-data in the proposed "advanced" drawer may well work. Also - the structured content-entry might fit into a locked block-order interface within Gutenberg. Both of these are entirely hypothetical, but potentially they would work as implementations for future WP CMS developments.

legacy business CMS issues 99% of my work is in providing bespoke business solutions directly to my client companies. So my concern is not the great things I might build in future but the cold hard facts of my client site functionality, and business relationships. What proposals are there to migrate existing CMS solution based businesses to Gutenberg? In my situation, each client has a different bespoke CMS solution built on the established WP framework. For me the phrase "cancelling the debt to the past" = "Throwing the baby out with the bathwater".

Concerns If Gutenberg is shipped as core in WP5.0 I anticipate my clients will have non-functional sites. Then each site will need to be re-made and each client mollified. Around 40 clients may want me to repair their CMS in that week.

• legacy CMS meta-box reliant sites and their userbase appear non-essential to the Core team
• the "advanced" draw proposal #952 has been deprioritised, indicating lack of interest in the whole area.
• there is no proposed method for resolving the "debt to the past" / CMS issue

[kevinwhoffman]

This is where we are proposing blocks, as a new interface that can unify many disparate ones. We are already suggesting that blocks can be superior to shortcodes, custom HTML, widgets, and an affordance for embeds.

Blocks make sense for all of those things - shortcodes, custom HTML, widgets, embeds. They are all forms of content that appear on the page. I agree, blockify them all.

Settings are none of those things. Settings have distinct requirements that do not overlap with the fundamental behavior of a block. In many cases these settings boxes store post meta which has no bearing on the front-end presentation of a post. To parse non-content alongside content every time a post is displayed seems unnecessary.

Another thing to consider is what happens when the user switches to Text mode. Will they see a bunch of HTML comments representing settings boxes alongside their post content? Will the user delete these unfamiliar things?

All of this could be simplified by treating blocks as content and settings as a separate UI component. Even if we didn't have to consider legacy meta boxes (which is a huge issue @steveangstrom pointed out), the user experience would still benefit from a clear separation of content and settings.

[Shelob9]

@steveangstrom Concerns section is a great summation of concerns that are still not answered yet.

This is a great discussion of what will be possible in the future and that all sounds great, WordPress as it is really needs this. For me, as a plugin developer, not a big deal, I'll make a block or two and be good. But what happens to Steve's clients and the millions of websites out there that were sold to clients with an expectation of backwards-compatibility?

[mihkeleidast]

I understand these concerns as I also have many clients whose websites will probably break with the update. Some thoughts from me:

We extensively use ACF for content management. For example, we might have multiple tinymce editors per post, or in a repeater. if the goal is to replace tinymce, how would we go about using multiple "block containers"? I understand correctly right now there is only one "block container", right?

Another ACF feature that does not fit the post editing flow is options pages. I really don't see how this would work on an options page.

For those wanting backwards compatibility - someone will probably make a plugin to restore the current editing experience, if there is no time/resources to update to gutenberg (this is something I plan on using). Also, 5.0 would be a major version bump, which means that breaking changes are OK (at least according to semver standards).

[nylen]

WordPress does not follow semver.

[tnorthcutt]

@westonruter I think this makes sense:

Fields that you would formerly be putting into metaboxes you will now moving forward instead be putting into blocks.

But, how do we get from there (metaboxes) to here (blocks)? Both in terms of backcompat for code (plugins which haven't been updated yet for Gutenberg) and backcompat for data (how do we display existing metabox data in a new content block, once a plugin is updated for it; is that a plugin-scope problem?).