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.

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.

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.

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?)

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?

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.

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.

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! ✨

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.

+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!

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.

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.

@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!

@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.

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.

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?

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.

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.

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.

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.

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...

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.

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.

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.

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

+1

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.

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. 😄

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?

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

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.

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.

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)

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.

...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.

@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?

@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.

@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

1. 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.

1. 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.

@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.

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.

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.

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.

@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?

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.

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.

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

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.

@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?

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).

WordPress does not follow semver.

@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?).

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?).

These are good questions. We will be exploring the answers as we implement these features.

If I had to guess where we will end up here: current metaboxes will be moved to a "legacy" area and we will provide APIs, documentation, and examples for registering "new-style" metabox-block-thingies.

@nylen what about the _rendering_ of current metaboxes?

It is good news that meta boxes are being prioritized, but we need to consider a solution that goes beyond placing old meta boxes in a drawer or confining them to a "legacy" area.

There are countless sites in existence today that are primarily built with meta boxes through plugins like Advanced Custom Fields. We're talking full-screen interfaces here, not just one or two boxes at the bottom of a post. I'm sure ACF will update to work with Gutenberg, but those sites will not be re-built.

So the question remains, what happens to an interface that has no editor and is comprised entirely of meta boxes?

So the question remains, what happens to an interface that has no editor and is comprised entirely of meta boxes?

The idea here, and correct me if I'm wrong @mtias, is that you just hide the content area with your plugin, and all you see are metaboxes where the content would be.

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

+1. This is a good idea as it doesn’t affect the current editor with meta boxes at all. While the distraction-free editor was there for a long time, it’s not used much. The Gutenberg editor can take this and improve instead of rewriting the editor screen.

Also, it would be better if we register support for the Gutenberg editor with supports parameter when register_post_type.

Finally, as a meta box developer, I’d love to see new API to make meta boxes work for the new editor. As you see here, many developers use meta boxes as a way to provide additional content for the posts. Those content can be categorized, searched later. It’s not just simple blocks of content as post content. So, if there’s a new replacement for add_meta_box() function, I’m happy to refactor my Meta Box plugin to work with that.

Agreed with all that's been said re: making standard metaboxes still work/have a place. As the lead dev of CMB2, I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released. I certainly don't mean this as a threat, but simply as a reality.

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.

I will definitely be looking to do this over the long term, but I'm not sure it's a fair expectation that metabox libraries will have this in place by the time gutenberg is released. (Granted, that may not be the expectation)

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

And even if it's updated, old installations would be broken.

Please also notice that Field Groups in ACF do not need to be in metaboxes, but there is also the style 'Seamless (no metabox)' with the options 'Side', 'normal - after content' and 'high - between title and editor (!!!)'. The last one important for creating a meaningful flow of editing.

Please keep in mind that there are a lot of critical individual developments out there, that will never be updated because nobody will pay for that. Breaking those implementations will be the ultimate killer for WP in enterprise environments.

@wsydney76 Please also notice that Field Groups in ACF do not need to be in metaboxes, but there is also the style 'Seamless (no metabox)' with the options 'Side', 'normal - after content' and 'high - between title and editor (!!!)'. The last one important for creating a meaningful flow of editing.

It's worth noting this isn't something that "just works" in WordPress but requires custom plugin code to remove the usual metabox UI - so it is reasonable to assume this will require additional work from ACF to work with Gutenburg.

Make it simple. When custom post type has no support for editor (Gutenberg) declared, use your imagination, CSS skills, and your most talented core designers to convert whole editor to something else. Make it appear as not something client/User see when in (native) post editing screen. It is just about appearance. Clients do not care if Gutenberg works in background or not, they could not care less even if they are told about it by web developers. They are visual types of people.

Regarding backwards compatibility, I proposed a Long Term Support version of WordPress back in february, long before the announcement of Gutenberg hitting 5.0.

At that point it seemed like an improbable task, but now that it's happening, it's even more important to discuss making 4.9 a LTS version, cutting off pre-4.9 support and focusing on 5.0.

The post can be found here:
https://khromov.se/wordpress-needs-another-long-term-support-version/

10 years+ WordPress developer here. As many pointed out, this development is great for content. It's a really needed standard solution for dynamic content blocks with custom markup. Having said that, this does limit the usage of post types in ways that steer from content and bring WordPress closer to a framework.

As an example: I built a suite of plugins that allow to not only create fields for post types (like many others) but also to create relationships between them (i.e. one to one, one to many and so on). This (together with more features) turns post types into something that's very close to models in frameworks like Laravel or Rails, and I then use a DSL to work with those posts, their data and their relationships.

This type of use is far from uncommon, and WordPress itself encouraged creative uses of post types by allowing developers to declare post types as not public. Flags like 'public', 'publicly_queryable' and 'show_ui' are all meant to allow developers to use post types for purposes other than a simple 1:1 mirror relationship with a public page on the website

How does Gutenberg fit in with that vision?

I don't see a solution other than to keep this editor optional, i.e. it should still replace TinyMCE but the editor should remain optional just like TinyMCE is optional right now.

If we can keep creating post types that do not support the editor and we can keep using metaboxes in those post types, I believe a consensus could be reached a lot faster.

Adoption of the new editor from themes & plugins developers could become slower with this type of approach, but I honestly don't see another way out of this that won't mean going the 4.9 LTS road, which would allow new projects to be started with WP 5.0 and legacy projects to stay with 4.9 LTS.

UPDATE: when I wrote this comment the title of the thread was different and the possibility of deprecating metaboxes was being discussed (i.e. core team hadn't yet clearly replied to this question with a firm "no" as it did in comments below). Under such a scenario gutenberg would have simply supported dynamic blocks and ignored the many other use cases for metaboxes, hence my above comment.

Having spent some time reading everyone's comments it seems to me that the likely outcome of this evolution of the edit screen is to provide a new metaboxes api that works within this js based edit screen. I.e. we don't actually lose the ability of using posts in creative ways as I mention above, but we simply get a new api to do it and the UI will be js based.

We are planning to use Pods 2.7 for building a React-powered app using the WordPress REST API and GatsbyJS.
Will Gutenberg be compatible with Pods?

I see this vital issue has been removed from any milestone. It has been de-prioritised _again_ while bells and whistles for blog editing get lots of work and are added to betas. This is very worrying for the future of Wordpress as a CMS.

I made my own code generators inspired by GenerateWP. For my own and private use on localhost, not public.
Anyway, I wonder how would it look in the Gutenberg when switch is done. ACF fields, much custom PHP code for Preview.

We haven't forgotten about this issue. Rather, it is an extremely complicated issue that we are only beginning to look into, along with many, many other priorities for getting the editor working well.

Some of the difficulties we will encounter when wiring up metaboxes may become apparent upon reading through #2251, which also has some info about next steps from a technical perspective.

The main point I want to stress on this issue, here, is that we need help from the community to plan and test this implementation.

Here is a starting point for a list of plugins to look at:

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

Plugins that do not appear above, most likely because they are not in the WP.org plugin directory:

• Fieldmanager

If you are aware of other widely used plugins that accomplish a similar task, please let us know here in this issue.

If you are the developer of one of these plugins, and/or can provide details about what WordPress hooks any of these plugins use to add their metaboxes and enqueue any related scripts or stylesheets, please let us know here in this issue or create a new issue for each specific plugin on the list above. This information is time-consuming to collect, and it will be extremely helpful for further develoment efforts to have it all in one place. For example:

Advanced Custom Fields adds its metaboxes by registering a hook against admin_enqueue_scripts. This hook verifies that the current page load is either post.php or post-new.php, and if so, adds an admin_head action which calls add_meta_box. WP core does its do_meta_boxes calls shortly after that action, in edit-form-advanced.php.

Finally, if you are a developer familiar with the way WordPress currently renders and saves metaboxes, your input here and/or on #2251 is appreciated.

Hi guys,
Elliot here - ACF dev.

ACF uses the admin_enqueue_scripts action to perform "field group matching logic" and then the admin_head action to add metaboxes (via add_meta_box()). It does not use the add_meta_boxes action.

Can I ask an obvious question here? Why are we discussing the 'difficulties' of metaboxes? These are an integral part of every WP website. Surely the metabox logic can remain as it is and live alongside the new Gutenberg editor area.

Please be sure to tag in @woocommerce too. They are most likely the biggest metabox plugin.

Thanks
E

Hi guys-

I am still formulating some thoughts and ideas but I wanted to drop in a quick question because it seems that this discussion is getting a little too focused.

Why are we only talking about adding fields to meta boxes? The current system allows us to add anything. Data, javascript to hit 3rd party API's to use their tools, a quick display of notes or help information, and even pictures of cute little kittens giving people a high five (ok, maybe not this one, but who knows right?!).

The point I am trying to make here is that meta boxes are universal containers that can hold a variety of things that include, but are not limited to, fields. Right now it's pretty easy with PHP to do this, however are we currently asking people to know how to write a React Component just to throw in say, some text?

Like I said, just trying to add to the context of the conversation.

Thanks,

Kevin - Lead Developer for Piklist

This question has been alluded to in many comments above but has not been answered to my knowledge:

Is it possible to replace the existing TinyMCE post editor with Gutenberg while leaving the rest of the interface, including meta boxes and existing hooks, unchanged?

This narrowed scope would allow Gutenberg to be included or excluded from custom post types by defining editor support when registering the post type.

• If editor support is registered, then Gutenberg is present on the edit screen with existing meta boxes continuing to function as they do today around the current editor.
• If editor support is not registered, then Gutenberg is not loaded and the blank canvas is available to meta boxes as it is today.

This approach appears to avoid the massive challenge of backwards compatibility with existing meta box implementations while freeing up resources to make the best editor possible.

Can I ask an obvious question here? Why are we discussing the 'difficulties' of metaboxes?

@elliotcondon - if a dev problem is difficult to solve, the only way to arrive at a solution is to work through the difficulties. I've started doing this at #2251, but as explained there, it's not going to be a quick task or an easy fix.

Thanks for confirming the information I collected about how ACF registers its metaboxes. To make some more progress on the implementation regarding ACF specifically, here are the next things that would be helpful to know:

• What scripts and stylesheets are enqueued to control the functionality of ACF metaboxes
• What actions are responsible for enqueuing them
• Any conditions that control whether they are enqueued or not.

Why are we only talking about adding fields to meta boxes?

I'd like to get to a place where the Gutenberg code doesn't have to care very much what a metabox is actually doing.

Towards that aim, @kevinpmiller, here are the next things that would be helpful to know for Piklist:

• What actions are responsible for calling add_meta_box to register metaboxes
• Any conditions that control whether they are registered or not (e.g. current screen is post.php or post-new.php)

In this issue, let's keep the conversation focused on making existing PHP metaboxes work alongside the Gutenberg interface.

Right now it's pretty easy with PHP to do this, however are we currently asking people to know how to write a React Component just to throw in say, some text?

Yes, we need to work out a set of APIs for creating "new-style" metaboxes. Here is what we have today for blocks - I expect it will be pretty similar, with metaboxes being registered as "blocks" that can save somewhere other than post_content: http://gutenberg-devdoc.surge.sh/

Discussion about new-style metaboxes should happen at #1684 or a separate issue to propose a technical API.

If editor support is not registered, then Gutenberg is not loaded and the blank canvas is available to meta boxes as it is today.

@kevinwhoffman - Gutenberg as written today is intended to be a post_content editor. So it stands to reason that if editor support is not enabled, then at least for now, we disable it. This is also a pretty easy task from a code perspective. Can you create a new issue for this, and I will tag it with the Good First Task label?

Gutenberg as written today is intended to be a post_content editor.

@nylen If Gutenberg is truly intended to be a post_content editor, then meta boxes should be left alone as they are not concerned with post_content.

Furthermore the need for an API to translate PHP meta boxes into React meta boxes is a manufactured problem. It does not have to be a problem, but it has become a problem because somewhere along the line it was decided that rewriting the post_content editor should also completely change how meta boxes work.

You've outlined the tremendous challenge of writing such an API in #2251. Translating PHP meta boxes into React for a popular custom fields solution like ACF is challenging enough, let alone trying to do so for every meta box implementation that exists today, popular or not. It does not scale.

@kevinwhoffman - Very well said. This reflects my exact thoughts as well as many other developers I have talked to.

I don't wish to pull this issue off topic, but I don't understand why there need to be any 'metabox' difficulties when introducing a new JS page builder. This is what I mean when I say:

Why are we discussing the 'difficulties' of metaboxes

I'm happy to read that:

If editor support is not registered, then Gutenberg is not loaded and the blank canvas is available to meta boxes as it is today.

If the above is true, all the wp-admin logic (actions, functions, etc) should be remaining the same(ish) for a post's edit screen. Therefore, there should be no reason why the metabox HTML cannot be rendered as it has done for years.

@nylen
ACF enqueues a few JS and CSS files to style and interact with the ACF metabox HTML element.
ACF uses the 'admin_enqueue_scripts' actions to add these assets
Many other plugins and themes enqueue styles/scripts - why would this be an issue?
ACF does not use JS to save metadata. It uses the save_post action to save any $_POST data - pretty normal stuff.

Furthermore the need for an API to translate PHP meta boxes into React meta boxes is a manufactured problem.

This isn't quite what we're doing. It's more like: since we are no longer using the traditional post.php load process, then we need to pick the things out of it that we need.

If editor support is not registered, then Gutenberg is not loaded and the blank canvas is available to meta boxes as it is today.

To clarify: This is not currently the case, but it would be a reasonable thing to explore in a PR. If you are interested in seeing this working today, please help out, it will go much more quickly.

@kevinwhoffman @elliotcondon @nylen Or better yet, how about:

• If block-editor support is registered, then use Gutenberg.
• If editor support is registered, then use TinyMCE.
• If neither support is not registered, then neither Gutenberg nor TinyMCE is loaded.

I'm not in favor of fracturing the WP Admin experience based on the presence or absence of Gutenberg.

If Gutenberg = New React Meta Boxes and No Gutenberg = Old PHP Meta Boxes, then a fractured admin is the direction we are headed.

Meta boxes should work the same everywhere regardless of whether an editor is present.

Example: Let's say I have a plugin that adds a meta box to rate posts out of 5 stars. The plugin is built so that any post type can be rated. Why should the internals of that meta box change based on whether the post type uses an editor or not?

@kevinwhoffman

I'm not in favor of fracturing the WP Admin experience based on the presence or absence of Gutenberg.

Was that in response to my suggestion regarding block-editor, or something else?

BTW, I don't see my suggestion as fracturing the experience, I see it as building on your suggestion to include existing meta boxes if they exist in the WordPress configuration.

@mikeschinkel The ability to enable or disable Gutenberg is necessary, but the idea of Gutenberg determining meta box behavior is what I am arguing against. Those are separate issues.

@kevinwhoffman I am in agreement with you, btw.

From Pods, we're doing normal, documented, standard things using the same actions as ACF and CMB2. We're all pretty much doing it the way it's recommended to be done right now.

+1 on ability to continue using meta boxes alongside Gutenberg, ultimately people will be able to use Gutenberg for things that belong directly in the content, and for everything else there's still the meta boxes that they love for attributes and additional information about a "post" (of any type).

-1 on having to rewrite everything in React, at least support both for a long while until everyone has time to get comfortable with the React method and it supports more / gets the kinks worked out for meta box implementations. I don't think there's a time in which the PHP meta boxes should be phased out, keep them for backcompat and let plugins migrate as React meta box documentation and developer skill improves in that area.

Following discussion in this ticket, as well as public and private conversations spanning from it, I think there is one critical question that must be answered here:

Does WordPress intend to formally deprecate Metabox API?

If the answer is No then the whole “let’s move things around and cripple them a little” is a non–starter. If the API remains supported to the backwards compatibility standards of WordPress core then the full expectation is for any existing metabox implementation to just work. As things in WordPress do.

If the answer is Yes then this is enormous backwards compatibility policy change and end of era for WordPress development as a whole. It requires not just “solving” metaboxes in Gutenberg. It would require enormous re–education and clarification that many–years span of WordPress core development done in a certain way and providing certain level of backwards compatibility expectations is over.

Unfortunately current answer seems to be not going to say Yes, but intend to break things, while pretending it is a No. Personally I find it extremely atypical approach for a major core feature and it is very unnerving that it is being done in such a way.

The Post Edit screen is _the_ most customised screen on every project that goes beyond a barebones blog.

These customisations are not limited to registering metaboxes. Any hook that the editing admin screens offer is in use in same project out there. And for those cases for which there is no hook, developers use jQuery to inject UI elements into the page.

So for these customisations, there needs to be a way forward.

For metaboxes, Fieldmanager is the tool of choice, due to it being VIP approved. Fieldmanager is powerful, but focussed on a limited set of fields. Legacy code bases can often not be retrofitted to use Fieldmanager, or another utility library.

Thus many metaboxes are still build using custom code. Custom code means a combination of PHP and JavaScript, often with Ajax-driven interactions.

The suggestion of stuffing all these carefully crafted metaboxes from their intended position into an area below the editor is absurd.

Any regression from the customisation options on the Post Edit screen available right now will be unacceptable.

If existing code needs to be updated, you can count 12-18 months from the moment that all new APIs are finalised for these upgrades to happen on client projects. Which means that there needs to be a dual-run period, where both the legacy APIs and the new APIs coexist.

I dont get it why Metaboxes have to do anything with Gutenberg at all ? It is just one backend page, screen. Can be arranged in hundreds of ways.
You said present implementation breaks React.

Let developers chose if they will tie their Metabox to Gutenberg, or keep them outside.
All this problem is because you assume everyone will have to make Gutenberg blocks, one way or other. What if they do not want it, do not need it.

Second big problem for me personally. I allways struggled with javascript, I am anti-talent for this language.
Ok, not everything spins around me, but just to say. It will not be more easy to add Metaboxes, than it was before.

I think @Rarst summed the issue up wonderfully. The community needs a clear answer and it feels like the dev team seems to be inclined to follow the deprecation direction but it simply can't spell it out clearly because it's trying to find a solution first, which I completely respect. We don't need a community going into panic mode for months, but at the same time that same community needs to have enough heads up and a clear road ahead. This is honestly a hard compromise to find.

@fklein-lu I strongly disagree Fieldmanager should be the "tool of choice". I don't even see it in the list of top 10 fields plugin.
https://github.com/WordPress/gutenberg/issues/952#issuecomment-320523428

Like many others have said, while I understand the desire to make metaboxes and Gutenberg a coherent and connected interface, changing the way metaboxes work introduces incredible complexities that may end up as a huge deterrent for people. History has shown us that introducing major incompatibilities between versions can heavily fragment a community.

How would one add Metaboxes to Dashboard backend screen ?
It has nothing to do with Gutenberg.

@khromov Read what I've actually written, instead of misquoting my words. Also if you'd read the post you are referencing, you'd know why Fieldmanager doesn't make the Top Ten list.

@fklein-lu Not sure why you think I'm misquoting you, here's the full context: "For metaboxes, Fieldmanager is the tool of choice, due to it being VIP approved.". I don't know anyone that uses Fieldmanager, so I have a hard time understanding that quote.

I am aware that Fieldmanager is not on WPorg. What I'm saying is we don't have usage data from it. I highly doubt it would rival some of the top plugins, and it also has very little community support, other than the ones that use it for VIP, which is a disappearingly small minority of the total amount of developers.

In our agency we believe, that somewhere in 3.x WordPress made the step from Blogging-System to Content Management System. Right now we are able to shape the content how the project needs it to be and we use custom post types and meta boxes to create a wide variety of different content, not just text.

If the block-editor becomes mandatory in 5.0, we strongly believe that this would be an ideological step backwards from CMS to blogging system. There are tons of enterprise applications, that run WordPress as an Hotel Booking Solution, a Job Platform, a Headless CMS for an App, Location Services, etc, and many of that use cases do not even have the editor activated.

Full backwards compatibility with the current metabox implementation is an absolute MUST. Breaking that will break the trust with clients and users for years to come. My favorite solution would be something on the lines of the ´theme_supports´ and the distraction free usability.

TL;DR: Don't expect enterprise clients to update their code within the next 12 months for other things than maintenance. Add a deprecation policy/warning with an appropriate timeline. Expect a huge dip in trust in WordPress, when you force a change (even for the better) in terms of backend and code usability.

It became somehow as politics, or voting/elections, not coding. Some poeople decided old Metaboxes are "old", "backward", "limiting", and there is no more place for them. Without any real arguments and reasons against them. I have not see them, except that React and other scripts are turbo-modern.

I still support you in finding solution to ditch old Metaboxes and do it as you imagined Gutenberg way. But seems as you have no idea how to solve it.

Difficult to discuss all this when much is still black hole for me. And I am not the only one.

Just to state how much I am objective in this matter, ot try to:

• I still think TinyMce and old post screen (with Metaboxes) is something most beautiful I have seen in CMS world. Functions, filters, expansions, and beautiful design. Yes, pure beauty and pleasure.
• Despite that I accepted Gutenberg from day one. Yes, ditch all this "old", switch and never look back.

They knew something I do not know. They own code. But I am not sure anymore.

Second thing, forgot it, and is very important in this context. It is already mentioned few times here.
I do things a bit differently than others. Reason why I accepted Gutenberg (one of them anyway) from day one is, I personally will have no problems whatsoever to convince people I did websites to to use Gutenberg. It is big schock when you force upon them something so different than TinyMce.
I do all plugin and WP core updates for all of them free of charge. So in this dilema when they have to chose between Gutenberg and stop of any updates for rest of time,. I think their choice is obvious,

Many other developers, companies, charge for updates. So this dilema will not be so easy hearted then.

@khromov I work for Alley, which maintains Fieldmanager. We are actively monitoring the thread while product direction is determined. It would be fair to say WordPress.org userbase generally doesn't use Fieldmanager, but the plugin does have extensive adoption as a library and custom/enterprise framework.

I also want to +1 @Rarst and @kevinwhoffman. Maintaining full support for existing metaboxes could still enable a future where we replace "legacy" metaboxes with TBD Gutenberg equivalents. But the uncertainty right now surrounding backwards compatibility must be mitigated ASAP.

The number of plugin installs from WordPress.org cannot be the only metric for the inclusion or exclusion of a plugin or library. I know of a _single_ site that uses Fieldmanager extensively, and it serves close to 24m unique visitors a month.

So even though only a small number of developers might use a particular plugin, they are responsible for developing and maintaining sites that get a disproportionate amount of traffic, and lots of visibility.

So they cannot be left out of this discussion. I consider that the Gutenberg team at Automattic should collaborate with the VIP team to get an insight into these use cases.

These enterprise projects move at slower speeds. There's whole lot of work that goes into upgrading metaboxes and other UI elements that are not actual coding work. There aren't even enough enterprise developers around to upgrade all these sites in the 5.0 timeframe.

As pointed out by other people in this thread, there needs to be an upgrade path that takes this pace into account. Like that, changes can happen gradually, as part of proactive maintenance work.

@fklein-lu see above, we are listening and you can always reach out if you wanna collaborate on code!

As for VIP and the enterprise market, I expect there will be more than a few conversations on this topic at WordCamp for Publishers next week in Denver. That said, we reached out to Gutenberg devs & @m but AFAIK none will be able to attend.

Regarding "5.0" timeline, at this point the enterprise engineers I've interviewed are assuming there'd be an easy enough opt out path to use the existing TinyMCE editor and metaboxes. Believe that the Gutenberg team has given the 👍 to this assumption, too.

And I have one website that use Jetpack and have only 2 unique visitors per day.
Stop beeing so easily offended. It is WordPress, not discussion about new Joomla version. :)

