3. ...Gutenberg currently uses two separate iframes for the main column and sidebar. If we support meta boxes that appear after the Title, that would theoretically result in a third iframe. Will this present any issues regarding how plugins enqueue assets that must affect all iframed meta boxes?

I did some performance testing tonight, and I came across this discovery in my Network tab which is alarming. It appears that all of the CSS and JS assets that are enqueued in the parent window are also being enqueued in the main column iframe and sidebar iframe - meaning each asset is requested a total of three times, effectively tripling the number of asset requests when using Gutenberg.

The page weight damage is lessened with browser caching enabled, but the number of asset requests is still tripled. I assume this is being done so that each iframe has the assets it needs to allow the meta boxes to work, but surely this can't be the solution to enqueuing assets going forward.

Thanks for creating the issue and your insights @kevinwhoffman. It's good to think a little that what we have today for metaboxes 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.

Right now the bugs that exist with the current version of metaboxes in Gutenberg need to be fixed and that's a focus. Performance needs to come into this fixing. Mobile wise, metaboxes have long standing been an issue, we are not making it worse here. That said we should work for a better solution in the future. It's important to loop back and remember this is only a 'today' solution as we iterate and continue to be free to think of a better option.

It's good to think a little that what we have today for metaboxes 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.

The iframe approach does not work, not even just 'for now.' The related issues listed above provide examples of meta boxes not working in major ways. Furthermore, even if those issues were fixed, tripling the page weight and number of requests should not be deemed 'working' under any circumstances.

All the above said, I think it's important to look at what in the future metaboxes will be used for.

Respectfully, this happens every time the issue of meta boxes is brought up. Please, rather than shift the conversation to future meta blocks, it would be really helpful to frame this discussion around the issues facing existing meta boxes. Once again:

Can these issues be addressed without requiring modification of the theme or plugin that generates the meta box?

I have not seen any evidence to date that suggests meta boxes will continue working with Gutenberg. 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.

Hi Kevin,

Thank you for the detailed report. I think a lot of the issues can be touched up to a certain degree. This is also an exploration of whether the iframe approach will work, and how far it can be taken, so it is good to have this kind of dialogue and chronicle the shortcomings of this approach.

Is it possible to launch a content window from a meta box that extends beyond the iframe?

Do you mean like a modal lightbox that should take up the entire page?

Do you mean like a modal lightbox that should take up the entire page?

That would be one example, but I'm more so referring to any scenario where content needs to be revealed that is not within the confines of the iframe.

For example, can I click a button in the sidebar that triggers a content box in the center of the page? If that content box is inside the iframe, then it won't be visible outside the dimensions of the iframe in the sidebar.

The logical next step would be to instead call the function in the parent document from the iframe. But plugins are not currently written to work like that, and requiring them to be modified would defeat the whole purpose of supporting legacy meta boxes. I can't stress enough that whatever solution is decided upon needs to work without modification to existing themes or plugins.

Knowing how negatively the iFrame implementation is with regard to plugin/theme assets, I think this should give the project pause. The real answer here is WordPress shipping the Fields API https://github.com/sc0ttkclark/wordpress-fields-api -- without that, implementing metaboxes effectively with Gutenberg is virtually impossible if we care about performance at all.

If we really aren't shipping Gutenberg until it's "ready" then I say we should be putting equal attention to the Fields API so that metboxes work correctly and seamlessly with React in Gutenberg.

The logical next step would be to instead call the function in the parent document from the iframe. But plugins are not currently written to work like that, and requiring them to be modified would defeat the whole purpose of supporting legacy meta boxes. I can't stress enough that whatever solution is decided upon needs to work without modification to existing themes or plugins.

Yup, definitely a concern I had while doing this. Cross communication between iframes does not sound very good. There are other alternatives to explore as well.

There will definitely be cases however where certain themes plugins will be broken, and it is not possible to accommodate every possible use case, I think maybe a better goal is to create a good experience for the vast, vast majority of users, and use cases. It is entirely possible that the current iframe solution does not meet that goal.

It may be worth noting that in a recent Core Customizer Dev Note Post there was attention drawn to the removal of using an iframe as an improvement. It does seem like a step backwards to be implementing an iframe as a solution here.

Hi mathetos,

If we really aren't shipping Gutenberg until it's "ready" then I say we should be putting equal attention to the Fields API so that metboxes work correctly and seamlessly with React in Gutenberg.

I agree that a Fields API would be somewhat nice. However, that would also entail needing people to adopt the fields API. If not many are willing to rewrite their plugin/theme for Gutenberg, I don't think they would be willing to do so for a Fields API. I also think that was brought up in a previous issue somewhere, so I would recommend hunting that down in the GitHub history, and adding your thoughts on how the Fields API could benefit Gutenberg.

