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.

10 Comments


  1. Nice summary and good reporting. Thanks.

    Perhaps Tom Nowell’s idea will pan out? Otherwise, I think there is a good argument to be made for a slower approach, along the lines suggested by Yoast, of only replacing the classic editor with the Gutenberg editor and not trying to shoot the moon on the first release. Such would allow a release sooner and get feedback / real-world usage of blocks for editing. It seems like we have been, as regards metaboxes, at the same place that we were back in the summer.

    Report

    Reply

  2. “What some people have called as the pragmatic approach is not concomitant with the design direction this project has had from the start….

    Translation: No. We don’t want to.

    #sigh. I think the team needs to consider the next 5+ years, not just the next 1-2. If it takes, say, 2 or even 3 years to get the full vision implemented then in we end up at the same point but with far less disruption to the community of people who use WP to deliver real solutions to our clients and to those clients. I’m still worried that they don’t really understand how prevalent metabox use is and that while we’ll have a solution that works for creating new sites with them, we will see breakage in existing sites. Worse, for decision-making in the near and medium term is that I can’t be sure we’ll have backward compatibility with existing solutions which makes it hard to plan for the next 3-6 months.

    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.

    It’s the team’s responsibility to communicate that vision out and to do so clearly. If we aren’t ‘grasping the vision’ the team can blame the community… or consider their communications.

    I love the idea of Mor10 to have a roadmap but again, why does it take someone from outside the team to create a ticket that asks the team to *deliver a freaking roadmap*? That’s a basic communication tool.

    Report

    Reply

    1. I think that Automattic is both good and not that good for Gutenberg.

      It’s good because it provides the ressources, developers and passion around this project. Things we should be thankful about.

      And less good, because the developers being from Automattic are somewhat biased regarding the importance of MetaBoxes. They do understand they are important but I feel like they fail to realize just how vital they became in WordPress. At Automattic, WordPress.com is a blogging platform and metaboxes are dispensable, but WordPress (SelfHosted) is mainly used as a CMS and as such, it can’t live without MetaBoxes.

      I’m still worried that they don’t really understand how prevalent metabox use is

      Report

      Reply

  3. Collaborators on the project have grown impatient with the community for not grasping the vision

    Yes, we who develop sites which make extensive use of meta data are too thick to see the greatness of Gutenberg and to understand why a crucial feature in CMS type sites like post meta is suddenly “locking the evolution” of WP. Please, core devs, enlighten us.

    Report

    Reply

  4. the design direction this project has had from the start — heading towards full site customization

    So the goal of the Gutenberg project is to replace the whole admin and swallow up the Customizer as well?

    Report

    Reply

    1. That is what I have noticed. WP seems to be trying to move the whole admin into the customizer. I remember just a few years ago WP wanted theme authors to start using the customizer instead of custom option pages; thought this is what the customizer was to be used for…active theme options/settings. Apparently not anymore, now they want everything crammed into it.

      Report

      Reply

  5. So… we have this massive revamp of the editor screen (not a bad thing), but we’re willing to make breaking changes for themes/plugins. If that’s the new approach of WordPress, can we PLEASE update the minimum PHP version then? I’d be so happy to accept this breaking change, if that one is forced for WP 5.0. ;)

    Report

    Reply

    1. Heck yeah. If breaking changes are the new norm then I’d accept Gutenberg and all it’s warts if the minimum required PHP version was updated to v7.0 for v5 of WP. If you don’t want to use Gutenberg and/or run an older version of PHP even as recent as v5.6 then you can just stay on WP v4.9 like so many are already planning to do anyhow.

      Report

      Reply

  6. I wanted to echo the comments of many, who like myself have built WordPress sites for clients large and small over the last few years. I have serious concerns, and like Morten has pointed out – there is no one suitable place to express them.

    I have embraced meta-boxes big time right from the start, as they offered an extremely flexible way of storing extra information relevant to a page or post, or any custom post type that I cared to define.

    Some of the information in the meta boxes will ultimately appear on screen when someone visits a site, but it may appear in different ways depending on the context. Other meta data can just be used for deciding which posts to show in a given WP_query, or even for sorting too – although I know that’s perhaps not the most efficient use. But WP_query has params to support that – so it’s obviously not just me…

    My sense of foreboding and concern comes from what happens when WP version 5 with Gutenberg is released. From what I’ve gleaned from the diverse sources of information and gossip, I wouldn’t be surprised if pretty much all the sites I’ve built will either break or stop being maintainable, without some serious amount of redevelopment work.

    This will create a lot of pain for the small businesses and charities I’ve built sites for. Even though I no longer have them as clients any more, they will probably approach me to express their frustration. Even more so when they hear that substantial rework of their site may be required – they, and I, will wonder just who is supposed to pay for that.

    I want to think that the Gutenberg team will deliver a great editor when it’s all finished, and I’m sure it will make building new sites easier. But please, don’t overlook all the existing WP sites.

    Maybe we need a central repository where people can share all the different ways they use meta-data, and where the Gutenberg team can understand how they need to accommodate those different ways.

    Report

    Reply

    1. Since nearly everyone will likely be in the same boat if v5 launches without proper metabox support, it could be an opportunity for an maintenance upsell. It won’t matter whether they’re a charity, non-profit, etc or not. WP.Org will have made the choice for everyone which while not very democratic is the way things are heading lately.

      Anyone in the industry that they go to (even if they don’t necessarily come back / choose to work with you again) will then have the choice to eat the cost of the work performed (in return for example, a maintenance contract) or a simple quote of the job cost.

      They’ll also have the option to leave the WordPress platform, etc if the scope of the work is comparable than what it might cost to redo the site another way or with another platform.

      Report

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *