Supporting Metaboxes

[jasmussen]

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

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

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

[androb]

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

[jasmussen]

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

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

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

[westonruter]

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

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

[braders]

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

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

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

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

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

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

[hedgefield]

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

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

[jasmussen]

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

[brentjett]

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

[jasmussen]

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

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

[kevinwhoffman]

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

[davisshaver]

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

Really important feature for the top of market!

[nylen]

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

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

[Shelob9]

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

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

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

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

Here are my technical concerns:

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

[westonruter]

@Shelob9 hi!

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

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

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

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

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

[buzztone]

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

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

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

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

[brograhamer]

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

[wpmark]

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

[rilwis]

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.

[jackonawalk]

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

[gschoppe]

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.

[mtias]

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

[kevinwhoffman]

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.

[brograhamer]

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.

[mtias]

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

[cr101]

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?

[youknowriad]

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

[JAW-Dev]

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?

[BE-Webdesign]

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.

[cr101]

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.

[plasterdog]

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.

[pento]

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.

[coffeeneed]

With respect, this should be far from feature complete.

[danielbachhuber]

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