...it is not possible to accommodate every possible use case, I think maybe a better goal is to create a good experience for the vast, vast majority of users, and use cases.

I agree, and I think that goal would be a lot more achievable if Gutenberg stuck to overhauling the editor rather than taking over the entire page. 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.

Source: https://yoast.com/gutenberg-alternative-approach/

I also strongly agree with the proposal put forward by Yoast. It provides a good interim stage that provides plugin authors time to convert metaboxes to the new blocks. Then as a part of the plan for eventual replacement of the entire editor experience, WP as a project can say something like "In x versions, metaboxes will be deprecated" so we have a plan in place for moving towards a better end goal.

Just noting that this concept breaks existing metaboxes, because there's no central TinyMCE instance to communicate with. Instead of supporting 80% of metaboxes, this will support 90% (I made up these numbers).

This concept doesn't solve the backwards compatibility issue, but just delays its resolution to later with the same problem. Gutenberg is the first step towards JS interfaces in WP and it won't stop with Gutenberg.

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...).

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.

Let's build the best possible editor now.

When we think the ideal vision of Gutenberg is ready to ship, we'll have time to discuss upgrade path strategies...

I couldn't disagree with this more. Why devote thousands of hours into developing the ideal editor if it cannot be made compatible with existing sites? If the first impression is that it breaks the UI they depend on, users will never experience the ideal editor in the first place.

Why devote thousands of hours into developing the ideal editor if it cannot be made compatible with existing sites?

Just to be clear,

• it's impossible to be 100% compatible with exisiting websites no matter the option you choose for the editor because the plugins have full access to the DOM, any thing you modify in the dom is breaking backwards compatibiliy
• There's only one way to ensure 100% backwards compatibility for any change: Do not make the change. The plugin disabling Gutenberg is already available.
• The editor is already compatible with a huge number of websites. But like everything else, When it breaks, it's always more visible.

it's impossible to be 100% compatible with exisiting websites

Now that this is clear, let's build the editor we think is best for the future of WordPress please.

Do all metaboxes have to work on mobile?

Yes, why wouldn't they?

What are the cases (if any) that would not be converted to blocks?

For blog posts, I understand why Blocks For Everything might make sense, but this might be ignoring the general use-case for metadata: data which is unseen. Like, I may use a metabox to expose UI to add analytics data to a post.

For things like Custom Post Types, that might be composed of ONLY meta boxes, I have trouble making sense of the new UI. Because WordPress lacks a comprehensive CRUD API for data, a lot of developers use WP_Query and its suite of related API as a stand-in, and they use meta boxes on CPT edit screens to isolate UI for adding specific data or associations. Many (a majority) of custom post types in the wild de-emphasize or ignore the traditional use of "content" - so for blog posts, yes, Content is front and center, but for many CMS use cases, a WYSIWYG does not make a lot of sense.

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. <iframe>s 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?

I will end with this example: if one of my "old" meta boxes triggers the UI for Media to open, how will that work in this "new" scenario, from within an iframe, without someone (a client I no longer work with) rewriting the code?

As I've tracked along with these conversations, I can't help but feel that the powers-that-be which are developing and making the shots regarding Gutenberg don't use or deal with metaboxes themselves. It feels like an ends-justify-the-means sort of argument wherein its easy to say so because the means aren't significantly valued to begin with.

Please understand that for many of us we have dozens of sites that would instantly break when updated to WordPress 5.0 — a product that has historically taught people that it's safe to upgrade because its manic about backwards compatibility. What's being discussed here isn't a minor (e.g. styling) break, but a potential show stopper that would render the admin-side of thousands (or more) of sites instantly unusable. That's scary stuff. As an industry we've sold people on the rock-solid reliability of WordPress.

Like @staylor pointed out above, on the majority of our websites (mid-to-high end complexity corporate sites) the metaboxes are the UI. The editor (if used at all) is merely a part of it.

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.

I think it may be a mistake to put this off to far. Especially since many organizations are going to need at least 1-2 quarters to prepare.

There is an adage that I have heard from multiple lead developers of WordPress that I think is important to remember here: When someone adopts WordPress for their site, they aren't Adopting WordPress 3.7 or WordPress 4.8, they are adopting WordPress. Making this path forward as seamless as possible is absolutely a necessity. This will break things, and that's ok (There are back compatibility breaks just about every release of WordPress), but they need to be minimized, documented, and communicated.

it's impossible to be 100% compatible with exisiting websites