@fklein-lu Absolutely agree with you. But if anything were to be the "tool of choice" for metabox fields, I'd think it would be the proposed Fields API.

@davisshaver I think that's the wise thing to do. If WordPress tries to strong-arm the deprecation approach with no backwards compatibility I can easily see someone porting old chunks of the code into a "parallel", legacy based alternative posts & metaboxes system and packaging it as a plugin or something like that. Personally that's the absolute last thing I'd hope to see happening. Again, this is definitely all hard work to pull off, so I wish good luck to everyone involved with ferrying the WordPress community into this new unexplored land.

Thanks everyone for chiming in here and expressing concerns and ideas. This is becoming a long thread, but I'll try to clarify a few points.

Does WordPress intend to formally deprecate Metabox API?

No.

The question that is not fully answered yet is _how do meta-boxes work in the context of the gutenberg editor_. Should they remain the same or evolve? How can we move towards the design goals with the least amount of disruption possible?

This issue has been lingering not due to a lack of desire, but lack of resources. The primary focus for this project is to offer a rich content editing interface that optimizes for direct manipulation of user content through the notion of blocks. (Having used meta-boxes extensively for various projects, I believe blocks can offer a better step forwards for many of those needs while providing a better user experience.)

Yet, there are multiple ways in which meta-boxes and extensibility could be handled:

• If we detect a meta-box is registered we can fallback to the old interface, nothing changes.
• We could split editing the content and modifying meta information into two screens or stages.
• We can try to see how feasible it is to render these as they are (PHP) below the content: #2251.
• A theme/plugin/CPT could unregister the new interface as needed.
• Various items that relied on meta-boxes could be converted to blocks for UI (still storing data separately).
• We could implement API based meta-boxes extensibility like the Fields API.

Or any combination of these.

We'd definitely appreciate any help from the community in building the best solution here as, again, the lack of certainty is not a lack of will; just that the possible solutions need to be explored in practice and tradeoffs—design and development wise—clearly written out.

No.

Thank you, I think a lot of people just exhaled.

The question that is not fully answered yet is how do meta-boxes work in the context of the gutenberg editor.

Why _are_ meta boxes in context of Gutenberg editor?

The answer seem to be that Gutenberg aims to replace whole post editor _screen_ with JS–driven implementation. I hadn’t followed development to be aware of reasons for that.

But I still think it was a very valid point raised — if the scope of Gutenberg is to be an editor component then replacing _screen_ scope seems overly ambitious. _If_ the scope of Gutenberg is (at least partial) replacement of WordPress _admin_ as a whole, it is _incredibly_ more broad and demanding scope. Not that replacing “just” editor is any easy.

Yet, there are multiple ways in which meta-boxes and extensibility could be handled

Gutenberg is scoped to replace main _editor_ component and existing admin UI continues to just work? Is _this_ being considered, if not why so?

I can only speak for the field manager plugin I built and that we currently use in over 60 different projects at the moment. I will briefly mention what this change seems to mean for it in the hopes that this can help anyone think about their own scenario.

Because I went through the trouble of building a highly decoupled architecture with common abstract classes and interfaces, all I will have to do is add a new "location". Here's the architecture components that are relevant to my point:

• Location: where the field group is attached (e.g. post, page, taxonomy term etc.), with a variant for each location (e.g. Post and Settings location works with meta boxes). This class instantiates all the moving parts mentioned below
• Location data store: the layer that is responsible for retrieving and persisting the data, with a variant for each location (e.g. post DataStore works with the post meta, Settings works with options etc.)
• Location view: when needed, as is the case for the settings page, it's a View class that holds the template and any helper functions

Now, in the context of Gutenberg, if I'm to support this new editor, all I will personally have to do is add a new location, called Gutenberg, and this location will have:

• Its own initialising method which will hook it to the Gutenberg editor. I imagine this will be mostly javascript based, so my library will register and load the common scripts needed for this purpose.

• Its own view/template: I will have to create a react component for each field type. This is not a big deal, the view layer is pretty straightforward to make when all other pieces are properly setup. These components will then be nested into the metabox react component. This is all very similar to what I already do for the php based metaboxes html, i.e. fields html > field group html > location (settings page html, metabox etc.)

