What is the future of Meta Boxes in WordPress?

You can create custom blocks for custom post types quite easily using Advanced Custom Fields Pro.

• This reply was modified 3 years, 6 months ago by Steven Stern (sterndata).

@sterndata Thanks for your answer, but I think it’s not answering the actual question.

Custom Blocks are not a substitute for Metaboxes. With meta boxes you can handle CPT attributes like for a example a custom status, a control date, an option from a list, or whatever. And then you can use those meta data to actually query things.

A Custom Block seems to be just a piece of aesthetic content. One may find a way to add/update meta fields via a Custom Block and some AJAX calls, but that is just complicating things that were already working before.

The real question is:

Gutenberg killed/replaced the TinyMCE editor. Fine. But: Is there any plan regarding the old way of handling meta boxes, which are not being faced at all by Gutenberg?

The settings boxes on the right of the main editor in the Block Editor (Gutenberg) are still meta boxes. You can add your own there with the right location argument (I don’t recall what it is, sorry). You can drag main meta boxes there through the UI, but there’s currently a bug where they cannot be dragged back. So the UI is a little wonky, but meta boxes are still an integral part.

I’m not sure what you mean by Multi Boxes. If that’s plugin functionality, that may very well no longer work.

@bcworkz Thanks, this gets closer to the answer I was looking for. Nevertheless, “pushing” the meta boxes to the sidebar is like… “hey let’s keep them there just to have them somewhere”, but it’s not a clean solution. It also takes away A LOT of the functionality they provided. It also somehow “kills” the way WordPress was heading towards being a generic CMS, rather than a Blog oriented CMS.

I will illustrate with a real example:

I developed a project for a client where there is a Custom Post Type called “Client”. Inside the Client CPT edit screen there are different editable areas (Custom Meta boxes). Some of those areas are big boxes that contain for example private messages with client, other boxes contain data about the client that can be modified with nice dropdowns, drag and drop, etc…

The thing is, this screen didn’t even need an editor. And now with the Gutenberg ecosystem, this was just pushed to the side, which really takes away the love for WordPress for this kind of projects.

So, the question:

Is there any plan on making metaboxes great again? In a way that they can occupy the whole screen, and in a way that the Gutenberg editor can be just disabled for certain custom post types without needing to hack the core with every update?

I would like to know this, so that I can make a long-term decision regarding the use of WP for future projects.

Thanks!

I’m unsure how we’d prevent the block editor from loading. You could at least hide it with admin CSS if it’s not needed.

You can still add meta boxes to the main area as we have in the past, using the “normal” context arg. For example, the default custom fields box still gets put there. Numerous custom field plugins do the same. You might look at one of those plugin’s source code for guidance if you continue to have trouble.

I cannot speak to future intentions of core development and meta boxes. There will always be a need for that kind of functionality. I’d expect similar functionality to always be available, even if it’s replaced by something beyond meta boxes. The soon to come Full Site Editing feature may play into what eventually happens with meta boxes.

Thanks @bcworkz, that’s a reasonable insight on the topic.

For more insight, consider the fact that Woocommerce itself DOES NOT use the Gutenberg editor screen fo its Product CPT. As of today, it still uses the good old interface.

Why?

Well, because there is a lot more to the Product CPT than just being able to “blockyly” design a product description.

• This reply was modified 3 years, 6 months ago by alvarofranz.

Indeed. For custom post types you can simply specify by omission the support for an editor. Then load the old tinyMCE editor into a meta box with the_editor(). It is for default pages and posts that I’m unsure of how to not use the editor. However, you can cause the tinyMCE editor to be loaded instead of the block editor by returning true from the ‘replace_editor’ filter. This can be an alternative to loading tinyMCE into a meta box.

I initially assumed you didn’t want any editor at all.

On the other hand, and since the topic of this is “the future”, see https://woocommerce.com/products/woocommerce-gutenberg-products-block/ and https://woocommerce.com/posts/making-it-easier-to-add-products-to-posts-and-pages-with-the-products-block-for-gutenberg/

@bcworkz Thanks again for the valuable information you provide.

@sterndata Thanks but I think the provided links are not relevant to the topic. I am talking about how to insert information into the database not about how to output it.

Of course Blocks are a nice substitute for shortcodes (which kind of is what Gutenberg is all about), but I was not talking about shortcodes.

I am talking about Meta Boxes. A Meta Box is not a Shortcode. In the case of Woocommerce Products, all those boxes that allow the user to INSERT organized data (post + post meta) into the database. That cannot be done with Gutenberg blocks.

But to conclude, as @bcworkz said:

I’d expect similar functionality to always be available, even if it’s replaced by something beyond meta boxes.