If you are not going to be compatible, than sure go and break things. Call the first release WP++ or WPNG. It is much better to declare in advance that things will most likely break and let people prepare for it. The current "deception" as if things will work as usual is bad for just everybody.

Iframes are dead end in terms of usability. Opened a jquery based date selection widget in a meta box, and was surprised when clicking at some other random place on the window did not close it. Took me a minute to realize that the click event was on the parent window and didn't propagate into the iframe. So I was surprised but got it in the end, but how are you going to explain such a thing to users? Do you expect each plugin to answer to each user's question about such trivial UX expectations.
And how do you expect external links to work?

There are great reasons why people use iframes only as last resort.

My productive suggestion, is to not declare meta box ready, as long as yoast seo do not properly work in it. It is both slightly complex in terms of interactions and it is installed on shit loads of sites. If gutenberg can not work with it, probably no one is going to use it.

My productive suggestion, is to not declare meta box ready

As pointed out by @karmatosed above: " It's good to think a little that what we have today for metaboxes 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."

To provide some real-world data I want to share this interface from a WordPress site I've worked on in the past. The content field is a minor part of this custom post type, and while some of the custom metabox fields could be converted to blocks, the majority contain data that is either used by the administrator, used by a 3rd party service through the REST API, or used to add metadata to the entry. While it may look a bit chaotic, this setup is designed specifically to work with the workflow of the client and uses a strict content model based on clear separation to ensure future versions of the site can handle each type of content independently.

Refactoring this site to work within the Gutenberg reality will take a long time and require substantial resources, so unless metaboxes are handled in a way that closely matches what already exists, this site owner will likely revert to a pre-Gutenberg version of WP and stay there for an indefinite length of time.

For reference, while this looks extensive, it is neither the most complex metabox setup I've built nor the most complex setup I've seen. What this example shows is the real-world workaround, via metaboxes, to meet the need for proper content modeling and separation beyond the content blob, something Gutenberg must handle gracefully and functionally.

Making this path forward as seamless as possible is absolutely a necessity.

Agreed

This will break things, and that's ok (There are back compatibility breaks just about every release of WordPress), but they need to be minimized, documented, and communicated.

Agreed

it's impossible to be 100% compatible with exisiting websites no matter the option you choose for the editor because the plugins have full access to the DOM, any thing you modify in the dom is breaking backwards compatibiliy

Agreed, I don't think anyone would disagree with you here. However, I think there's still room to discuss what gets broken and when it is broken. Those kind of decisions also impact what kind of work developers have to do to fix whatever is broken. There's a significant difference between adjusting things because dom selectors have been modified, vs having to rewrite a custom content model to fit the new Gutenberg paradigm where metaboxes only sorta work :) The contention around metaboxes indicates to me that it's something that probably isn't a good thing to target breaking in the initial release of Gutenberg in core.

I get that all of this is an experiment, I think @kevinwhoffman does too. I see this issue as a well thought out evaluation of this experiment and it should be taken as that. Will this experiment suffice as a final solution? No. So what's the next experiment?

I also don't think we'll see a huge uptick of developers converting their existing work to Gutenberg until a merge proposal is in place, with that in mind, what breaks in the initial release of Gutenberg does matter.

tldr; Do we expect breakage with Gutenberg? Yes! But we should still be selective about what we break, and how far that breakage goes in the initial iteration of Gutenberg merged to core.

Yes, we've all been around WordPress development enough to expect some things to break from one release to the next. And in a way that is exactly my point. As long as we are presenting Gutenberg as just another WordPress update, then it should not break anything more or less than any other update. If we break that trust, it won't matter how good the editor is at the end of the day.

Here's a current screenshot from a plugin I've been developing over the last several months. In this situation, a visual editor has no value whatsoever, and trying to shoehorn the sort of interface needed into an interface designed for visual editing of content makes no sense.

I'm actually seriously considering whether I should even bother continuing to develop this for WordPress, given that all my work may be undone with the next version.

As you can see, I need access to the media uploader in my metafields, and relegating the majority of the page to an iframe would make this interface extremely clumsy.

There are millions of interfaces like this in plugins, tools, and custom sites, built on WordPress. Treating these users like second-class citizens, in favor of the "new hotness" of blocks is unacceptable. Metaboxes need to retain their current level of integration and prominence in the edit page.

I highly support Yoast's view of Gutenberg. 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.

@aaronjorbin well, seems like there is a communication problem here as in https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/ it was explicitly said

This release includes long awaited meta-boxes support (needs testing!),

it is not an "idea" it is not an "experiments", it is just something that like every software might still includes bugs. I would not have tested it if it was called "an experiment" in that post.