• Its own data store class. I don't imagine this class will be very different from the post location data store, as this will be post meta based (I imagine nobody's thinking of deprecating post meta anytime soon).

• New piece: the endpoints. These new react based components will need to be able to talk to the data store to retrieve and persist values. As these live completely on the client side, they will need endpoints as a bridge to talk with the location data store, with the meta store to retrieve the components that are to be loaded in whatever context etc.

If I am not missing anything major (I admit I have not had the time to check Gutenberg out yet) this is more or less the gist of what I think I would have to do to natively support this new "location". I also have built-in checks for each location and its filters to make sure what the developer is asking is possible, e.g. if I try to add a field group to a "projects" post type where the format if the post type is "video", but that CPT does not support post formats, the library will throw an exception. I hope I'll be able to provide the same feedback with this new location, e.g. if I add a field group to a Gutenberg location where the post type is "reviews", I hope I'll be able to know wheter that post type was registered to support Gutenberg.

This ended up being a bit longer than I had anticipated, my bad. I'd love to hear back from anyone involved in Gutenberg development or any author of libraries with similar concerns who have any feedback to share.

Thanks.

Gutenberg is scoped to replace main editor component and existing admin UI continues to just work? Is this being considered, if not why so?

Gutenberg did start just with the editor box. The kickoff goal was to unify multiple disparate interfaces under a single unified block interface. It quickly become apparent that in order for us to create a compelling experience revolving around this unified block interface, we had to consider the full writing flow, including settings and publishing.

If the key strength of WordPress is to make it easy for anyone to create rich posts, then we can't just design for those of us who already know how to use the editor. We have to consider users who've never used WordPress before, and what they expect in a modern publishing interface. Otherwise we'd just be adding cognitive load to an already heavy interface.

We're not done yet, and it's not easy, but we're working on it every day.

☝️ I have updated the ticket title and description to hopefully address some misconceptions.

The new Gutenberg editor and the future of ButterBean

As requested in the comment above, I'm listing the ButterBean meta box framework. I can create a new ticket if necessary.

Repo: https://github.com/justintadlock/butterbean/tree/dev

For testing purposes, the framework is included in this plugin: https://github.com/justintadlock/custom-content-portfolio

ButterBean is a drop-in framework built with Backbone.js and Underscore.js. It is modeled heavily off of the customizer in core WP.

It's a young framework, but it's one I've been planning to roll into several plugins this year. Right now, I and others are hesitant to do this because of the direction of Gutenberg. And, I'm not even sure if I shouldn't just start over from scratch in React or whatever JS framework is ultimately decided to be added to core WP next.

Hooks used

The following are the primary core WP hooks used (pretty standard for most meta box frameworks, I'd imagine):

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

Created #2265 to document relevant hooks for CMB2.

Added Design label to encourage people to add additional mock-ups.

In general, I feel that data which isn't a part of the content being displayed shouldn't be a part of the main editor area. Not everything is a block.

1) The majority of my custom meta boxes are made with Fieldmanager. In my eyes, these should "Just Work" with no additional work needed on my end besides updating. cc/ @mboynes and @bcampeau as they may be able to provide value to this discussion.

2) Some of our custom meta boxes are a mix of jQuery and PHP. For example, we have a "One or none" meta box that is a radio with a "clear" button. Assuming that this will break, I would expect that there would be examples of how I create this in Gutenberg and that there would be a significant amount of time for me to upgrade to a version of WordPress that mandates Gutenberg before my code breaks.

3) I have another metabox that combines some jQuery and PHP code which disables the publish button until a selection has been made. Similiar to my second example, assuming that this will break, I would expect that there would be examples of how I create this in Gutenberg and that there would be a significant amount of time for me to upgrade to a version of WordPress that mandates Gutenberg before my code breaks.

4) I've removed the category meta box in the past and replaced it with: 1) a radio select 2) A version without the ability to add new categories (this was dumb).

5) I've used post_submitbox_misc_actions to add options to the publish metabox that don't need to be in their own metabox.

As far as what I mean by a significant amount of time, I would say ~2 years from the point that the Gutenberg API is frozen.

While we are at it, I've like to remind everyone here that not everyone uses just metaboxes to extend the post screen. Some of us also use the following hooks:

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

I just want to second what @mikeschinkel said about edit_form_[POSITION] hooks. Piklist makes heavy use of for meta-boxes, workflows and other things.

Thanks again for your time guys.

The question of whether Gutenberg is an editor replacement or a screen replacement is important to answer as soon as possible not just for those concerned with backwards compatibility but also for those developing Gutenberg. The answer to that question affects many of the decisions being made every day regarding how Gutenberg works and where controls are located.

It's been clear since the first beta that we're already well on the path to a screen replacement, but that decision to overhaul the screen is also what created the issues of meta box support and missing hooks. If the answer to these issues is "don't replace the whole screen" then I worry that so much work has already been done under the assumption of screen replacement that it would be difficult to go back.

Firstly, great to see real progress on this.

One observation is that edit-screen extensions rarely work in isolation. For example, ACF changes the visible fields based on JS change events on the post parent select box.

Given that the DOM will be different in a Gutenburg context, and that React is likely less suited to external event listeners, how do we continue to make this data available to metaboxes and other plugin code. One possibility is that the Redux store is made available to metaboxes, but I don't know if this is possible, desired, or gives enough flexibility.

This becomes even more problematic when metaboxes are loaded in an iframe, or ajaxed into the page.

It's been clear since the first beta that we're already well on the path to a screen replacement, but that decision to overhaul the screen is also what created the issues of meta box support and missing hooks. If the answer to these issues is "don't replace the whole screen" then I worry that so much work has already been done under the assumption of screen replacement that it would be difficult to go back.

I completely get how much work has been done towards the "screen" replacement approach. But a project that started with the goal of a "post content editor" replacement, shouldn't have gone back to the community before deciding unilaterally that it would replace the whole editor screen?

I don't mean to dismiss the huge work that has been done (the editor really looks amazing), but too much WordPress relies on meta fields that are not strictly "content", and many of it won't fit at all inside the same Gutenberg container (unless it being completely forced). To me, it seems more like "we have a solution and need to create a problem for it" than the other way around, which was the original statement of Gutenberg (post content editor is quite messy, shortcodes are everything but friendly to use - despite approaches like Shortcake -, etc).

@brentjett mockup from July 4th seems to be something that could work both for "revamped metaboxes" that do not fit in the content ("settings area") and meta boxes that could easily be converted to a Gutenberg block (event information).

