search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.32k stars 4.12k forks source link

Are iframes a viable long-term solution for meta boxes? #3304

Closed kevinwhoffman closed 6 years ago

kevinwhoffman commented 6 years ago

Issue Overview

Generally speaking, iframes have been discouraged in web development for many years for reasons that are well-documented:

We began to explore the pros/cons of iframing the content area in https://github.com/WordPress/gutenberg/issues/2420, however iframed meta boxes were introduced in Gutenberg 1.5 without a similar discussion.

Some of the issues that resulted are clearly related to iframes (https://github.com/WordPress/gutenberg/issues/3242 and https://github.com/WordPress/gutenberg/issues/3243) while others listed below may or may not be. Before making the effort to resolve these bugs one by one, we should consider whether iframes are a viable long-term solution for meta boxes and what kind of effects that decision would have on users and developers.

The Big Question

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.

Additional Questions

  1. Given existing issues with saving data from meta boxes (https://github.com/WordPress/gutenberg/issues/3277), are we confident that editing content in iframes will not result in any data loss? In other words, is the inability to save data in some meta boxes a temporary bug or a technical limitation of mixing iframes with React?
  2. What kind of challenges are introduced when it comes to debugging PHP or JS meta box functionality when they are placed within iframes?
  3. Many plugins enqueue CSS and JS that affect multiple meta boxes - some in the main column and some in the sidebar. 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?
  4. What, if any, accessibility challenges are introduced by placing meta boxes in an iframe?
  5. What, if any, issues are related to iframes on mobile?
  6. Is it possible to launch a content window from a meta box that extends beyond the iframe?

Screenshot

In the screenshot below (Gutenberg 1.6), iframes are marked with a red border to show their location. In this case, Yoast and WooCommerce meta boxes exist within the iframe. WooCommerce requires use of both the main column and sidebar iframes.

gutenberg-meta-box-iframes

Related Issues and/or PRs

kevinwhoffman commented 6 years ago
  1. ...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.

gutenberg-iframes-network-tab

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.

karmatosed commented 6 years ago

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.

kevinwhoffman commented 6 years ago

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.

BE-Webdesign commented 6 years ago

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?

kevinwhoffman commented 6 years ago

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.

mathetos commented 6 years ago

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.

BE-Webdesign commented 6 years ago

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.

nerrad commented 6 years ago

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.

BE-Webdesign commented 6 years ago

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.

kevinwhoffman commented 6 years ago

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

image

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

nerrad commented 6 years ago

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.

youknowriad commented 6 years ago

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.

youknowriad commented 6 years ago

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.

kevinwhoffman commented 6 years ago

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.

youknowriad commented 6 years ago

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

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

staylor commented 6 years ago

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?

JasonTheAdams commented 6 years ago

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.

aaronjorbin commented 6 years ago

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.

markkap commented 6 years ago

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.

aaronjorbin commented 6 years ago

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

mor10 commented 6 years ago

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.

metaboxes

youknowriad commented 6 years ago

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

nerrad commented 6 years ago

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.

kevinwhoffman commented 6 years ago

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.

gschoppe commented 6 years ago

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.

2017-11-02-23-30-ensemble dev

markkap commented 6 years ago

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

gonzomir commented 6 years ago

After reading the discussion and thinking about the projects I build with WordPress, and things I see people do with WordPress, I came to the conclusion that Gutenberg should be opt-in for custom post types. This will allow current websites that use CPT for a structured data to continue to work and new websites where WordPress is used as a CMS to be build. I want just to remind you that when registering a post type we can explicitly declare the support for editor field together with other features. Then why not just add explicit support for Gutenberg there? Of course this will not fix the issue with meta boxes added to posts and pages, but it will allow WordPress to be used as a CMS in the future.

StaggerLeee commented 6 years ago

Can add one new issue with those iframes. When User session goes out WP login screen is shown over Gutenberg, and inside iframe, twice.

Just for developers to be aware of it.

StaggerLeee commented 6 years ago

More I follow all of this more I am convinced that only possible way would be like Microsoft did.

Windows XP = WordPress without Gutenberg Windows 10 = Wordpress with Gutenberg.

Those 2 cannot be mixed and updated with packages of other one.

Joomla and Drupal did it. Why not. Not something I prefer at all, but what is alternative.

kevinwhoffman commented 6 years ago

After reading the discussion and thinking about the projects I build with WordPress, and things I see people do with WordPress, I came to the conclusion that Gutenberg should be opt-in for custom post types.

A split admin would be one of the worst results that can come out of Gutenberg. I've outlined the reasons why in https://github.com/WordPress/gutenberg/issues/3330#issuecomment-341752490.

khromov commented 6 years ago

This discussion is getting really kafkaesque. It seems that no matter how many people propose pragmatic settlements to the current pain points, there are a few key people that seem completely impervious to the criticism. Unfortunately these people are the ones who have the final say, because so far the discussion has showed that a few key people can run over hundreds of worried of developers. I worry about all the damage this is doing to the WordPress ecosystem. Make Gutenberg the editor, not the edit screen. Don't break WordPress.

viktorbijlenga commented 6 years ago

Kevin Hoffman:

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 believe that the path forward proposed by Yoast would be a great improvement to WordPress Core. A new editor to create content, that a lot of users would embrace as an improvement over the current one. A smaller step for WordPress, but a great improvement for the user.

youknowriad commented 6 years ago

This is a heated subject. I admit that sometimes we (at least I) can be dismissive in my comments and I apologize for this. We’re receiving a lot of feedback, good, bad, objective, useless and sometimes it’s hard to distinguish between them. We are human. Try to be on the other side of the equation, be the one building this thing and receiving all this feedback. IT can feel close to “personal attacks”, brains tend to react by being dismissive, we should not.

People commenting and reading blog posts often think we are discovering the meta boxes issues and all what’s related. We’re not. We’re working on Gutenberg for a year now. Maybe you just discovered/tried Gutenberg but we don’t, we work on it for enough time now to be comfortable with most of the backward compatibility issues and we have answers for most of them.

Please, be open-minded, and let’s start by answering some questions:

What’s the goal for Gutenberg? Is it to replace the editor?

It’s not, and it never was, the main goal for Gutenberg is paving the way to the future of WordPress Core. Technically, by leveraging the REST API, client-side UI and unifying Core Concepts: Widgets, Shortcodes, Blocks, Content Metaboxes under a unique concept “A Block” and experience wise by answering these questions: How can simplify building websites (think customizations) and publishing content (think editor) in WordPress.

What’s the goal for the Gutenberg Editor? Is it to replace the editor or the whole page?

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. Months before the first alpha. The design was close to what we have right now.

What about the Metaboxes, are they important for WordPress?

They are. Like Shortcodes, Custom TinyMCE Buttons, they are heavily used and abused to extend WordPress’s editor page.

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.

Shortcodes are a string converted to content in the rendering phase, TinyMCE Buttons are custom buttons added to the TinyMCE toolbar and use the TinyMCE API to communicate with the editor’s content. Metaboxes? I don’t know, they can be anything, you just add a bunch of HTML,Javascript and PHP to extend the editor’s page and how it behaves on save.

Is this lack of “purpose” an issue, or an advantage?

Well! It can be seen as a “pro”, because a plugin can do anything they want with the editor including things like:

Flexible right! But what about WordPress updates. Any update to the editor’s screen. Any TinyMCE update, any class change, any new div, any button removed/moved, any change is breaking compatibility with plugins because as a Core WordPress developer, you do not know what plugins are using Metaboxes for.

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

Yes, they are. And Internet history proved so many times that a technology that doesn’t evolve dies. (please do not react with 👎 If you do not like this answer, it's a fact and not an opinion)

Ok, but then how can we move WordPress forward if we’re stuck with Metaboxes?

That’s a good question and before answering, we need to understand the current use of Metaboxes in WordPress plugins

What do the current plugins use Metaboxes for?

I’d say there are two categories of “Metaboxes” plugins:

Ok, knowing this, how can we move forward?

We need three things:

Ok, but didn’t you say that any change to the editor page will break plugins (including replacing only the content area)?

Right! So if our wish is to not break any plugin, we’re left with a unique option. Provide a way to stay with the current edit page without change. That’s exactly what the plugin disabling Gutenberg is for.

I would not call this a good upgrade path personally, it’s not even an upgrade, anything better?

This upgrade path (disabling Gutenberg) is a necessity but yes, we can do better. If you take a look at the plugins using Metaboxes, 90% of them do not have any interaction with the content area, thus, if we replace only the content area (yoast approach), we will be breaking 10% of the plugins only.

So, the only way without breakage is disabling Gutenberg. Replacing the content area only breaks 10% and leave us with a middle-ground User Experience, what if we still want the whole Gutenberg upgrade, how much plugins this would break?

The optimal Gutenberg User Experience consists of replacing the metaboxes plugins with plugins providing the same functionality with the new Gutenberg Extensibility APIs.

That said, we noticed that most of the plugins using Metaboxes are using them as content being saved to post meta and we can make those work in the Gutenberg screen to enjoy the whole experience while plugins authors upgrade their plugins.

Is this the iframe solution everyone is talking about?

Yes, it is. We show the meta boxes in iframes which has its drawbacks (link, modals, reloading assets) but at the same time it allows 80% of the plugins to work while enjoying the whole Gutenberg Experience. This solution just landed and we’re still experimenting with it. What’s certain, is that there’s no way to make all metaboxes work and make changes to the editor.

I see, can you recap the upgrade possibilities please?

Sure.

1- Disable Gutenberg: do not break 100% of the plugins 2- Gutenberg replaces only the content area: 90% of the plugins work, the UX suffer 3- Gutenberg replaces the whole screen: 80% of the plugins work, the UX is better 4- Gutenberg with compatible plugins: Best possible UX

So what do we need to do?

Our goal is to build the 4th option because it’s the best option for WordPress’s future. Our goal also is to build Gutenberg in a way we can reuse its pieces to achieve the 2nd and 3rd options if needed.

How can I opt-in for on option over another?

This has not been decided yet. Having a plugin to choose which upgrade path you want is a possibility. Downgrading automatically by detecting some Metaboxes is an option...

That's my take to explain the reasoning behind these issues, please if you want to answer with words like "ridiculous", "badly managed", "poor implementation"... my patience as a simple developer who spent the entire year thinking about the best possible way forward for WordPress as a whole (core and community) is close to a limit. I personally might not reply further on this issue, but I'm listening to feedback and will adapt my reasoning if convinced by feedback.

We're all on the same boat, we want the best for WordPress.

vladolaru commented 6 years ago

Very thorough explanations, Riad. Thanks for making the time to write them. Let me help you stay clear of that limit with a 💪 and a 🤗. Hope it helps.

With regards to metaboxes, I would be extatic to have a Fields API in core. Would rewrite our plugins just to get rid of all the mess custom metaboxes solutions tend to gather after some time.

Now for people that have complex metaboxes setups, the Fields API is their salvation as long as they've built them on top of a framework like ACF or CMB. The developers of those frameworks just need to switch to the new API and all is well. Not an easy task, but good for everyone. Now for those with "hard-coded" stuff lying around, now it's as good a time as ever to reorganize things in a cleaner, more future proof way. You’re in better shape, Gutenberg or not.

kevinwhoffman commented 6 years ago

We are human. Try to be on the other side of the equation, be the one building this thing and receiving all this feedback. IT can feel close to “personal attacks”, brains tend to react by being dismissive, we should not.

There are humans working very hard on Gutenberg. There are humans whose livelihoods (their themes and plugins) will be affected by Gutenberg. And there are humans who use the themes and plugins affected by Gutenberg to do their own work. We're all looking out for each other and want the best for WordPress at the end of the day. Though we may disagree passionately on what "best" means.

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

Mockups alone did not signal that the code base of the entire editing page would be rewritten in React. No one could have known looking at a mockup that critical hooks would be removed or meta boxes broken. However, when it became obvious to me that the full-page takeover would pose an issue for meta boxes, I voiced that concern on June 15th, the day before 0.1.0 was tagged for release. Four months and 15 releases later was the first time we actually saw meta boxes appear in the interface, within iframes.

I created this issue based on my experience closely following and testing Gutenberg since its pre-alpha stages. This is just the latest issue related to ongoing meta box challenges, but importantly, it is the first one based on concrete testing of a meta box implementation of Gutenberg.

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 again signals a fundamental misunderstanding of how meta boxes are used by plugin and theme developers. We expect that shortcodes and TinyMCE buttons will need adapted because they are actually used within the content editor. Meta boxes are not.

Suggesting that meta boxes—the foundational building blocks of custom WordPress development—have no purpose again tells the community that Gutenberg is prioritizing the core experience of a "fresh install" at the expense of plugin and theme developers.

Any update to the editor’s screen. Any TinyMCE update, any class change, any new div, any button removed/moved, any change is breaking compatibility with plugins because as a Core WordPress developer, you do not know what plugins are using Metaboxes for.

We may not know the purpose of a meta box, but we know the fundamental requirements for registering a meta box and the hooks they use. We know that none of them were developed to work within iframes. For years we've understood how to extend and enhance WordPress without breaking them. Again, if 5.0 is just another WordPress release, then the amount of breakage should be no different from any other release.

We show the meta boxes in iframes which has its drawbacks (link, modals, reloading assets) but at the same time it allows 80% of the plugins to work while enjoying the whole Gutenberg Experience.

If you have any evidence for these 80%/90% numbers that are constantly being referenced, please share it. Otherwise please don't use hypothetical statistics when asking the community to make a decision of this magnitude.

Please Stop and Reevaluate Now, Not Later

After all of this discussion and what I thought was proof that iframes are not a viable long-term solution, I came across https://github.com/WordPress/gutenberg/issues/3165#issuecomment-341476059 that looks to add a third iframe to Gutenberg.

It is past time to stop pursuing the ideal editor as if limitations don't exist, and start considering an approach that doesn't break WordPress.

gschoppe commented 6 years ago

Speaking as a developer who has been watching and discussing the Gutenberg editor from day 1, I'm sorry to say that Riad's argument has some big holes in it.

Firstly, people have been bringing up the issue of metaboxes since day one, along with several other issues that are still up in the air. in the Mockup phase we were told "everything is a visual best case, we'll address metaboxes later". Then, in the prototype phase it was "This is all proof of concept code, metaboxes will be dealt with later". Then when the first iteration of the feature plugin was released (which was, as a huge surprise to no one, not a from-scratch rewrite after-all, and just a repackage of the current proof of concept code), the argument suddenly became "legacy interfaces like metaboxes will have some support for now". Then, when the public outcry became deafening, it was "we misspoke, metaboxes aren't legacy". But now, this argument is just pushing the "legacy" agenda again.

Metaboxes aren't legacy code, because there is currently no viable replacement.

In metaboxes, I can trivially add a full-featured, nested editor using wp_editor. Gutenberg currently has no UI for nested blocks, and it isn't slated for 5.0 release, so it cannot do the equivalent, without a massive amount of custom UI code.

That is a single example, but degrading the experience of metaboxes is not an acceptable solution, until Gutenberg is beyond parity. That won't happen by WP 5.0

Here is a roadmap to the "unified admin" plan for Gutenberg that would actually work:

That way, developers can start utilizing Gutenberg on production tools without losing the current capabilities they have. Gutenberg will benefit from all the edge use-cases that are developed for these developers, creating a flexible solution that will actually meet the needs of those currently using metaboxes.

By the time metaboxes are deprecated, plugin authors will have had sufficient time to learn and use the benefits of Gutenberg in the wild, and it will be the obvious choice.

Gutenberg is like a concept car. Scale back now, and ship an iterative improvement to the editor (not the editor page). Then, over the next year or two, you can walk the project towards 100% admin coverage.

jchristopher commented 6 years ago

I just want to hop in from the perspective of a client service provider who has referenced WordPress' vocal commitment to backwards compatibility to ease client concerns about updates breaking their websites. With that, I recognize that my usage of WordPress has likely skewed/biased my perception of the edit screen.

To date it feels like this issue has been punted/dismissed/downplayed when in my world meta boxes have been a major selling point for WordPress since Custom Post Types became easily available for widespread use. I'm glad this discussion is happening.

Gutenberg is an impressive project, yes, but the clients I've worked are really quite happy with the meta box based solutions they have been provided with. Having an option to disable Gutenberg is nice, but I'm concerned about it being opt out via plugin. Despite my best efforts to coach customers, I don't imagine they'd be willing to install a new plugin on their own, nor would they know what Gutenberg is even if it's blatantly featured on an upgrade welcome screen.

It's possible (perhaps even likely) that the meta box plugins I've used on client sites could be updated to be "Gutenberg compatible" but even then the entire workflow is going to change for those clients overnight. It feels like it's asking a lot of those clients when their existing workflow has done well for them since their site was delivered however long ago.

I fully stand behind the goal of Gutenberg improving user experience, but in my opinion we can't avoid the precedent that's been put in place (intentional or not) to use meta boxes for content editing. I think Yoast's approach is great, it's something that ticks a number of checkboxes for a wide variety of potential solutions to this problem.

Just my two cents, looking forward to observing the outcome here.

ghost commented 6 years ago

The number of plugins working with Gutenberg may be 80%, 90% or 0% as in our tests, what should be avoided is that thousands and thousands of site owners have to find out by themself whether their configuration will probably work or will not work with Gutenberg. That would be an enormous waste of time (=money), cause a lot of confusion and kill a lot of trust.

I would like to see plugins/themes marked as compatible / not compatible with Gutenberg (or 'not relevant'), so that site owners can be informed about potential problems before that thing becomes active on their sites and can act accordingly. Data could not only come from plugin owners but also from community tests during beta testing time (the real beta..., and that timespan should be long, not just a few weeks.) and beyond.

I am aware that this will never be complete or 100% accurate, but should be doable for the most prominent plugins.

PS. For my own projects (a intranet microsites platform for a client > 30.000 employees, and a bunch of small business/non profit sites) we decided to disable Gutenberg until it is at least one year successfully in the wild.

jnicol commented 6 years ago

Percentages don't tell the whole story anyway. Any discussion of the impact of Gutenberg needs to consider how many websites are affected by its metabox implementation, rather than how many plugins are affected. Gutenberg could impact only a handful of plugins and still affect millions of users, since some of the most widely used plugins depend on metaboxes and custom fields - ACF and Yoast SEO being two obvious examples.

aurooba commented 6 years ago

I've been following the development of Gutenberg from afar for many months now and I know that the issue of metaboxes has been around for a long time. I support the philosophy behind Gutenberg and I think eventually Gutenberg is going to become a very powerful part of WordPress core that enables WordPress to be a viable and competitive piece of software for many years in the future. I am SO onboard with the whole concept of Gutenberg and its aim.

What I don't understand is the desire to get from 0 to 100 in one go. Why is an iterative release not the path being taken here? Why are the two options 'break nothing' or 'break everything'?

Metaboxes are the reason why WordPress is as powerful as it is. Its purpose is to extend the edit screen.

I think it's great that Gutenberg wants to overhaul the entire screen, but I just don't think that's realistic to do in one go, especially if it means treating one of the most important components of WordPress (as far as custom development..which is a huge huge part of success of WordPress) as an aside.

2- Gutenberg replaces only the content area: 90% of the plugins work, the UX suffer

The UX doesn't suffer. The users will see it as the editor section getting revamped. It'll give them a new way to create content – a way that most of them will find empowering after they adjust, and it won't break any existing workflow they have or leave them wondering how to accomplish the things they used to accomplish in the editor.

4- Gutenberg with compatible plugins: Best possible UX

This is an excellent goal, but it's the long term goal. Eventually yes, absolutely, it should be Gutenberg with plugins that work with alongside or inside the Guteneberg experience.

Our goal also is to build Gutenberg in a way we can reuse its pieces to achieve the 2nd and 3rd options if needed.

I'm not really sure what this means. You want to build Gutenberg with the assumption that plugins all just work with it, and use that solution to pedal back to option 2 and 3? Building first towards 2 and then iterating to 3, isn't that what's going to get us to 4?

I like the roadmap proposed by @gschoppe, as a developer who builds custom WordPress websites, this is an approach I can get behind, one that won't negatively impact developers or their clients or normal WordPress users, and still get us to the end goal of Gutenberg - albeit at a pace that's easier to swallow.

amandarush commented 6 years ago

Along with Kevin's concerns about iframes, I'd like to point out some accessibility concerns. First, while users who experience a site visually will experience framesets and iframes as a cohesive whole along with the rest of the page, screen reader users do not. Screen reader users experience each frame within a frameset, and each iframe, as a distinct part, separate from the rest of the page, because web pages are experienced in a linear fashion. Some screen readers, (notably Jaws for Windows, which is the one with the most market share according to WEBAIM's annual screen reader usage survey), has a configuration setting to ignore frames, including inline ones, because they can be so jarring to some screen reader users. When the ignore frames setting is invoked, the content within frames and iframes disappears. Even if Gutenberg follows every accessibility best practice when it comes to iframes, asking users to disable this setting for the sake of being able to fully edit content also exposes them to every single instance of iframe and frame worst practice on the net. The only other alternative for these users is to ask them to create a separate profile just to use Gutenberg, which is not a simple process, because it means they need to configure every single browser setting and speech setting all over again. It also means they need to then keep up with at least two separate browser profiles. I will be the first person to tell Jaws for Windows users to migrate to NVDA full time because reasons. Gutenberg using iframes for metabox support is not one of those reasons.

smutek commented 6 years ago

.. my patience as a simple developer who spent the entire year thinking about the best possible way forward for WordPress as a whole (core and community) is close to a limit.

I swear I hate to be rude but you may need to get thicker skin in that case. You're frustrated at the responses in the face of an "entire year" you've spent thinking about this, and thank you for doing so, but these are decisions that are going to impact multiple years of work that others have done.

In my case, from what I am reading, nearly every website I've built over the last 3 years may break instantly. I'm no longer responsible for these sites, but what's going to happen at the agency where I used to work when dozens of clients are calling at once with broken sites. How will that impact that little agency, their day to day work, their bottom lines? How will it impact their clients? Those are my concerns and I'm just one little (figuratively) developer in this relatively large ecosystem.

I admit that sometimes we (at least I) can be dismissive in my comments and I apologize for this.

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.

It makes me sad to write this but I would not in a million years suggest anyone start a major project with WordPress right now.

amandarush commented 6 years ago
2- Gutenberg replaces only the content area: 90% of the plugins work, the UX suffer

@youknowriad, how can you say the UX doesn't suffer with Gutenberg versus TinyMCE? I'm genuinely asking that question, not snarking. I can tell you that the UX indeed suffers greatly in Gutenberg compared to TinyMCE and meta boxes. I would encourage you to find this out for yourself by:

(1) Unplugging your mouse. (2) If you're on a Mack, press command+f5, and attempt to get anything productive done using VoiceOver. (3) If you're on a PC, go download NVDA, install it, unplug your mouse, and perform the same test. Try to do something productive with Gutenberg under those circumstances.

I think you'l find that the UX is an absolute nightmare at this point. That's not to say that it can't change for the better. Gutenberg provides an opportunity for WordPress to clear out a lot of technical debt with regard to accessibility, and if this is done with care and correctly, then some huge achievements can be had. But if this is done incorrectly or carelessly, a lot of the work the WordPress Accessibility Team and other core contributors have done since 2012 will need to be begun again. I would like to see WordPress as a project not make the same mistake it started out with: Not considering web accessibility from the start, meaning that the accessibility team and other concerned contributors have found themselves bolting on accessibility after the fact, which is a task that can never be caught up on, since WordPress is not a stagnant code base.

I get that you guys have been working on Gutenberg for a year. I also get that working on this is hard in and of itself, and that negative feedback doesn't help that situation. Finally, I get that it may seem that those of us who are being as critical as we are may appear to be calling your baby ugly, or merely reacting to fear of change, and as a creator, that's frustrating at best and hurtful at worst. But speaking for myself, the baby isn't ugly. It has a lot of unrealized potential to either be the coolest kid on the block, or the little jerk that makes everyone's lives miserable. I'd like to see it be the former and not the latter. With regard to meta boxes specifically, they are a literal staple of WordPress custom development, probably moreso that shortcodes or TinyMCE buttons. They shouldn't be brushed off lightly, or shoved in an iframe until we can figure out how to get rid of them.

ramseyp commented 6 years ago

My simple story with WordPress is that it has been my website engine of choice for creating websites for individual, small business, and enterprise customers for more than a decade. In that time, there have been three things that have made WordPress the tool of choice:

  1. Open source. I think this audience can agree how powerful and advantageous this is.
  2. Ease of use. WordPress made it amazingly easy for non-developers to create and update content. This was huge in my early years of creating websites for individuals and businesses.
  3. Defining content. Custom post types, custom taxonomies, and custom meta boxes. When everything leading up to these reached a singularity, I don’t think I’m reaching when I say this is when WordPress was “sellable” to the business community as more than just blog software. ( WordCamp Phoenix 2012 - CMB. Justin Tadlock’s great writing on defining post types, taxonomies, and meta boxes. )

I would go so far as to say custom meta boxes - this ability to create custom admin interfaces, creating a great user experience for people, is massive. Break that, and you’re breaking WordPress.

The idea behind Gutenberg, making the content editor experience more powerful, is a great idea. It’s worth doing, but must be done right, with care, and not rushed. Right now, it feels very rushed, and nowhere near ready.

@jchristopher says it very well:

I fully stand behind the goal of Gutenberg improving user experience, but in my opinion we can't avoid the precedent that's been put in place (intentional or not) to use meta boxes for content editing. I think Yoast's approach is great, it's something that ticks a number of checkboxes for a wide variety of potential solutions to this problem.

@jnicol and @aurooba make great points and ask good questions. Why does it appear like it’s all or nothing instead of more of an iterative roadmap? Yoast’s alternative is much more sensible than what’s been seen and I think the “iframe experiment” proves that point. Thank you, @amandarush, for calling out the accessibility problems. I challenge everyone to try working with Gutenberg the way she outlined. It might change some perspectives.

@aaronjorbin said it earlier, when someone adopts WordPress, they are not adopting WordPress (version-number-here), they are adopting WordPress as a whole.

There’s another version of that, that anyone in client services probably hears often. When someone comes to you and says they need a new website (we’re not talking about blogs), they generally don’t say, “I need a new Wordpress website”, or "I want a new Drupal site", etc. They just want a new site, one that works, and works well.

WordPress has been the best solution for millions of websites: ease of use and open source being key. Breaking custom meta boxes (forget the plugin numbers, how about all the existing websites with custom admin UIs?) with a rushed implementation of a new editor interface damages that ease of use.

rickgregory commented 6 years ago

my patience as a simple developer who spent the entire year thinking about the best possible way forward for WordPress as a whole (core and community) is close to a limit.

I'm going to be blunt, here:

This and a couple of other comments like this make me think that some of you should step away from decision-making roles in this project. If you can't take honest, well-thought out, but critical feedback on a product then, frankly, you should not be in a decision-making role on a product team. I've been in your shoes multiple times, usually in face to face meetings and in the successful cases everyone in the room realized that no matter how heated the debate got, it was about delivering the best product we could for customers. Taking criticism about product ideas and direction is part of being a decision-maker on a product team and it should lead to a better product because no one can possibly think of the best way to do everything. That goes for teams too.

I have no doubt that everyone on the core team wants to deliver a revision of WordPress that's awesome but you inevitably get close to a project; you know what's been debated, considered, rejected, etc and it's hard to pull up and see things from an outside perspective. But you are not the totality of the WP community; you can't be. What you're hearing are valid concerns about the product direction. If you can't take that on board, think about what's being said and why it's being said then, please, step away from making decisions about the direction of Gutenberg.

Alternatively (and this would be FAR better), DO take on these thoughts. Truly consider what people are saying. Understand our concerns as people who run businesses that use WordPress and understand that we're concerned not only for ourselves, but for our clients.

GaryJones commented 6 years ago

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.

kevinwhoffman commented 6 years ago

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.

tomjn commented 6 years ago

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.

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:

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

aurooba commented 6 years ago

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

kevinwhoffman commented 6 years ago

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.