Going back on subject, I see that the main problem here is the attempt to avoid declaring a breakage. From my limited understanding of JS framewoks, it is very hard to be "half pregnant" with them, and once you decided that your main screen control is done with them, everything needs to be done with them, therefor the only way forward is to make meta boxes first class citizens in the gutenberg edit screen.
As "legacy" plugins are unlikely to adapt, this will mean that gutenberg needs to be an explicit opt-in option for existing sites. I hate the idea of a UX fork, but at least this way there will be a way forward that will work, and if it will be declared now people will be able to prepare.

I've been using WP since early 2008, and I can't think of a new feature or decision that has created as much division in all that time as the introduction of Gutenberg, in its current form.

While WordPress is aimed at the users, it is but a tool, and users simply won't be able to make use of that tool if they don't have the WP professionals around to help them achieve their goals.

I'm seeing references to wanting to cater for the users of a fresh install (what? ~1% of the web increase per year?), but that seems to be at the cost of the existing userbase (~28%), the majority of which is likely to be running a plugin that has at least one meta box. That seems like poor business sense on any scale.

I get the ideology: create a best-case editor, then use an adaptor pattern to get old talking to new. The trouble is, PHP and JS are different technologies, and passing that issue off into the land of HTML iframes is not viable, for all of the reasons given previously.

It was the first pass, it was an experiment, but this effort is not successful. The quicker that is acknowledged, the quicker we can move on to the next suggestion.

No-one has come up with a suitable solution when it comes to the case of meta boxes that satisfies all parties though.

That means one party needs to relent - and whether that's 10-50 pro-Gutenberg developers, or hundreds/thousands of developers who are scared or the impact the changes will have for them, let alone their users, we'll see.

Once all the workarounds suggestions are exhausted, then perhaps there will be a concession that overriding the whole page is not feasible for all parties. At least not in the single hit that is currently being attempted.

To circle back to the original question - are iframes the long-term solution for meta boxes? Multiple developers (and let's not forget, they are Users too) have explained why the answer is no.

We've been having a largely constructive discussion here. Remember:

We criticize ideas, code, and pixels, not the humans behind them. We may have different opinions on the best path forward, but we don't question credentials. When we address individuals, it's to lift them up and give them credit for a job well done. With so much going on in the world, we gotta look out for each other. This is a monumental challenge, but we'll get there together.

Let me remind everybody that metaboxes in Gutenberg was the result of a @BE-Webdesign stepping up and getting this done, independently from everybody else with little help, appearing out of nowhere. If it weren't for @BE-Webdesign there would be no metaboxes in Gutenberg. Of the 47 comments left here, perhaps only 2 people actually touched the metabox code for review and UX purposes.

The fundamental problem here though, is how to safely get the metaboxes on to the page as 1st class citizens without building insecure code, leading to a tradeoff of hacky kludges or having gotchas.

• The first iteration involved a gotcha, making WP pretend it was on the edit.php page, and generate the metaboxes that way. Initial reports indicated it had compatibility problems and was super hacky, and not a viable solution. This is because a lot of plugins only register metaboxes if certain circumstances are met and don't trust WP to know when to render them
• The second iteration which is what got merged uses iframes, so the metaboxes are showing in the classic editor, albeit with everything but the metabox removed. This is a bit kludgy but it got metaboxes working, albeit with issues
• There's also a solution where we fetch the HTML code and then insert it wholesale into a component, which would be a security catastrophe, despite being the super obvious solution. Hence why it hasn't been done this way.

My suggestion, is:

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

Also, the yoast design is pretty, but where does block meta go?

Unfortunately, I have very little experience with js at the level required to contribute actual code to Gutenberg. I'm only starting to dip my toes into the world of developing WordPress rather than developing on top of it. So the best I can do is provide my feedback, test the editor (I actively use Gutenberg on my personal blog), and provide suggestions/thoughts. If I could contribute code, I absolutely would. If there is another way I can help out, I'd love to know. Because I care about this a lot. :)

Contributing comes in many forms. While the time and effort put into developing this attempt is appreciated, the testing and discussion that prevents future sunk costs can be just as valuable. For example, there are a number of newly opened issues related to the iframe implementation. We could sink many more hours into trying to fix those issues, or we could use the testing and rationale in this thread to determine a different direction is needed. I hope that's the realization that we've arrived at as a group.

Let me remind everybody that metaboxes in Gutenberg was the result of a @BE-Webdesign stepping up and getting this done, independently from everybody else with little help, appearing out of nowhere. If it weren't for @BE-Webdesign there would be no metaboxes in Gutenberg.