@rilwis I think you should drop by and mention the extensive use of Metaboxes in your plugin. Since I use it in most of my products, I find it to be an extensive framework. How does it fit in this whole Gutenberg thing? — Insights from someone whose business is to sell a plugin to build metabox (that's going to get affected the most) should be useful here.

For design inspiration you can check free and commercial (screenshots) backend Admin themes. Or any other platform.

Dashboard, but imagine Gutenberg:

Perhaps the proposed Fields API will solve some of the issues around supporting metaboxes in the new editor

The scenario we should be considering is what happens when WordPress is updated with Gutenberg and the plugins that implemented the meta boxes are not.

This is the "worst-case scenario" that poses the biggest threat to breaking the admin experience, but it will not be uncommon given the number of sites powered by meta box plugins including the big-name players and the custom one-off solutions.

Relying on these meta box plugins to be updated should not be part of the equation unless we are willing to acknowledge large-scale breaking changes. The Fields API is a great idea, but we shouldn't assume that improving the way custom fields are handled in the future will have any impact on code that was written before such an API existed.

It is clear that:

• We are not going to break backwards compatibility on any large scale.
• We are not going to bifurcate the editor page using some detection mechanism.
• We will have a single editor and editing experience.
• There are many use cases above that the current Gutenberg implementation cannot accommodate.

Therefore:

The way forward is to rethink the post edit screen in a way that embraces the new and old. That very likely means backtracking on the current Gutenberg implementation in some manner. It is a design challenge, not the end of the world.

@dmccan No, those statements are not "clear" as every solution proposed thus far either:

• Splits the admin experience between new/old.
• Relies on plugin updates to blockify their meta boxes.
• Relies on a non-existent Fields API.
• Requires the new interface to be deregistered to avoid the problem altogether, which would again split the admin experience.

I didn't emphasize the worst-case scenario to be melodramatic; I did it to define the constraints within which we should approach the problem.

So it seems like Gutenberg should likely stay a feature plugin for a long time, one that people can choose to select if they like or to opt out of if not, possibly to even be included as a plugin with core.

Solving all the problems it needs to solve in order to have a single editor experience will take a lot of calendar time. Just look at Microsoft's original ASP.NET and how badly it solved the general web problem. Eventually AJAX emerged and the rest is history.

Forcing a change too quickly could result in WordPress becoming a true legacy-only platform.

P.S. The "single editor" requirement seems to be unrealistic. If the users had the option to use the old or the new then the new could be allowed to evolve over time until there was no longer any benefit to use the old. But as long as there are installations using the existing hooks _(I believe)_ it is irresponsible to go with a single editor solution. #jmtcw

@kevinwhoffman - I think we agree, but maybe I wasn't verbose enough.

I think my bullet points are clear and the final solution will embrace them. For example, I don't believe that WordPress will break backwards compatibility on a large scale, despite what people looking for solutions might propose at this point.

The solutions proposed so far are lacking, which is where my conclusion, that we need to rethink the current Gutenberg implementation to embrace both new and old, come in. I think that doing so is really the only way forward.

@mikeschinkel - I don't imagine that Gutenberg will be the only editor option in Core in 2017. It could well be that it starts as a user choice and evolves to the point that it covers all of the essential bases, or it takes the time to get it right.

In any event, what I'm suggesting is a backtrack to incorporate Gutenberg in some upgraded version of the current editor screen, rather than throwing everything out and then wondering how we might handle all of the essential functions. I think that is doable and possibly not that huge of a backtrack, once people come to terms with it. Such a course would likely be faster and provide a better end-user experience.

Maybe they (core coders) should talk to the Matt. He started all of this and they now do not have answers.

@dmccan One thing that I believe will be critically important is that whatever is implemented has an easy extensibility model. WordPress is known for its easy extensibility model with plugin action and filter hooks and without that Gutenberg will be as bad for WordPress as the current media management system that is very difficult to extend.

As a side note, while I have never using React or Vue _(I am a PHP dev)_ the discussion over React requiring a build system and that many people found Vue much easier to use than React has caused me to become super anxious over whether Gutenburg will have an easy to learn and use extensibility model or not, and whether or not it will mean we can continue to use WordPress for client projects.

Just my feedback to note my concern, no need to reply directly to this.

I think I know what it is all this about.
It was never about content editor, never about "writing flow", "breaking with old....backward" etc...

It is about full-blooded front-end visual theme editor.

Sorry for sending emails to all of you. My last comment on this particular issue.

@Rarst @kevinwhoffman : I totally with you about whether or not Gutenberg is a editor replacement or screen replacement. It's a well-thought point. And I hope the dev team can go back to the start point and the nature of Gutenberg - an editor, and keep everything else as it is now. They're 2 different parts and can be used with or without each other. So it's better to keep them as separated things.

In addition, I created #2308 to list the relevant hooks from Meta Box plugin.

@ahmadawais Thanks for the mention.

@nylen It would be worth adding Posts 2 Posts to the list of plugins to consider. Though it's no longer supported, I expect it is still quite widely used.

@nylen I maintain my plugin Developer's Custom Fields but it's no longer actively developed (I use CMB2 these days). Only 1000+ active installs but maybe worth adding to the list.

I agree with the comments about Gutenberg Editor being just that, the content editing portion. Not sure why or how it got sidetracked into being a complete screen replacement. All of the popular page builders out there do it right, just replace TinyMCE with something else which makes it easier to compose content.

Also, meta boxes typically are not part of the content, and even if they are content related they usually still don't make sense to be a block.

Take a staff directory for example. Why would I want the fields for the persons information to be a block? It's not like you'd want them adding other blocks when they are just supposed to be entering First Name, Last Name, etc...

tldr; Gutenberg should only replace the TinyMCE editor for post types that need content composition.

Just adding my two cents here.

Why not just leave it as it is now? What I mean is this.

• Keep the two edit options when hovering over the post title like it is now, but change it so by default clicking the title will bring you to Gutenberg. Then have the Edit link go to Gutenberg and have an additional link go to the classes edit screen. Maybe call it something like Classic Edit.
• Add some type of support flag for the Post and Page post type, so Gutenberg can be disabled if a developer wants to do that. If Gutenberg isn't enabled then have the title link go to the "classic" edit page, remove the Edit link to Gutenberg and the Classic Edit link's text would change to Edit
• Then with custom post types have Gutenberg support like for the Editor, Featured Image, etc. That way a CPT doesn't have to support Gutenberg.
• Then update the styling of the classic edit pages. Updated the meta boxes and the sidebar styles to match the Gutenberg styling. Even move the excerpt and comments meta boxes to the sidebars like in Gutenberg.

I think this would make everyone happy. Gutenberg would be on by default for the Post and Page posts types. If devs need to use meta boxes instead of Gutengerg they can. It would give plugins and theme devs time to convert over to Gutenberg and it would give end users the ability to adjust to Gutenberg without interfering with their workflow by the editor change.

And it will allow devs the time to start selling the idea of using Gutenberg to the end users. People tend to not like change. Letting them get used to the new editor would be a lot better than just a hard change.

This would also separate the two which would allow the two different saving methods. Gutenberg can use JS and classic can keep using PHP.

I'd add some type of warning like if a user saved a post with Gutenberg then tried to edit it with classic to let them know that if they save the post it will override the post's previous save from the other editor. There could be something like a post meta to indicate which editor was last used.

It's an idea. It may be a stupid idea, but I think it would alleviate all the concerns that a lot of devs are having.

I totally agree with the points which many people have raised about the scope of Gutenberg today. This project first started as a (much needed) improvement to the content editor. Reading through this thread, I can't help but feel that we're creating problems that don't need to exist. If we stick to the original plan of adding Gutenberg to the editor (not replacing the full screen) then this solves so many issues, not just regarding Meta Boxes.

By completely revamping the screen, I fear this will cause so many problems for non-techie content editors. The average blogger/author is going to see a completely different screen and panic. If the update simply targets the editor, the onboarding experience can be much more controlled.

Another way to approach this might be to use the same workflow as Beaver Builder. I.e. keep the normal post edit page (with the usual Meta Box sections etc) then Gutenberg could be launched via a button. This can then take you to a new screen. Much like the comments about targeting the Distraction Free Writing mode.

I also agree with people suggesting to keep the existing meta box UI and change only the content editor.

I think most of us do recognise that the primary factor in pushing a platform forward is to innovate. It is evident that WordPress is slowly trying to move towards a JS based approach for richer experiences that can match (and surpass!) what everyone else is doing. If we're being honest, the entire metaboxes system and current edit screen UI can feel somewhat dated, but as developers we are so used to it that it's second nature to us and we fail to take into account how much of a learning curve there is to it.

Reading this entire thread clarifies two things for me:

• It is obvious that core team does want to push for a fully js based edit screen, and imho that's ok
• Perhaps if we can all accept the above point, we can move the conversation towards the legacy support and migration strategies to pursue

As soon as we understand how the js version of the metaboxes will eventually work (are there a proposed API?) we'll be able to start thinking about how to create a bridge that makes our existing technology (plugins, fields managers etc.) work with this new approach.

If an API focused discussion is already happening could someone point me and anyone else who doesn't know where that's happening in the right direction? Thanks!

Is there a reason not to split the editor into two screens navigated through tabs?

My view is that Gutenberg is,

• An attempt to tidy up the editor screen
• An attempt to add page builder/layout functionality to core
• An attempt to minimise the need for metaboxes by making it easier for developers to create new content blocks.

The problems, as highlighted above and as most of us developers and end users can feel and foresee, is that Gutenberg,

• Removes editor style format choices from authors
• Forces authors to use a non intuitive workflow that requires many mouse clicks to add blocks
• Breaks many older plugins, some of which are maintained and some that are not.
• Converts WordPress into what feels like a Tweet platform.

Using Guttenberg to create content has all the same awkwardness as designing an email template in Mautic or MailChimp. Guttenberg's UI would work well for template design but not for longform post creation.

We should concentrate on increasing workflow fluidity, not the introduction of a stop-start content creation UI.

The UI for Guttenberg looks great but it is unrealistic to expect end users to be happy with it while it is anywhere near its current form. It gets in the way of content creation.

The text block is next to useless. A text widget should not limit authors to the use of only a few font formats. This will annoy many authors.

Here are my suggestions:

• Introduce Tabify Edit Screens into the page editor.
• Move metaboxes into their own page tab within the editor screen.
• Use a non React based page for the metaboxes (page hidden behind an editor tab)
• Use a default TinyMCE (or a similarly feature rich editor) based canvas that works well for longform and that does not insist authors use blocks.
• Introduce Guttenberg Blocks as an addon to TinyMCE or the TinyMCE lookalike.
• Introduce Shortcake to the TinyMCE based editor such that authors can visually see the content of blocks and such that authors can edit content directly in the page flow without need to click an edit button for each block.
• Make it easy for developers to add new blocks to Guttenberg by tying add_shortcode() into block creation e.g. add_shortcode('tag','function','guttenberg true/false'). Adapt add_shortcode so that it automagically makes the shortcode compatible with Guttenberg; this will allow developers to easily convert some/many of their metaboxes to shortcodes that work within Guttenberg.

What I'm really saying is that Guttenberg needs to be broken into 3 tasks:

• Editor screen clean up
• Improved editor UI
• Improved editor extension framework.

I would say most people use WordPress to create long-form content and have no wish to be forced to use blocks to create their content. Blocks are great for page layout creation but annoying when used every time a post is written.

I have a customer who is in her 80s. She just wants to create content. She does not want to be forced to relearn how to use the editor screen. It has taken over a year to get her accustomed to Visual Composer and that's an easy page builder to use.

I've digressed from the original thread topic but this needs to be said: Guttenberg will kill WordPress.

If Guttenberg is introduced in its current form, WordPress will be forked and the Guttenberg version will die.

Perhaps the new editor makes more sense if you use WordPress for a blogging site and creating a PHP theme for it but nowadays a lot of people use WordPress as a CMS for building web applications using React, PODS/ACF and the WordPress REST API. Hence the need for supporting metaboxes and Relationship fields for advanced linking between CPTs.

First off, I think Gutenberg is going to be awesome.

That being said, I think we can all agree that breaking websites/functionality breaks trust, and that's not cool. We all want to be able to trust each other, and our clients/customers want to/need to trust us.

I think the best thing we can do is include a filter that developers can use to revert back to the "legacy" editor screen.

This way, we can apply our own logic to determine whether we're ready for Gutenberg or not. If a user is using a meta box that is going to break completely in Gutenberg, we can choose to revert to legacy mode.

Then, we can work at our own pace to migrate our meta boxes or ideas to fit with Gutenberg, while keeping old posts that depend on our "legacy" meta boxes working as they should.

Why can't the legacy metaboxes be rendered at the locations (context) they are registered for and keep on functioning as they currently do?

So, first render the (optional) Gutenberg editor section, followed by any registered (legacy) normal/advanced context meta box (with it's registered title), then the sidebar with the new Post Settings column and under that any registered (legacy) side context meta box (with it's registered title).

Of course the legacy meta box would be styled just like the new the Post Settings box everything would look well integrated.

Maybe it would require a legacy-meta-box.php script that would be loaded when needed, e.g. when add_meta_box is called.

If we only ever think of current meta box solutions as "legacy" and require them to use the old editor without ever thinking through the reasons for using them in the first place and then working on better ways of providing that functionality in the new editor then current sites are just going to stay legacy and never upgrade. This will be a huge issue for those of use that manage client sites.

The reason we use ACF fields in almost all our projects is to control the data so it is displayed consistently on the website. Here are two examples we are working on currently; A large events site and a festival with works/installations that need to be linked to artists but displayed separately. In both these cases the "content", the piece that Gutenberg is replacing is only about 10% of the content on the edit screen and is actually the least important piece. For the events site, the important data is Event type, event Category, date, time, location, organiser etc. You can publish a meaningful event entry without entering any content in the editor at all. For the festival site we need to be able to select an artist and link it to a work, select the works location on the festival site and upload a featured image, again the content is an extra not a necessity. For all the "normal" page content on these sites Gutenberg isn't flexible enough (and nor should it be by default, I don't believe) and we'd continue using a more fully featured page builder (Beaver Builder) for better design options.

