WPTavern: Gutenberg Development Team Confirms Meta Box API Will Not be Formally Deprecated
The discussion surrounding how Gutenberg will handle meta boxes heated up over the weekend after a participant commented on the GitHub issue with concern regarding meta box support being removed from the most recent milestone.
“I see this vital issue has been removed from any milestone,” @steveangstrom said. “It has been de-prioritized again while bells and whistles for blog editing get lots of work and are added to betas. This is very worrying for the future of WordPress as a CMS.”
James Nylen, one of the lead developers on the project, reassured followers of the topic that the Gutenberg team has not forgotten about the issue but rather that it is “an extremely complicated issue that we are only beginning to look into, along with many, many other priorities for getting the editor working well.” He also asked for help from the community in planning and testing implementations for supporting meta boxes.
This response left many things unclear. Participants in the discussion, many of whom are developers concerned about about the prospect of having to rewrite all of their meta boxes as React components, are wondering why meta boxes cannot work alongside the new Gutenberg editor and why the team chose to include meta boxes in the scope of the project.
“Is it possible to replace the existing TinyMCE post editor with Gutenberg while leaving the rest of the interface, including meta boxes and existing hooks, unchanged?” Kevin Hoffman asked. When Nylen clarified that Gutenberg, as written today, is intended to be a post_content editor, Hoffman summarized the concerns that many developers have expressed:
If Gutenberg is truly intended to be a
post_contenteditor, then meta boxes should be left alone as they are not concerned withpost_content.Furthermore the need for an API to translate PHP meta boxes into React meta boxes is a manufactured problem. It does not have to be a problem, but it has become a problem because somewhere along the line it was decided that rewriting the
post_contenteditor should also completely change how meta boxes work.You’ve outlined the tremendous challenge of writing such an API in #2251. Translating PHP meta boxes into React for a popular custom fields solution like ACF is challenging enough, let alone trying to do so for every meta box implementation that exists today, popular or not. It does not scale.
As the Gutenberg contributors shared that they have only just begun to look into the meta box issue, it’s now clear why there is no roadmap for how the project will handle “legacy” PHP meta boxes. In July, Nylen said, “If I had to guess where we will end up here: current metaboxes will be moved to a “legacy” area and we will provide APIs, documentation, and examples for registering ‘new-style’ metabox-block-thingies.”
Plugin developers who manage meta box libraries, agencies, and other concerned parties are following the ticket to find out how to plan for the WordPress 5.0, which has been targeted as the Gutenberg release. Andrey Savchenko asked if WordPress plans to formally deprecate the meta box API, which finally drew a clear answer from the team. Matias Ventura responded:
“Does WordPress intend to formally deprecate Metabox API?”
No.The question that is not fully answered yet is how do meta-boxes work in the context of the Gutenberg editor. Should they remain the same or evolve? How can we move towards the design goals with the least amount of disruption possible?
This issue has been lingering not due to a lack of desire, but lack of resources. The primary focus for this project is to offer a rich content editing interface that optimizes for direct manipulation of user content through the notion of blocks. (Having used meta-boxes extensively for various projects, I believe blocks can offer a better step forwards for many of those needs while providing a better user experience.)”
Ventura listed several options the team has considered for handling meta boxes and requested help from the community to build the best solution:
- If we detect a meta-box is registered we can fallback to the old interface, nothing changes.
- We could split editing the content and modifying meta information into two screens or stages.
- We can try to see how feasible it is to render these as they are (PHP) below the content: #2251.
- A theme/plugin/CPT could unregister the new interface as needed.
- Various items that relied on meta boxes could be converted to blocks for UI (still storing data separately).
- We could implement API based meta boxes extensibility like the Fields API.
When pressed to answer the question of why meta boxes are being included in the context of the new editor, Gutenberg design lead Joen Asmussen clarified how the team decided to include meta boxes in the scope of the project:
Gutenberg did start just with the editor box. The kickoff goal was to unify multiple disparate interfaces under a single unified block interface. It quickly become apparent that in order for us to create a compelling experience revolving around this unified block interface, we had to consider the full writing flow, including settings and publishing.
If the key strength of WordPress is to make it easy for anyone to create rich posts, then we can’t just design for those of us who already know how to use the editor. We have to consider users who’ve never used WordPress before, and what they expect in a modern publishing interface. Otherwise we’d just be adding cognitive load to an already heavy interface.
The question of how meta boxes will fit into the context of the Gutenberg editor is still open. Participants in the discussion are eager to have this question answered for the sake of backwards compatibility and also because it affects ongoing decisions regarding Gutenberg development and screen design.
“I completely get how much work has been done towards the ‘screen’ replacement approach,” Xavi Ivars commented on the issue. “But shouldn’t a project that started with the goal of a ‘post content editor’ replacement, have gone back to the community before deciding unilaterally that it would replace the whole editor screen?”
The meta box API isn’t being deprecated but there’s also no clear path forward for how Gutenberg will support “legacy” PHP meta boxes. The Gutenberg team said the issue has not been solved due to lack of resources. The project needs community input and better communication if the team is going to land on a solution that will seamlessly usher the majority of WordPress sites into the Gutenberg era with the least amount of breakage.
Currently, the feasibility of rendering legacy PHP meta boxes below the content is fraught with challenges and still up for debate. If there isn’t enough time or client resources for developers to rewrite their work into JS-driven meta boxes, then a clear path for opting out of the Gutenberg interface may be necessary for sites that need to preserve the legacy “PHP” meta boxes.
Source: WordPress