While the praise and adoration is nice 😄, I definitely had help, and it is largely a team effort from many people.

My suggestion, is:

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

Yes, this is most likely the next iteration, and I think this is a great suggestion as well as a constructive idea. Not 100% sure how to do this cleanly yet, but it is entirely possible to not use iframes, and have the same improved UX that Gutenberg is already providing. There will be updates coming to improve the meta box experience, which will likely involve eliminating iframes. The iframe method has served as a way to see how meta box support could be implemented, now better improvements will be made. When things were first being explored with meta boxes many months ago ( not a new topic ), it made sense to move forward with the iframe approach, due to the state of Gutenberg back then, now that it is merged and many other pieces have moved around, the use of iframes is probably no longer necessary, from a technical standpoint. More work will need to be done.

@BE-Webdesign Thanks for your efforts and input here. Let's close this out and begin a new issue when that approach is ready for discussion.

Please Stop and Reevaluate Now, Not Later

Not everyone is used to this approach to project design, but this is a project that follows a continuous daily reevaluation of pretty much everything. Compare the original mock ups to the current editor. Things change. Most pieces are not set in stone. The only way to truly evaluate whether something will work is to actually do it. Not everyone approaches product design the same way, but I think the rapid iteration of Gutenberg has been serving it well, rather than trying to hash out unknowns ahead of time.

Thanks everyone for the discussion. 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. The iframes are an implementation detail I think we can drop relatively easy. So let's focus on that.

I would like to add, as some concluding thoughts, that not changing anything about the edit screen would be the simplest path for us to do. It also would not be fair to the goals of the project and the long term users of WordPress. 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. 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. This cannot be built by us alone and we sincerely welcome all the help we can get from all of you, as there are several hard problems buried in the road to overcome.

WordPress always moves with the user, and we take the burden of figuring out development paths to ease transitions for our existing code. 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. There are people out there who could benefit from the default Gutenberg experience right now. As developers, we have the privilege of being able to manufacture solutions, but also the responsibility of not eluding the changes we have to make in order to allow people, who would otherwise struggle, to have their presence on the open web.

@mtias I truly appreciate your sensible comment, especially the part about "WordPress always moves with the user".

Unfortunately that is completely at odds with what @youknowriad has been communicating in this thread, and since you both work at Automattic I urge you to talk to him about the product direction, because right now we are getting mixed signals.

Unfortunately, you didn't address the Yoast sketch proposed which would give us all the flexibility of Gutenberg while being compatible with existing metaboxes. Why can't someone acknowledge why you are not considering this approach?

Unfortunately that is completely at odds with what @youknowriad has been communicating in this thread

I think you just misunderstood what I said, I was just enumerating facts and I share @mtias thoughts 100%

@mtias

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

I really disagree with this view. Making an iterative enhancement that is constrained to the editor itself, but has the power to replace metaboxes, as well as releasing and promoting a fields API would be a smooth way to transition the mass of plugins to a block paradigm, simply by ease of use, compared to the fractured landscape we have now.

By smoothly making that intermediary transition, you would make it much easier to deprecate direct DOM generation/manipulation on the post_edit screen, because by then, the standard, in-practice solution would no longer involve such manipulation. I don't believe anyone is saying "direct DOM manipulation needs to be the primary experience forever". They are saying "It is the the primary solution now".

if you can maintain complete flexibility of dom manipulation with a full-screen solution, go for it... but that seems to be a very lofty goal, and I doubt any form of hoisting from the classic edit screen will actually be able to deliver on any reasonable level of compatibility. Perhaps I am wrong, but it seems like an incredibly complicated hack to try to transition users, when a more iterative approach could do the same job.

By retaining the primacy of the current paradigm, while releasing the new one, you encourage adoption without hurting anyone's current experience. Then, once most workflows have transitioned to a block paradigm, direct dom control can be deprecated in favor of a full-screen solution.

It is not betraying the goals of the project, simply addressing the release schedule to make the change more manageable for thousands of agencies and developers.

@youknowriad Let me post a few snippets of what you have written to support what I'm saying:

by leveraging the REST API, client-side UI and unifying Core Concepts: Widgets, Shortcodes, Blocks, Content Metaboxes under a unique concept “A Block”

Nobody asked "Content metaboxes" to be turned into blocks, and it was not communicated until Gutenberg shipped its initial version. In fact, this is what the core of the argument is about. I won't repeat what others have said much better, just that metaboxes are very often not page content.

Unlike what you read here and there, the focus has always been about redesigning the whole page, The first mockup for the Gutenberg Editor Page has been shown in the second or third weekly Gutenberg meeting. We were still in the prototyping phase.

