WPTavern: Gutenberg Contributors Explore Alternative to Using iframes for Meta Boxes
The discussion surrounding the use of iframes for meta boxes in Gutenberg became more heated over the weekend, as concerned developers implored the team to consider the detriments of the current approach. Responses from Gutenberg’s leadership initially deflected concerns, presenting the iframe implementation as an experiment that “works ‘for now’” but isn’t what the team would ship.
Instead of getting a response to the specific concerns about performance and accessibility of the iframes approach, Kevin Hoffman was urged to think about the future of meta boxes and “the cases (if any) that would not be converted to blocks.” When the developer community is repeatedly asked to test and offer feedback but is met with deflection on issues that are critical to sites using WordPress as a CMS, the GitHub discussions begin to get more heated.
“People are worried, and getting frustrated and it seems to me that they have every right to do so because the perception is that the team working on Gutenberg has little understanding of how meta boxes are being used, little concern for what the impact will be, and is going to move forward with their vision no matter what,” Jimmy Smutek, lead developer at the office of external affairs at Johns Hopkins, said in response to a Gutenberg collaborators’ admission to having been dismissive of feedback.
After several rounds of developers joining the thread to debunk the notion that iframes for meta boxes “work for now,” Gutenberg lead developer Matias Ventura joined the discussion yesterday and confirmed that the experiment is likely to be dropped fairly soon.
“I’m glad the conversation refocused in the end to the topic’s issue: is the current approach to meta-boxes in an iframe viable? With the answer being no,” Ventura said. “The iframes are an implementation detail I think we can drop relatively easy. So let’s focus on that.”
He also addressed the popular opinion that WordPress should make iterative enhancements to the editor itself (and not the full page) before proceeding with overhauling meta boxes.
“What some people have called as the pragmatic approach is not concomitant with the design direction this project has had from the start — heading towards full site customization — and what has dictated our decisions so far,” Ventura said. “Nothing here has to be a final solution, we are exploring what is possible within the design premises and putting it out there for testing.”
Ventura said that not making changes to the other aspects of the edit screen would certainly be the simplest path for Gutenberg to take but that it “would not be fair to the goals of the project and the long term users of WordPress.”
WordPress developer Gary Jones contended that pursuing a more iterative approach would not change the goals of the project but would make it possible for more sites to come along during the process.
“Going one step at a time does not, in any way, compromise the goals of the project,” Jones said. “You can still head to full-size customization if that’s the goal, but by doing it in a stepped way, you’ll bring the rest of the developer community along with you.” Jones cited the Customizer as an example of a feature within WordPress with a concept that is being realized over time with many iterations.
Ventura responded with clarification on the Gutenberg team’s approach to iterating on the project, a paradigm shift that supports block-based content creation from the outset.
“We have proposed a staged approach, from Matt’s original new focuses post, it just considers the steps differently,” Ventura said. “There are generally three stages for the Gutenberg project: from the post editor, to page templates, to site building. What is primordial is that the paradigm is one where the content is a single area, with the block as the primary concept, and where the outcome can be visually represented with clarity and without excessive abstractions.”
Ventura also assured those following along on the discussion that the project will not be dropping support for meta boxes but needs more time to experiment with different interface options.
“WordPress always moves with the user, and we take the burden of figuring out development paths to ease transitions for our existing code,” he said. “As a project, we have said before that we were not dropping support for meta-boxes from WordPress, but also that we had to explore what interface decisions we would have to make within the new paradigm, including the possibility of loading the classic editor when we detect meta-boxes we cannot handle or that directly conflict with an editor that seeks to more clearly delineate what is content and what is meta-data.”
He also said the team plans to create more mechanisms to handle incompatibilities as well as “allowing more things to be opt-in (say if you are comfortable with your meta-boxes showing in Gutenberg you could declare support for it, or vice versa.”
A new approach to rendering meta boxes without using iframes is currently underway. Riad Benguella has created a pull request that attempts to undo the iframes and implement a suggestion that Tom Nowell offered during the discussion:
Instead of loading Gutenberg on a settings page, lets load it into the main classic editors page, load metaboxes in their native environment, then hoist their container DOM node into a component via JS.
We then use a different kind of toggle to make sure the classic editor can still be used. This way:
– we avoid the iframe nonsense
– metaboxes work as they always have done as far as registration is concerned
– the existing JS works as expected, and no hacks are necessary to make things work on the PHP end
The new approach has the advantage of no problems with links, modals, duplicate stylesheets, and the other drawbacks to using iframes.
The Gutenberg Team Needs a New Communication Strategy
The discussion regarding the long-term viability of using iframes for meta boxes has highlighted a lack of a unified message or communication strategy among Gutenberg leads. Collaborators on the project have grown impatient with the community for not grasping the vision, but communication is scattered across various blogs, comments, Slack channels, and GitHub discussions.
Morten Rand-Hendriksen has opened a new issue requesting a centralized resource that can serve as a plain language outline of Gutenberg’s scope, direction, and goals.
“My observation is the community is struggling to see the wider scope of the Gutenberg project due to lack of a single authoritative plain language resource containing this information,” Rand-Hendriksen said. “This creates a high degree of speculation, miscommunication, and frustration from all parties and the project suffers as a consequence.”
Gutenberg does have a documentation hub, but so far those documents are more technical and lack a practical roadmap for how the team is aiming to accomplish its goals. The FAQ section of the current docs is the closest thing to the plain language resource that Rand-Hendriksen is requesting in his ticket. The readme.txt files for both Gutenberg’s GitHub repository and the WordPress.org plugin give the impression that the project is simply updating the current editor to be block-based, not overhauling the entire editor screen.
“Due to the fractured nature of this information it is challenging for anyone to get a clear picture of the entire project, and though Matias and Matt’s posts do a good job at explaining the grand vision of the project, they lack concrete plain language breakdowns of the essentials the community need to get a firm understanding of what this project is and where it’s headed,” Rand-Hendriksen said. “They also exist as independent satellites of information circling the project rather than core parts of the project itself.”
The community is chiming in on the GitHub issue with questions they would like to see answered in a more transparent plain language product roadmap. A document like this might help the Gutenberg team to better communicate the goals of the project and avoid sending mixed messages that cause unnecessary confusion.
Source: WordPress