The other key factor in all of this is the order of the content on the edit screen. For an event you need so set a title but then in an ideal editing flow you want some of the key information like date, time etc entered BEFORE you enter any "content" in the "editor". We have to have the ability to control where in the editing page the content is, before or after the "content".

The idea of just creating another tab with all the "legacy" meta boxes on it would be horrible. It would break the editing flow entirely for many uses of CPTs, hiding the content from users in a way that I think they would find very hard to discover.

The project needs to be MUCH smarter about that. A tabbed process might work great if you could choose (in some kind of page template) which bits were on which tab. You'd also need a mechanism for stepping the user through each tab. However, I also believe that for shorter CPT items you HAVE to have the ability to keep it all on one page with certain key elements above the editor content (required blocks if you will).

All in all most of the solutions people are talking about don't seem to have any of the flexibility of the current edit screen.

That's why I'm scared about the timeline of 5.0 for this, it feels like it could be great in time but if it gets rushed out the fragmentation will destroy all good will from both developers and clients. WordPress is trading on it's flexibility, backwards compatibility and general user friendliness. We can't sacrifice that for the new shiny toy. Look at the PHP requirements for WordPress, we're talking literally years before PHP 5.6 or 7 will be a requirement. The community has recognised that no matter how frustrating that long timeframe is, it's necessary to not break websites. Isn't this EXACTLY the same kind of problem?

Changes like this, while ultimately they'll be great for the platform have to be well thought out and managed or they risk the very foundation that WordPress is built on.

@avocadesign - Some good points. We will be able to register JavaScript meta boxes going forward, though it seems like the current thinking is to have two locations ... which is not as flexible as you've mentioned.

@avocadesign - well explained. The post_content is not always the focus of a post and your 'events & artists' is a good example. It would be great to see some screenshots showing the back-end & front-end of these post types so we can help developers visualize how WP is being used as a CMS, and how a typical client works through a post edit screen.

@avocadesign

If we only ever think of current meta box solutions as "legacy" and require them to use the old editor

In what I suggested (above your comment) the 'legacy' meta boxes are positioned either under the Gutenberg editor (if the post type needs that) or under the Post Settings block (depending on the context they are registered for). I don't see any requirement to keep the old editor around.

I agree a tabbed interface wouldn't work. What do you think about my suggestion. As I see it it would give you all the flexibility you are used to and would allow you to move to the new system when ready.

If Gutenberg would become part of core, you would be able to build an even better UI for the samples you mention. It would partly consist of a custom Festival block (sort of WYSIWYG form) and related settings in one or more (JS based) Post Settings sections. The user would benefit from a faster interface with direct feedback.

WordPress is trading on it's flexibility, backwards compatibility and general user friendliness. We can't sacrifice that for the new shiny toy.

I disagree. I think you should give the Gutenberg a bit more credit. They are working hard on a solution that works for everybody. They are listening and looking for use cases (just like the one you mention) Nothing is set in stone yet, nor is the release Gutenberg 'might' be part of.
If Gutenberg doesn't address all issues currently under discussion, you can trust it won't be part of the 5.0 release. We have seen that happen in the past numerous times with other features too.

Here's an example of an interface I built with Advanced Custom Fields for a client who manages hotel properties.

• The Property custom post type uses 18 custom fields across 10 tabs.
• Tabs keep all pertinent information on one screen and accessible to the editor at the click of a button.
• Field types include simple text and number fields in addition to ACF galleries and relationship fields.
• Support for editor was not declared in the custom post type registration, which means the entire UI relies on custom meta boxes.

This type of UI is representative of many custom WordPress sites where a series of custom fields hold a mix of on-page content and "invisible" meta data used to organize posts.

The community needs to know what happens to this type of interface once Gutenberg is introduced, and I don't think asking @elliotcondon to migrate all of it to React in time for launch is a realistic expectation.

@kevinwhoffman

The community needs to know what happens to this type of interface once Gutenberg is introduced

You are right, but the goal of this issue #952 is to _find_ that answer by discussing and suggesting alternatives. What would work what not. At some point in the future, when everybody thinks we all came to something that would work in all legacy and future cases, only then it can be implemented and can the (user) community be explained how it will work. Currently it's simply too early to expect an answer from the team to that question IMHO.

I think the use case you provide and the one that @avocadesign provides will help the team very much.

In regards to your example, my suggestion (see a few reactions above) would simply show all the boxes as shown in the screenshot (with the new Gutenberg styling of course).

@kevinwhoffman

Gutenberg will most likely be opt in for CPTs, much like how your CPT does not declare support for the current editor. I don't see why it would ever not be opt in for CPTs as most things in WordPress are extremely flexible, Gutenberg will not be any different. It currently only works for posts.

I highly doubt Gutenberg would change anything at all for an interface like this, nor is it the intent to. That being said, it could be interesting to explore what Gutenberg offers and see if you could create a more compelling editing experience for your client by using it.

For example, you could create a property/properties block, that could be used to allow your client to embed property information into other posts etc. quickly and easily. Then while editing in Gutenberg they could change the same information you see in ACF while looking at the property information being displayed inside Gutenberg. Gutenberg is not overtaking the admin interface of WordPress, it is replacing the functionality of the editor, and will most likely lead to block based content templates.

Good things are coming from Gutenberg, not headaches!

Here's the Events edit screen for the site mentioned above with ACF fields above the post_content and then The Events Calendar standard meta box below post_content.

The site will be opened up to many many non technical users, we are not talking a trained editorial team, we're talking Joe average who's never used WordPress before or ever been trained other than the help we provide in the site.

We've set it out this way to ensure that users find and enter the event type and category and header and featured images for each event. We are also able to use the existing meta box positions to provide relevant help documentation on screen to help them edit the event and provide support to new users in a non intrusive way.

Also please bear in mind that we are logged in as an admin, non admin users have had various sidebar meta boxes hidden to further reduce the visual clutter they see.

The "content" isn't nearly as relevant as the various meta boxes to successfully enter an event. An event won't display on the site if a date is not correctly entered or a category selected. The thing that worries me about this whole discussion is mock ups like in issue #1352 where the meta boxes are relegated to the bottom of the screen in a collapsible section. I can guarantee you from our experience we would have untrained users never seeing the meta boxes, just entering the date and location directly into the content area as plain text and then complaining that their event wasn't showing up in the system. It's just not discoverable enough for untrained users in post types requiring structured information.

Also we have required fields in this interface and if the meta box is collapsed a user is going to get a warning but not be able to easily find the cause of the problem.

Metaboxes or the next iteration of their type of functionality need to be first class citizens and we need the ability to place them above the content, beside the content or below the content in order to make useable interfaces for our clients.

Gutenberg will most likely be opt in for CPTs, much like how your CPT does not declare support for the current editor.

Registering support for Gutenberg in CPTs has not been confirmed, and honestly it feels more like avoiding the problem of meta boxes rather than solving it. If the only way for existing sites to access Gutenberg is to register support for it by code, then it would severely limit the potential audience.

We should also not pretend that custom meta boxes are only used in custom post types. They are just as likely to exist on regular posts and pages.

Gutenberg is not overtaking the admin interface of WordPress, it is replacing the functionality of the editor...

This is inaccurate. As it exists today, Gutenberg _is_ a full-screen replacement for the post edit screen.

@BE-Webdesign & @kevinwhoffman

Also why should CPT's have to miss out on the aspects of Gutenberg that are clearly better than the current edit screen?

