A lively and productive discussion regarding Gutenberg’s use of iframes for meta boxes is happening on GitHub. Yesterday, WordPress developer Kevin Hoffman created an issue titled “Are iframes a viable long-term solution for meta boxes?”
Gutenberg 1.5 introduced initial support for meta boxes. Hoffman identified several issues with iframes that have been popping up as developers have begun testing the current meta box implementation. He did some performance testing that revealed Gutenberg’s use of iframes triples the number of asset requests, as it enqueues all of the CSS and JS assets in the parent window as well as in all the iframes.
“Generally speaking, iframes have been discouraged in web development for many years for reasons that are well-documented,” Hoffman said, before citing a litany of issues that plugin developers have already discovered in testing Gutenberg’s meta box support. “Can these issues be addressed without requiring modification of the theme or plugin that generates the meta box? We have to consider that third-party code that has powered meta boxes for years may not have the luxury of being updated in order to be compatible within an iframe.”
Gutenberg design lead Tammie Lister responded to Hoffman’s concerns, indicating that the current implementation of meta boxes is simply an experiment and not necessarily what would land in WordPress 5.0:
It’s good to think a little that what we have today for meta boxes in Gutenberg is an experiment, in many respects it’s a holding pattern as the project works out the direction to take. In saying that it’s one that works ‘for now’ but isn’t what we would ship with.
All the above said, I think it’s important to look at what in the future metaboxes will be used for. What are the cases (if any) that would not be converted to blocks? Do all metaboxes have to work on mobile? Is there even an alternative interface that we haven’t explored? I bet there is. Right now, it’s about looking at those possibilities and getting on a road that works for the state right now and the future state.
The presentation of this implementation as an experiment that “works for now” (but would not be shipped) comes as a surprise after Gutenberg 1.5 arrived with the announcement that “this release includes long awaited meta-boxes support (needs testing!)”
Hoffman contends that the iframe approach doesn’t even work ‘for now,’ as the issue was opened in order to cite several major ways where it is broken. If Gutenberg moves forward with the current approach, it would require many plugins to be modified in order to be compatible with WordPress 5.0, which Hoffman said would defeat the whole purpose of supporting legacy meta boxes.
“I have not seen any evidence to date that suggests meta boxes will continue working with Gutenberg,” Hoffman said. “If the answer is no, then we ought to stop pretending that 5.0 will be just another WordPress release and start being honest about breaking backwards compatibility.”
Edwin Cromley, a collaborator on the project, said that the team anticipates that certain themes and plugins will be broken and that it is not possible to accommodate every possible use case. He admitted that the iframe solution may not meet the project’s goals. Instead, he advocates creating the best experience for the vast majority of users.
However, the current approach would adversely affect many sites out there that use WordPress primarily as a CMS with meta boxes. WordPress core committer Scott Taylor expressed concerns about custom post types, many of which do not make use of the traditional “content” section in favor of meta boxes only.
“In this current iteration, meta box support is an add-on, when in many people’s reality, meta boxes ARE the UI, the API, the mechanism they use to compose their CMS,” Taylor said. “iframes are the gulag.
“And we are forgetting the values WP has been built on forever: I should be able to update to the latest version of WP, and have to rewrite nothing. I have so many projects in the wild on WP that I will never touch again. Can I be confident that some of them won’t break wildly with this change?”
Hoffman advocated scaling back the scope of the project to focus on the editor component, a popular opinion that many plugin developers share and one that was illustrated in detail in Yoast’s post proposing an alternative approach to Gutenberg. This approach stages out the changes to the edit screen, giving developers more time to update their plugins, as well as allowing the Gutenberg team to find an adequate solution for meta boxes.
“I think that goal would be a lot more achievable if Gutenberg stuck to overhauling the editor rather than taking over the entire page,” Hoffman said. “Then we could leave the existing hooks in place and meta boxes could continue to communicate with each other as they do now. Also, asset enqueuing would be a non-issue since it would work as it does today.
“I’m in strong agreement with this concept put forth by Yoast, which seems to me like it would maintain much of the work already done while scaling back the scope of the project to focus on the editor component.”
Gutenberg engineer Riad Benguella indicated the team is not too keen on working towards this concept.
“Reusing Gutenberg pieces to build this concept is relatively doable, but this is not the UX we want to optimize for, we want to build the best possible editor first and make it available for people without backwards compatibility concerns (fresh installs, no metaboxes…),” Benguella said.
“When we think the ideal vision of Gutenberg is ready to ship, we’ll have time to discuss upgrade path strategies, a concept like this one is an option for an upgrade path, but definitely not as the final product. Other upgrade paths are also possible.”
The WordPress developer community is not, however, in favor of delaying this discussion once again. Many are eager to finally answer the question of how meta boxes will fit into the context of the Gutenberg editor so they know how to prepare. Given the numerous issues with the iframes approach, rendering legacy PHP meta boxes under the new editor will require more experimentation and possibly an alternative solution.
“Why devote thousands of hours into developing the ideal editor if it cannot be made compatible with existing sites?” Hoffman said. “If the first impression is that it breaks the UI they depend on, users will never experience the ideal editor in the first place.”
“I think it may be a mistake to put this off too far,” WordPress core committer Aaron Jorbin said. “Especially since many organizations are going to need at least 1-2 quarters to prepare.”
Mark Kaplun suggests the Gutenberg team use a popular plugin as a gauge for the success of current and future meta box support experiments.
“My productive suggestion, is to not declare meta boxes ready, as long as Yoast SEO does not properly work in it,” Kaplun said. “It is both slightly complex in terms of interactions and it is installed on shit loads of sites. If Gutenberg cannot work with it, probably no one is going to use it.”
Greg Schoppe, who has tested and written extensively on Gutenberg’s ongoing development, joined the conversation to advocate for Yoast’s alternative approach to the project as well.
“I highly support Yoast’s view of Gutenberg,” Schoppe said. “It is unclear to me how ‘upgrade the visual editor’ was reinterpreted to be ‘replace the entire post edit interface’ by the Gutenberg team, but it seems directly at odds with the so-called ‘Ship of Theseus.’
“In this case, the lack of clear direction and support for the existing standard workflows is actively hurting developers now. How can I move forward building a project, without a trusted set of hooks and tools that I can rely on? It is unconscionable to think that such a large software project would entirely upend the standard workflow for developers in a single update. and it is insane that these conversations are just happening now, in November, when the plan is to have a merge approved at the beginning of the year.”
The discussion regarding the iframes approach to meta boxes was opened yesterday is still relatively new, but so far the Gutenberg team’s responses have failed to adequately address the concerns of the developer community in this thread. Finding an approach to meta boxes that preserves WordPress’ powerful CMS capabilities, without alienating users and developers, is one of the Gutenberg team’s greatest challenges. They are still aiming at producing a merge proposal early next year, but with meta boxes still in the experimentation stage, the team’s anticipated timetable continues to put the project at odds with the WordPress developer community.
Agree, but please do not use one single plugin like Yoast SEO as a gauge as it does not focus on creating data, instead select a number of plugins that cover different use cases and are implemented differently.
For example ACF (Free + Pro) should be a strong candidate (completly broken now), also plugins for creating multilingual sites or supporting custom workflows.