The Gutenberg team kept saying the sketches were just for show and not the final design. Besides, a sketch can't show whether the entire edit screen has been converted to React or if it's just been styled differently. The fact that the whole page was going to be redesigned came as a big surprise to everyone I have spoken to.

What’s the difference between Shortcodes, TinyMCE Buttons and Metaboxes?
The main difference is that “Metaboxes” have no “purpose”, it’s just a way to extend the editor page without consistency while Shortcodes and TinyMCE buttons have one.

This is a giant misconception that should raise eyebrows within Automattic. (And I hope @mtias and @m are listening). It's simply not true and I truly question your judgement following this statement.

Can we conclude that for the long-term of WordPress, Metaboxes are locking its evolution (regardless of Gutenberg)?
Yes, they are.

I'd say almost nobody agrees with you here, and I think Automattic needs to put this to a vote in order to determine the product direction.

I also question @mtias saying things like people needing to contribute. It's obvious that the Gutenberg team associated with Automattic aren't budging an inch and are deflecting all criticism.

I have literally zero faith that if I were to make a PR to reduce Gutenberg to be just the edit component, it would be considered by the Gutenberg team, due to statements made by a few individuals within Automattic.

@mtias,

I would like to add, as some concluding thoughts, that not changing anything about the edit screen would be the simplest path for us to do. It also would not be fair to the goals of the project and the long term users of WordPress.

Going one step at a time does not, in any way, compromise the goals of the project. You can still head to full-size customisation 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.

The Customizer is a prime example of this. Yes, it has its critics, but the end concept will be realised over time, to be a feature that allows certain groups of users to utilise WP efficiently as the tool for managing their site.

There are people out there who could benefit from the default Gutenberg experience right now.

Absolutely. But there is also a considerably greater number more who would have a detrimental experience with the default Gutenberg right now.

I hope we can all move on with respect and separate the people from the product in our responses. Passion is great, but it is important we think about the human's we're interacting with in threads like this. Every person involved in this project cares, they wouldn't be coming into these threads and interacting if they didn't. Now, let's take a breath and all remember how much we all care about WordPress and want to at the heart of our comments keep this community safe, productive for everyone.

@khromov, as the design lead of this project, just like Matias is the tech lead, I stand 100% behind @youknowriad. I understand you are passionate, but you are not being respectful. Please adjust the approach you are taking by calling a single person out. Let's stop being personal.

It's important to also remember a lot of those working on Gutenberg were members of the WordPress community before, were (are still) core contributors before. Yes, that includes myself. I will speak super personal here, once you do a PR please notify me and I will take a look and make sure it has the same respect all reviews do, no matter where they come from. Please, let's move on from seeing this project as an 'us v them' one. It is not and we have some amazing non Automattic contributors here, that statement does them a dis-service.

@khromov

I am generally seen as a detractor to Gutenberg, as my posts and comments highlight the issues I see with approach and implementation, but I feel that the goals and progress of Gutenberg are sometimes misconstrued in comments, due to a miscommunication or lack of understanding of the project's overarching goal.

Blocks are not a visual way to represent and edit post content, they also don't have to be part of a content-picker menu, or drag/droppable. They can be used for those things, of course, and that is the workflow that much of the visible parts of Gutenberg have highlighted. However, ignore what you know about that paradigm for a moment, and instead look at it this way:

Blocks are meant to be a fundamental control structure for the site, regardless of interface or storage.

• Widgets are slated to become blocks. That does NOT mean that they will exist in the editor and be saved in post_content. It simply means that they will be controlled with a system built in a JavaScript framework, with a single, common API.
• The Customizer is slated to be replaced with blocks. The interface will probably remain (roughly) the same, but the sections of the Customizer will be controlled by the same API.
• The plugins page, the theme editor, the dashboard itself, are all slated to eventually become blocks. If the idea of these sections, exactly as is, is impossible to imagine recreated with a common API, then you probably have some misconceptions tied to what a block is, in WordPress parlance.

The issue is not that metaboxes can't be recreated inside the block paradigm, in fact, non-front-end blocks that are added programmatically to a post type, locked in place, and store to post-meta instead of post_content are slated for the WordPress 5.0 release (correct me if I'm wrong).

In essence, that covers all the needs for trivial meta-fields like textboxes and selects. You could exactly duplicate that interface in blocks, if you want, or you could possibly streamline some of it, based on the new visual language that blocks supply... that would be entirely your call.

The issue is not that metaboxes can't ever be blocks. The issue is that right now, there are interfaces made in metaboxes, that are not yet supported in blocks (either by WordPress or third parties), and re-implementing that work is a herculean task for developers, especially since these tools were not built from a common API like the proposed Fields API, but rather in a hodge-podge manner that directly modifies the DOM of the page, and enqueues resources in an ad-hoc, unmanaged way.

This current state causes problems for developers too. For example, if you use Visual Composer, along with Piklist for fields, Piklist will override many of your admin styles, making VC very difficult to navigate.

Or if you are using WooCommerce along with any plugin that enqueues the new version of the Select2 Library, one or the other will break your admin interface, with a critical JS error.

The same thing can happen if two different plugins rely on different versions of the CMB2 framework.

Blocks intend to solve these issues by introducing a common framework around the various page additions. Some of this framework will be focused on offering wiz-bang drag and drop visual stuff to the editor, but the majority is not actually tied to that. It is just making sure that things that appear in admin are managed in a common way.

Now, there are valid arguments that WordPress has thrived on a Wild West dev attitude, and that this common framework raises the barrier of entry for developers who don't know react. And there are valid arguments that the Block interface will not reach anything close to widespread dev adoption before release. There are even valid arguments that the current block API is a bit naive, and doesn't take into account many common workflows, making it impossible to adapt plugins until those capabilities are created and documented.

But arguing that the Metabox free-for-all, as is, is the end-all be-all solution, and must be preserved for eternity doesn't offer a great path forward for anyone. For WordPress to be able to offer better options for all users, devs included, some sort of common system needs to exist.

It would have been nice if this system was a common Fields API, years ago, so that all these changes would mostly just be a replacement of the rendering step for that API, but as it stands, a path forward needs to be found.

All that said, I am still strongly in favor of Yoast's proposed interim solution, as being the best real-world way to move towards an eventual common UI. I remain critical, of course, but I want to make sure we are critical of facts, and not misunderstandings.

Unfortunately that is completely at odds with what @youknowriad has been communicating in this thread, and since you both work at Automattic I urge you to talk to him about the product direction, because right now we are getting mixed signals.

I'd say almost nobody agrees with you here, and I think Automattic needs to put this to a vote in order to determine the product direction.

It's obvious that the Gutenberg team associated with Automattic aren't budging an inch and are deflecting all criticism.

I have literally zero faith that if I were to make a PR to reduce Gutenberg to be just the edit component, it would be considered by the Gutenberg team, due to statements made by a few individuals within Automattic.

I'd just like to state the obvious, but Gutenberg is a WordPress community project, not an Automattic product. I might be an Automattician myself, but that gives me no more authority on this project than anybody else, be they a freelancer, agency CEO, or a dedicated dev fulfilling a companies 5% commitment, unlike what some people have suggested. Similarly, WordPress itself is a community project, not an Automattic project.

Automattic doesn't "release" or "build" WordPress, and Gutenberg isn't an Automattic product

Furthermore, before this conversation becomes even more emotional, and people lose sight of the forest for the trees, I would like to take the time to appreciate the difficulty of the task that has been assigned the Gutenberg team, and how well they are handling it in general. They have been tasked with creating a paradigm that will become the basis for WordPress's entire admin experience, within constraints that only allow them to demonstrate its effectiveness in one small corner of the interface.

The amount of misunderstanding caused by the idea that "the editor is taking over" is immense, and must be very hard to manage. Their purview is to create the common building blocks for WordPress's admin, and to test them out by rebuilding the editor. While I believe that this task would be much more palatable and flexible to the public if they were just rebuilding the wp_editor() interface and expanding from there, it is understandable why all the connected components of the 'edit experience' make a more complete trial for the proposed new paradigm.

I understand, and I appreciate the year of effort that has gone into this work. I still am critical of some of the decisions made, and believe there is time to make some modifications that will vastly improve the initial adoption, but I am completely in agreement with the overarching goal of eventually providing a more structured framework for the WordPress admin experience, for both devs and users.

@karmatosed

The reason I mentioned @youknowriad is that he was the only one engaging in the discussion. A discussion that have involved hundreds of developers and thousands of hours without making any headway, despite there being a clear consensus from the developer side. I don't think it's disrespectful to question the legitimacy of decisions made when they are made by a small group of developers, even if that involves calling out specific people.

Regardless, I had a private chat with @youknowriad and he has explained to me the upcoming roadmap which in my opinion sounds more sensible than what is being communicated outwards.

@tomjn

I respectfully disagree. The important decisions are made by Automatticians, and after a talk with @youknowriad I have understood that the product direction is already set for a long time to come, so there's nothing for us regular contributors to do other than fix bugs and perhaps some minor visual tweaks.

@gschoppe I just wish this "paradigm shift" was discussed openly and made in collaboration with the developer community. Maybe that's the intention, but in that case the communication side is not working very well.

Why can't someone acknowledge why you are not considering this approach?

@khromov we had already, and in some other places in the editor chats, etc. This issue in particular was about the iframe implementation.

I have literally zero faith that if I were to make a PR to reduce Gutenberg to be just the edit component, it would be considered by the Gutenberg team, due to statements made by a few individuals within Automattic.

Not at all. We considered it ourselves very early on before, seeing it too limiting and not appropriate to drive the vision we had. It might still be a reasonable compromise for many, and could be a good plugin to explore. The work needed to make it happen, though, would improve Gutenberg in general by making it more reusable, so I wouldn't oppose people working on it. If someone worked on such a PR, I'd probably suggest to add a setting in the Writing section to toggle the behaviour instead of making it the default.

We have significant features coming around nested blocks, global blocks, declaring block templates, columns, etc, that really benefit from the sheet of content being the full page and would feel rather poor otherwise, limiting what developers can do and what users can experience. There are also nice tools like the document outline that integrate seamlessly and in real-time in the full-screen editor that would be contrived in a mere replacement of TinyMCE.

Going one step at a time does not, in any way, compromise the goals of the project.

Definitely! We have proposed a staged approach, from Matt's original new focuses post, it just considers the steps differently. 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.

Absolutely. But there is also a considerably greater number more who would have a detrimental experience with the default Gutenberg right now.

Of course, and it's why there is both a plugin to go back to the current experience at will, and we'll have mechanisms to handle incompatibilities, 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 viceversa).

@gschoppe I know we have had our fair share of disagreements in the past, but I appreciate your comments here and willingness to participate even through the different points of view. You make some good points about the agglutinating factor of the block. Maybe one day we'll meet over a WC conference and we can embark on a fun philosophical discussion over the ship of Theseus paradox. Who knows. 😉

You from Automattic should not complain we cannot respect your work, and that we are pushing you to much.
Not for 7000 - 10.000 € pro month salary you get paid. Silly. It is not like when people complain on WP Trac to developers volunteers.
If Gutenberg gives you headache talk to your boss. He gave you impossible task to do.

Second, you are way better coders than majority of people who commented here. Why did you try to pass "Iframes" solution ?
I told you, you treat people like kids. Let us make a try with iframes and see if people will scream to much, be to much emotional. If there is much noise we move away from iframes.

Why did you try to pass "Iframes" solution ?
I told you, you treat people like kids. Let us make a try with iframes and see if people will scream to much, be to much emotional. If there is much noise we move away from iframes.

When meta box support was first being implemented, the new editor existed on an entirely new admin page, not post.php, the editor loaded differently, and in general there were many constraints, part of solving the meta box problem using iframes, illuminated some of those constraints, which no longer exist, and as a result meta boxes, most likely will not need to use iframes anymore.

This project favors incremental improvement across releases over perfection in a single release. No one is trying to see if people will scream. The reality is that the iframe approach worked well for most meta boxes, despite what people have made this into. Now it will be improved upon further, and there will be fewer and fewer 😱 🙀 .

@StaggerLeee please be respectful to everyone in this project no matter where they work. Just as you would like someone to treat you well, do the same to others.

I will not as the design lead for this project see personal statements like you made said to anyone. I do not care where anyone works or any of their background, that's personal details you have no right to call out over. Please drop the personal and get back to focusing on the product.

Now, let's move on and focus on making the best product we can. I absolutely understand your points often come from a place of passion. You can be respectful and passionate, please go back to being that.

You from Automattic should not complain we cannot respect your work, and that we are pushing you to much.
Not for 7000 - 10.000 € pro month salary you get paid. Silly. It is not like when people complain on WP Trac to developers volunteers.
If Gutenberg gives you headache talk to your boss. He gave you impossible task to do.

@StaggerLeee I wish I was paid that much hint hint 😂 but Automattic isn't Google, and I can earn more elsewhere in the WP world. My own presence here is purely off of my own back, I'm not paid to be here, and neither are a lot of the other people working on this. I'm actually paid to do code reviews and help launch enterprise clients!

So trust the message has been received, the proof is in the Pull Requests tab at the top, this isn't an Automattic conspiracy to break your code and p**s off your clients ( don't forget, Automattic has paying clients who use metaboxes too )

For those still concerned by iframes, I suggest looking here at this Pull request ( #3345 ) which is attempting to undo the iframes and implement my suggestion made earlier.

As the next iterations of metaboxes implementations, it would be good to test and identify compatibility issues, throwing rotten fruit towards A8C might feel good but it doesn't help.