The publish controls being moved to the top so they are not confused with content and a cleaner overall aesthetic are definitely strong points of where this project is heading.

By not having a decent plan for how to create equivalent functionality to what is there currently for CPT's with complex needs (via meta boxes) we are ignoring a large portion of the user base and relegating them to a second class, ultimately unsupported experience.

IMHO that just plain sucks.

I'm not even arguing that metaboxes need to work out of the box as they currently exist. There might be a new and better way to implement this kind of interface flexibility.

What I'm concerned about is that the dev team doesn't really seem to grasp the issues for a lot of developers with enforcing a "post_content" first approach here. We use Beaver builder on ALL our sites, except for CPT's where we need structured data output. A page building tool, which is what Gutenberg is, is great for posts and pages with individual content needs. It's terrible for structured data. For structured data, interface consistency, required fields and other layout priorities trump free form content every time.

@kevinwhoffman

We should also not pretend that custom meta boxes are only used in custom post types. They are just as likely to exist on regular posts and pages. This is inaccurate. As it exists today, Gutenberg is a full-screen replacement for the post edit screen.

Yes, but it is not replacing the entire admin interface, which is what I was referring to. You are comparing an incomplete project to the current experience. #2251, when it is complete, will introduce the almighty meta boxes back in, so it won't be all that different, and will be a whole lot better. There probably will be some things certain plugin authors may have to tweak, but for the most part I am confident that things will go smoothly.

@avocadesign

Also why should CPT's have to miss out on the aspects of Gutenberg that are clearly better then the current edit screen?

Nobody said they are to my knowledge? There is not too much difference between adding editor support for a CPT, and adding support for the block editor.

By not having a decent plan for how to create equivalent functionality to what is there currently for CPT's with complex needs (via meta boxes) we are ignoring a large portion of the user base and relegating them to a second class, ultimately unsupported experience.

I think there is a decent plan in place, maybe it is not clear, but I am very confident that Gutenberg will meet the needs of the vast majority of all types of users, even exceed them, when all is said and done.

Nobody said they are to my knowledge? There is not too much difference between adding editor support for a CPT, and adding support for the block editor.

I worry that the step talked about by many in this thread of making Gutenberg opt-in for CPT's will result in many of the current complex use cases to be ignored in Gutenberg in the short to medium term and effectively force use cases such as the events one illustrated above to use the existing system because Gutenberg isn't flexible enough. That is effectively forcing those current complex use cases to miss out on the other advantages of the project.

We're being told "don't worry, it will be alright" a lot but you are right @BE-Webdesign when you suggest that the plan is not clearly presented at all for some of us, I just can't see at all how this is going to be resolved satisfactorily in the short term - if it is then feel free to point to the discussion or issue to enlighten me.

Edit:
What I mean by "short term" is by launch of 5.0 to the public, early 2018 seems to be the goal here. Longer term in 2 or 3 years time I can see this being much more successfully resolved.

@BennyVL & @dmccan Flexibility is key problem here. Correct me if I'm wrong but none of what I'm seeing suggested by the devs working on this is as flexible as what we currently have.

With ACF and other plugins I can easily register metaboxes above the content (below the title), below the content and in the sidebar. The design of the interface is up to me. It doesn't enforce that the editor is first, it doesn't mandate that the editor is even present. I can register new metaboxes, I can deregister or move others.

What I want is a solution that remains this flexible in the long term. Whether the metaboxes need to be updated to a shiny new JS format, become proper blocks or some other change needs to happen to make this possible doesn't really bother me. I want the flexibility we currently enjoy to be included in Gutenberg regardless of the method used to get there.

What I want is a solution that remains this flexible in the long term. Whether the metaboxes need to be updated to a shiny new JS format, become proper blocks or some other change needs to happen to make this possible doesn't really bother me. I want the flexibility we currently enjoy to be included in Gutenberg regardless of the method used to get there.

That is the goal and what most people want.

I have listened to a lot of chatter about the meta box issue and what will happen to them with this new editor. My personal view is that Gutenberg should focus on just the editor and not the entire page edit screen. But it seems that decision has already been made.

Hi guys,

I'm the lead developer for Carbon Fields and wanted to add the list of actions/filter we use that may be affected:

Filters:

• postbox_classes_{$page}_{$id}

Actions:

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title (positioning sugar - not critical)

My questions:

• If we are going to keep legacy meta boxes how would they interact with data changes?
• What type of events (jQuery? some exposed implementation of an emitter?) and what events exactly can we expect from the new editor (e.g. on submission success, failure etc.)?
• Will these events be available to legacy meta boxes or only to React implementations?

PS:
I just want to thank the Gutenberg team for all the hard work and effort and it makes me excited that WordPress is moving towards modern tools and solutions (even if the journey seems scary)!

Supporting meta boxes is very important ...

... for thousands of wordpress developers and users.

WordPress can't ignore the big plugin player ...

... like Advacend Custom Fields Pro (https://github.com/elliotcondon/acf/issues/622), WooCommerce or Yoast SEO.

I'm responsible for Toolset project, which uses custom types, fields and taxonomy heavily.

We want to make our plugins compatible with Gutenberg.

This is what I understand:

• We will need to use a new API to display the custom fields and taxonomy on pages and posts, when they use Gutenberg.
• We don't need to do anything about Gutenberg for CPTs, because they will use the normal WordPress editor and not Gutenberg.

Is this correct? If so, could you kindly refer me to the documentation for the API for displaying custom boxes on Gutenberg?

I think the docs are still evolving. There are some docs at https://github.com/WordPress/gutenberg/tree/master/docs -- http://gutenberg-devdoc.surge.sh/

I'm hearing what @BE-Webdesign and others are saying about the intent to minimise disruption - thanks, that's reassuring - but just wanted to add my 5p's worth (ok, ok, my usual 105p's worth.)

Anyone who's been developing for a while will remember the pain of manually creating web interfaces for bespoke databases - boring, time-consuming, error-prone and very expensive in terms of developer time.

WordPress plus Advanced Custom Fields (Pro) is a great tool for efficiently creating bespoke database-driven websites (and even intranet data management tools) with attractive front ends, rigorous data-entry checking, intuitive and consistent user interfaces etc. These systems may not be scalable for enormous volumes of relational data, but in very many cases they don't need to be; these are simple systems that can be created in a cost-effective way for clients. This is what makes WordPress a really useful CMS (and, in effect, a lightweight RDBMS), not just a blogging platform.

