Solvedgutenberg Supporting Metaboxes

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:

post settings

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

33 Answers

✔️Accepted Answer

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.

Other Answers:

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

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.

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.

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

More Issues: