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

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

Edit: This ticket has been rephrased to add a little clarity. Metaboxes are here to stay. See also #952 (comment)

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: Automattic/wp-calypso#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: #1288 (comment)

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

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

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

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

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

@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 (elliotcondon/acf#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.

• Screen options
• Meta Boxes (ACF, Yoast, etc)
• Permalinks?! I can't even begin to understand why this isn't editable in 1.0 yet
• Classic content block does NOT load properly in localhost environments
• 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
• 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?
• 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: #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.