I (and I'm sure many other) small businesses use WP+ACF (or similar custom data plugins) to create bespoke sites and systems for client organisations and individuals who don't have big IT budgets. If the introduction of Gutenberg is done without due consideration for supporting existing editing/data-entry flows, metaboxes etc, I have two "non-technical" but nonetheless significant problems:

1/ My end users will require re-training (it's easy for us, as techies, to forget how massively confused non-technical users can get by interface changes - I wrote the Clarify Password Reset plugin because I was losing so much time sorting out users who were totally stymied by the new password reset process introduced in 4.3).

2/ As well as upgrading my own plugins for a different metabox approach, I will have to spend time upgrading and testing all my client sites with a professional level of diligence, making sure that any and all of the third-party plugins I'm using have also managed to update their codebase correctly. (And this in a situation where I have no control over how rapidly the third-party plugins are updated, either in advance of or (even worse) sometime after the 5.0 release - so workload-planning becomes really difficult.)

In neither of the above cases would I feel it was right to charge my clients further fees for that additional work; after all, I chose the platform on which to build their sites and systems, and it's not like they've requested any changes or improvements. Maybe I'm "too nice" or naive on that front, but as people have mentioned above, it's a trust issue; we trust WordPress not to drop us in the poo by breaking backwards compatibility, so that our clients can trust us not to sting them for unexpected extra fees. The net result is that I suddenly have a huge amount of extra unpaid work to somehow fit in - possibly urgently, if sites are actively broken by the upgrade right away - while continuing to do enough paid work to stay afloat.

I really like using WordPress, and have invested much time learning the ropes, developing my own handy project frameworks etc - to the point where I now make most of my living (and feed my family etc) via WordPress-based development projects. I've also tried to give something back by taking the time to formally release useful little plugins I've developed onto WordPress.com, because I value OSS, community-based development etc. I guess this is mostly a plea to take the issues mentioned in this issue thread to heart as much as possible; otherwise I agree that there's a real danger that the codebase might get forked. As a WordPress fan and plugin contributor, I would think this a REALLY bad outcome; however, as a solo developer relying on WP to make my living, I might have to go with the forked (i.e. properly backwards-compatible) version out of economic necessity. Please don't let this happen!

@konamac makes some great points, some of which I've posted about in another thread.

To piggyback off of this, it is entirely unacceptable to not give us a reassuring answer on the future of metaboxes.

1. There is no straightforward answer to the future support of existing metaboxes. This is an extremely frustrating and heavy handed move against development agencies and theme / plugin authors. "Gutenberg is open source, so figure it out yourselves" is irresponsible.

2. Gutenberg is awesome. I love the interface, the visual design, and I do think this is the way of the future in terms of editing content. But it is far behind where it needs to be in order to consider it for a 4.9 or 5.0 release.

3. Everything I should be able to do in legacy is everything I should be able to do in Gutenberg.

4. Screen options
5. Meta Boxes (ACF, Yoast, etc)
6. Permalinks?! I can't even begin to understand why this isn't editable in 1.0 yet
7. Classic content block does NOT load properly in localhost environments
8. Documentation MUST be key in order to create different style blocks. Give several examples, several use cases. Not every theme developer is backend, so don't assume. Be crystal clear
9. Block settings need work. It is very difficult to tell what settings are available per block. Seems random. When do I need to edit block settings vs when do I not?
10. The whole comment tags around Gutenberg text editor is ... sad to see.

Some of us are getting extremely frustrated with this process. It should be a dead simple answer.

Will Gutenberg protect the current use of metaboxes / ACF, and are there plans in place to ensure such support indefinitely?

We don't need to know what the solution is right now - we know you're figuring it out. But we still don't have a CLEAR answer on this. ACF in particular needs to work the same exact way it always has to support older clients that will NOT agree to being charged to update - especially when discussing removing legacy editor at some point (how can you even begin to have that conversation right now?!)

Love Gutenberg. But I have to join the choir - this is getting ridiculous. The way the project team has communicated this expectation has not been simple. Yes or no is all we are looking for.

@BE-Webdesign

when it is complete, will introduce the almighty meta boxes back in

Can I therefore suggest that you write an entire post on this very issue, that you HAVE in fact indicated, that meta boxes, as they are now, are going to stay please. This would prevent a lot of worried developers in the community who are worried about their businesses.

Additionally I would encourage the team to make this a priority to add these in now. This would prevent a lot of the negativity around the project I am sure.

As stated in #2308, I copied the hooks that Meta Box plugin uses when creating/saving custom fields:

• Scripts, styles are enqueued using admin_enqueue_scripts. We do check for the current screen (via get_current_screen) to make sure scripts and styles are enqueued only for that pages. For the core plugin, it checks by post types. For extensions (term meta, user meta, settings page), it checks more for taxonomies, user profile page or settings pages.
• We also use print_media_templates to print Underscore templates.
• Scripts we use in the plugin includes: color picker, underscore, backbone, media scripts, tinymce (for the editor field)
• We use init to initialize all the hooks for the plugin.
• Meta boxes are registered using add_meta_boxes hooks.
• Hidden meta boxes use default_hidden_meta_boxes.
• We also hook to post_edit_form_tag to allow upload files.
• We use save_post_{$post_type} and edit_attachment, add_attachment to save meta values for posts and attachments.

What's wrong with building out hooks to display metaboxes above/below/sidebar of Gutenberg?

Figured I might as well do what third-party developers do best, and throw another massive wrench in the works.

Mattias tells us that metaboxes can be reimagined as blocks that store to post_meta. If that is a goal for merge, then there are some issues to iron out:

Many metaboxes register the_editor($custom_id); for this to be supported in the context of Gutenberg, either an interface and api for creating nested blocks is necessary from day one, or we are saying that metaboxes can only have the second-class editor interface, without any of the benefits of blocks. This will be particularly problematic for the large number of agencies that currently design using ACF Flexible Layouts, as they will need a way to create separate Gutenberg blocks for various contexts and areas. Even "thinking in blocks" I don't see a good way to solve the "content-area followed by template part followed by content area" issue without supporting nesting in "metablocks" from day one.

Stemming from that, is the technical concern of nesting with regard to blocks that are not stored in post_content. Mattias says blocks will be able to store to postmeta, but if a block can define where it is stored, how will nesting work, when a parent block stores to postmeta, and the user adds a child that stores to a different post_meta... (Or in the pathological case, a nested block Tha stores to postmeta contains a block that stores to the same postmeta field.

This leads to a third metabox concern. If Gutenberg is a full edit page replacement, rather than a replacement for the_editor(), how will people be able to enqueue and use blocks on other pages and in other contexts, such as metaboxes or custom admin panels that use the_editor(). It appears at first glance that the answer will be "they can't". Which leads to some serious concerns as to whether Gutenberg adds flexibility to custom CMS implementations, or takes it away.

If users are given the option of Gutenberg, and it is as revolutionary for them as claimed, not being able to provide that new interface in these instances could prove disastrous for agencies.

There is no straightforward answer to the future support of existing metaboxes.

I've said repeatedly we are going to account for meta-boxes. The only uncertainty is what is technically viable and how it will be displayed in the new UI.

We are not attempting to break anything—shortcodes, custom fields, etc—all should still work. The UI to interact with them might change (unless you disable Gutenberg completely), and certain use cases for meta-boxes are going to be a better fit for blocks going forwards.

Gutenberg is awesome. I love the interface, the visual design, and I do think this is the way of the future in terms of editing content.

I'm glad to hear!

Permalinks?! I can't even begin to understand why this isn't editable in 1.0 yet

Because the REST API doesn't support this yet. Any help is welcome: https://github.com/WordPress/gutenberg/issues/1285

I've said repeatedly we are going to account for meta-boxes.

@mtias I think the confusion regarding support of meta boxes results from @m suggesting that a legacy plugin will be available to restore existing functionality. It would be helpful to clarify what aspects of the existing interface (meta boxes, meta box positions, hooks, etc.) will continue to work with Gutenberg versus which aspects require the legacy plugin to continue working.

I've said repeatedly we are going to account for meta-boxes.

@mtias my apologies, I must have missed your clarification elsewhere. Glad to hear! Make the current iteration visually more appealing and purposeful and it'll be a huge success.

I understand what you're saying about REST API support, I will watch the thread for updates.

Thank you for clarifying. Now that I have this insight I am full speed ahead for Gutenberg - all my fears are set aside.

@kevinwhoffman right, I think the heart of the issue is that "existing functionality" includes the presentation as well—and since Gutenberg significantly changes the UI getting back to the previous one would require the plugin to disable. How meta-boxes fit in the new UI and how old meta-boxes can be supported without developer intervention are the things being worked on. I don't know exactly how that will work out, so I haven't been able to promise a specific outcome. I also think this could end up in a clearer presentation of meta-boxes features.

@brograhamer no apology needed, it's a large thread! We don't want to rush anything, and this is a pretty big project with many moving parts. At times some things may seem neglected, but that doesn't mean we are not planning on solving them.

I'm currently building a web app using ACF with 10 custom post types which don't use the tinymce editor. I'm using the Title feature and about 15 ACF fields on average for each CPT.
Currently you can declare which features (i.e editor, thumbnail, excerpt, etc) a CPT supports.
Will it be possible to hide/remove the "Write your story" paragraph block as well as the "Insert block" icon from the edit screen?

@cr101 I think we if you drop the "editor" from your CPT supports, we should probably drop the block inserter and the blocks from Gutenberg, seems logical to me.

On the other hand, with the v1 of metaboxes, the metaboxes panes can be expanded from the bottom, if we keep this, we should ensure that it's always "open" for CPTs without "editor" supports. It might not be necessary if the metaboxes are always shown under the editor (like some of the design suggestions above)

I'm not sure if this is the right place for this, but what about the core custom meta fields? There's been a lot of talk about third-party plugins but what about the core custom meta fields. I know it those aren't really that popular but I can think of a few sites I've worked on that use them.

Is there any plan in place for integrating the core custom meta fields into Gutenberg?

Hi @jawittdesigns,

I am pretty sure the core metaboxes ( at least most of them ) have been re-implemented already in Gutenberg! They feature some nicer work flows around handling taxonomies etc.

Not everyone uses WordPress for blogging. A lot of us use WordPress as a CMS. We are currently building a web app using the WordPress REST API and ACF. We have 10 custom post types and each CPT has 20 custom fields and all the CPTs are linked to each other via bidirectional relationships using ACF Relationship and Post Object fields and the ACF Post-2-Post plugin.

Gutenberg is of no use to us in its current form since we don't even use the current editor. We are only using the Title textbox for our CPTs and the rest is custom fields which get stored in post_meta table.

I strongly believe that the Gutenberg editor should not become part of core in its' current state. I recognize that WordPress as a project needs to play somewhat to those site builders who do not work with their own custom themes … however the Gutenberg editor seems to be a direct attack on those of us who use Advanced Custom Fields to make complex entry of content fairly “idiot proof” for site owners by giving them a very specific way to enter their content. The Gutenberg editor in its' current state seems to be a direct attack on those of us who use ACF.
With the Gutenberg plugin the edit link in the header sends the user directly into the Gutenberg interface which does not show ANY of the ACF meta-boxes, and has no screen options tab at the top of the screen to activate them. Yes the user can go back to the page/post array and choose the “classic editor” option and then see the meta-boxes but this means that an extra step needs to be taken by the site editor to get to the ACF fields. Not exactly optimal considering that the goal of using ACF in many cases was to make editing of complex layouts more fluid and straight-forward for a non-technical editor.

What a long running issue this has been!

With the merge of #3345 and #3554, meta box support is at a state we're happy to call _feature complete_. Note that this is different from _complete_, as there's obviously still work to be done on polishing the meta box experience, particularly around styling, more complex JavaScript handling, and determining rules for falling back to the classic editor.

Thank you to every who has constructively participated in this issue, I do understand it's been a difficult, and occasionally controversial process. For a documentation on how Gutenberg handles meta boxes, and how you (if you prefer) can mark meta boxes as being incompatible with Gutenberg, please see the handbook.

If you run into bugs associated with particular plugins or meta boxes, please open a new issue, so it can be tracked correctly, and fixed.

With respect, this should be far from feature complete.

@coffeeneed If you'd like to be constructive, please open a new issue with sufficient detail for us to assist. Thanks