Gutenberg Contributors Discuss the Drawbacks of Using iframes for Meta Boxes

photo credit: Closed square box, variation(license)

A lively and productive discussion regarding Gutenberg’s use of iframes for meta boxes is happening on GitHub. Yesterday, WordPress developer Kevin Hoffman created an issue titled “Are iframes a viable long-term solution for meta boxes?

Gutenberg 1.5 introduced initial support for meta boxes. Hoffman identified several issues with iframes that have been popping up as developers have begun testing the current meta box implementation. He did some performance testing that revealed Gutenberg’s use of iframes triples the number of asset requests, as it enqueues all of the CSS and JS assets in the parent window as well as in all the iframes.

image credit: Kevin Hoffman

“Generally speaking, iframes have been discouraged in web development for many years for reasons that are well-documented,” Hoffman said, before citing a litany of issues that plugin developers have already discovered in testing Gutenberg’s meta box support. “Can these issues be addressed without requiring modification of the theme or plugin that generates the meta box? We have to consider that third-party code that has powered meta boxes for years may not have the luxury of being updated in order to be compatible within an iframe.”

Gutenberg design lead Tammie Lister responded to Hoffman’s concerns, indicating that the current implementation of meta boxes is simply an experiment and not necessarily what would land in WordPress 5.0:

It’s good to think a little that what we have today for meta boxes in Gutenberg is an experiment, in many respects it’s a holding pattern as the project works out the direction to take. In saying that it’s one that works ‘for now’ but isn’t what we would ship with.

All the above said, I think it’s important to look at what in the future metaboxes will be used for. What are the cases (if any) that would not be converted to blocks? Do all metaboxes have to work on mobile? Is there even an alternative interface that we haven’t explored? I bet there is. Right now, it’s about looking at those possibilities and getting on a road that works for the state right now and the future state.

The presentation of this implementation as an experiment that “works for now” (but would not be shipped) comes as a surprise after Gutenberg 1.5 arrived with the announcement that “this release includes long awaited meta-boxes support (needs testing!)”

Hoffman contends that the iframe approach doesn’t even work ‘for now,’ as the issue was opened in order to cite several major ways where it is broken. If Gutenberg moves forward with the current approach, it would require many plugins to be modified in order to be compatible with WordPress 5.0, which Hoffman said would defeat the whole purpose of supporting legacy meta boxes.

“I have not seen any evidence to date that suggests meta boxes will continue working with Gutenberg,” Hoffman said. “If the answer is no, then we ought to stop pretending that 5.0 will be just another WordPress release and start being honest about breaking backwards compatibility.”

Edwin Cromley, a collaborator on the project, said that the team anticipates that certain themes and plugins will be broken and that it is not possible to accommodate every possible use case. He admitted that the iframe solution may not meet the project’s goals. Instead, he advocates creating the best experience for the vast majority of users.

However, the current approach would adversely affect many sites out there that use WordPress primarily as a CMS with meta boxes. WordPress core committer Scott Taylor expressed concerns about custom post types, many of which do not make use of the traditional “content” section in favor of meta boxes only.

“In this current iteration, meta box support is an add-on, when in many people’s reality, meta boxes ARE the UI, the API, the mechanism they use to compose their CMS,” Taylor said. “iframes are the gulag.

“And we are forgetting the values WP has been built on forever: I should be able to update to the latest version of WP, and have to rewrite nothing. I have so many projects in the wild on WP that I will never touch again. Can I be confident that some of them won’t break wildly with this change?”

Hoffman advocated scaling back the scope of the project to focus on the editor component, a popular opinion that many plugin developers share and one that was illustrated in detail in Yoast’s post proposing an alternative approach to Gutenberg. This approach stages out the changes to the edit screen, giving developers more time to update their plugins, as well as allowing the Gutenberg team to find an adequate solution for meta boxes.

“I think that goal would be a lot more achievable if Gutenberg stuck to overhauling the editor rather than taking over the entire page,” Hoffman said. “Then we could leave the existing hooks in place and meta boxes could continue to communicate with each other as they do now. Also, asset enqueuing would be a non-issue since it would work as it does today.

“I’m in strong agreement with this concept put forth by Yoast, which seems to me like it would maintain much of the work already done while scaling back the scope of the project to focus on the editor component.”

Gutenberg engineer Riad Benguella indicated the team is not too keen on working towards this concept.

“Reusing Gutenberg pieces to build this concept is relatively doable, but this is not the UX we want to optimize for, we want to build the best possible editor first and make it available for people without backwards compatibility concerns (fresh installs, no metaboxes…),” Benguella said.

“When we think the ideal vision of Gutenberg is ready to ship, we’ll have time to discuss upgrade path strategies, a concept like this one is an option for an upgrade path, but definitely not as the final product. Other upgrade paths are also possible.”

The WordPress developer community is not, however, in favor of delaying this discussion once again. Many are eager to finally answer the question of how meta boxes will fit into the context of the Gutenberg editor so they know how to prepare. Given the numerous issues with the iframes approach, rendering legacy PHP meta boxes under the new editor will require more experimentation and possibly an alternative solution.

“Why devote thousands of hours into developing the ideal editor if it cannot be made compatible with existing sites?” Hoffman said. “If the first impression is that it breaks the UI they depend on, users will never experience the ideal editor in the first place.”

“I think it may be a mistake to put this off too far,” WordPress core committer Aaron Jorbin said. “Especially since many organizations are going to need at least 1-2 quarters to prepare.”

Mark Kaplun suggests the Gutenberg team use a popular plugin as a gauge for the success of current and future meta box support experiments.

“My productive suggestion, is to not declare meta boxes ready, as long as Yoast SEO does not properly work in it,” Kaplun said. “It is both slightly complex in terms of interactions and it is installed on shit loads of sites. If Gutenberg cannot work with it, probably no one is going to use it.”

Greg Schoppe, who has tested and written extensively on Gutenberg’s ongoing development, joined the conversation to advocate for Yoast’s alternative approach to the project as well.

“I highly support Yoast’s view of Gutenberg,” Schoppe said. “It is unclear to me how ‘upgrade the visual editor’ was reinterpreted to be ‘replace the entire post edit interface’ by the Gutenberg team, but it seems directly at odds with the so-called ‘Ship of Theseus.’

“In this case, the lack of clear direction and support for the existing standard workflows is actively hurting developers now. How can I move forward building a project, without a trusted set of hooks and tools that I can rely on? It is unconscionable to think that such a large software project would entirely upend the standard workflow for developers in a single update. and it is insane that these conversations are just happening now, in November, when the plan is to have a merge approved at the beginning of the year.”

The discussion regarding the iframes approach to meta boxes was opened yesterday is still relatively new, but so far the Gutenberg team’s responses have failed to adequately address the concerns of the developer community in this thread. Finding an approach to meta boxes that preserves WordPress’ powerful CMS capabilities, without alienating users and developers, is one of the Gutenberg team’s greatest challenges. They are still aiming at producing a merge proposal early next year, but with meta boxes still in the experimentation stage, the team’s anticipated timetable continues to put the project at odds with the WordPress developer community.

54 Comments


  1. Mark Kaplun suggests the Gutenberg team use a popular plugin as a gauge for the success of current and future meta box support experiments.

    “My productive suggestion, is to not declare meta boxes ready, as long as Yoast SEO does not properly work in it,

    Agree, but please do not use one single plugin like Yoast SEO as a gauge as it does not focus on creating data, instead select a number of plugins that cover different use cases and are implemented differently.

    For example ACF (Free + Pro) should be a strong candidate (completly broken now), also plugins for creating multilingual sites or supporting custom workflows.

    Report

    Reply

    1. I agree. Selective success stories are how we end up moving too quickly and getting ahead of ourselves. For example, one might test Gutenberg with WooCommerce (where the meta boxes save data correctly) and wrongly assume that they work everywhere.

      The level of insight, resources, and expertise that a company like Yoast has available mean they will be able to create a working product regardless of how much adaptation is required. The majority of WordPress site owners are not as fortunate. That’s why it’s critical that everyone actually test Gutenberg as it develops, and not just follow along in the headlines.

      Report

      Reply

      1. Upgrades create breakage. 4.8.2 and 4.8.3 probably introduced more breakage than a major release does. The fact that someone can write some code to get into compliance with GB, do not mean that people are going to upgrade to the latest version of the plugin (plugin upgrades are notoriously breaking things) while they might upgrade to latest wordpress. For yoast. based on the stats here https://wordpress.org/plugins/wordpress-seo/advanced/ more than 50% of the users are not even in the ballpark of the latest versions.

        For those 50% GB will mean an immediate breakage and for whatever reasons they might not be in the position to upgrade the plugin.

        I can go for hours about how bad GB core design is, but it is pointless to judge the project against unreachable goals of supporting every plugin under the sun, and you need to set some concrete goals you can work against. Not having concrete goals is one of the fundamental problems of GB (and many other core features as well). When you do not have concrete goals you either get substandard solution (iframe for meta boxes) or feature bloat.

        GB goals should be first to support all the editor relevant APIs, mainly wp_editor, but also the JS API to the editors, or at least have an upgrade path to where APIS have to be broken. Once this is done and the GB editor component can be used anywhere where bare tinymce did, you can move to focus on other things.

        Report


      2. There’s a middle ground between supporting every plugin under the sun and guaging readiness based off the compatibility of a single popular plugin. I thought the initial metric of 100k installs would ensure sufficient testing, but Matt has since changed that metric to the number of published posts, which does not ensure the same amount of variation in testing.

        Report


      3. I thought the initial metric of 100k installs would ensure sufficient testing, but Matt has since changed that metric to the number of published posts

        It is at least a measurable goal, and I would agree that if there are 100k posts which were written in GB than the feature is ready to be considered for merge. Obviously at the current state of the plugin with explicit warning against using it on production this goal is not going to be achieved in 2018.

        I, and many other people, complain about how backward compatibility holds back wordpress (php 5.2 anyone?). It will be hypocritical for all those people to shoot down GB just because it breaks backward compat. The problem for me is not that there will be a reduced or broken experience for some sites, the problem is that there is no forward path, supported with explicit APIs, right now for yoast and anybody else to rewrite its metabox in GB compliant way even if he is willing to put the resources into it.

        Report


      4. I thought the initial metric of 100k installs would ensure sufficient testing, but Matt has since changed that metric to the number of published posts, which does not ensure the same amount of variation in testing.

        Kevin, to me it’s not a binary thing, it’s just which is going to get us the widest array of feedback. As you point out, 100k posts on sites with no plugins isn’t going cover everything, neither is 100k sites with no posting activity. :) Any metric taken in isolation is going to be insufficient, what I’m advocating for is we take the success action of using Gutenberg (publishing) into account versus just the number of people that have it installed and active.

        It’s definitely something we’ll discuss more when everyone feels like Gutenberg is ready for more mainstream and widespread testing.

        Report


      5. Matt, thank you for clarifying. We could really use your input in this meta box discussion. Different Gutenberg contributors are communicating different visions for where meta boxes fit in the future of WordPress, and there is no sign of development slowing down to reevaluate or course correct. The issue is open for discussion: https://github.com/WordPress/gutenberg/issues/3304

        Report


  2. Wow, it’s more and more beginning to look like we’re racing headlong to a big fork in this road.
    Unintended consequences and all that good stuff.

    Report

    Reply

    1. Yes, a fork is an ever looming possibility, I suppose. However, I’d like to see all the blogging specific aspects of WordPress removed from core and turned into a plugin. Then if Gutenberg also remained a plugin then WordPress users would get these choices:

      1) Use WordPress as CMS only with TinyMCE – No Gutenberg, Blogging or Jetpack support without the relative plugin having been installed.

      2) Use WordPress as CMS Only with Gutenberg as TinyMCE Editor replacement only – Gutenberg support added via plugin but no Blogging or Jetpack support installed by default.

      3) Use WordPress as CMS + Blog with Gutenberg as TinyMCE Editor replacement only – Gutenberg, Blogging and Jetpack support all added via plugin installed by default.

      4) Use WordPress as Blog Only. Gutenberg, Blogging and Jetpack support all added via plugin installed by default. This package would also include a new plugin to disable the features such as Metaboxes, custom fields, the Pages post type, the CPTs functionality and enable the Gutenberg plugin to run as a Full Edit Screen replacement. This would be the least complex edition and potentially excellent for beginners, medium lovers, etc.

      These possibilities could be offered as pre-configured packages so people could just use the one they want without having to add the plugins after the fact. The one WP edition for everyone is perhaps just not a good option anymore.

      WordPress also doesn’t need to get forked for this sort of thing to happen and it democratizes things far more than ever before.

      However it’s becoming clear that that’s no longer the mantra that WP follows anymore. The lowest common denominator user shouldn’t dictate the use case for anyone.

      Report

      Reply

      1. Matt, I think your assessment is correct and that the specific use-case has to guide development from now on. Milan Petrovic also makes some good points in his following post, which are worth noting.

        Report


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

    I think this is a bad comment that pulls all the efforts back to the beginning. There’s a very long issue on Github discussing about the needs of meta boxes for WordPress as a true CMS.

    I love the alternative way that Yoast team proposed. Sadly, the development team still want Gutenberg is a replacement for the whole editing “screen” instead of “editor”.

    Report

    Reply

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

    The fact that core devs are asking themselves these questions in the first place is a sad indication of how far removed they are from what thousands of people are doing with WP as a CMS.

    Report

    Reply

    1. Precisely…

      ‘(if any)’

      Seriously, from the design lead…. inconceivable!

      Report

      Reply

      1. The “if any” doesn’t worry me at all – I’m very happy for the Gutenberg team to continue to work towards understanding the possibilities that block based editing brings.

        Report


      2. Neil – they’re a year into it. Frankly, if by now someone doesn’t understand the importance of metaboxes and how they might be used, I question whether they should be leading this effort. I don’t mean that they should know all possible uses, but they should understand enough that they aren’t wondering if there are any that might not convert to blocks. Now, if they’ve surveyed the field and see that all kinds of metaboxes including those done with ACF, etc can be converted to blocks that’s awesome. But then let’s put that as a stake in the ground as a release criterion.

        I’m fine with the idea that metaboxes would all become blocks – that makes a lot of sense. But it needs to be a fairly easy, robust process for those of us who’ve created these sites for clients.

        Report


  5. The fact that this discussion is taking place now, after the full year in development, shows had badly this project has been managed. Things like this should have been discussed before the first line of code has been written. And, I agree with Robert saying that core developers are out of touch when it comes to the way WordPress is used.

    No matter what anyone from the Core team says, Gutenberg started the way it started because of the needs of WordPress.com not the WordPress as a whole.

    I can’t remember a project for client I worked on in the past 5 years that used WordPress as a blog, and when I go back to all these projects, Gutenberg can’t be used with any of them, because most of them don’t need editor at all, but they have 5 or even more custom meta boxes for building content.

    Well, it is not too late, current Gutenberg can be used to build a new solution that maintains compatibility with old WordPress versions and all the existing plugins, but limits Gutenberg to content editor, improve edit screen layout and make sort of a hybrid between current edit screen and Gutenberg, similar to what Yoast team proposed. And, make the Gutenberg optional, so when the post type is registered, we can pick between ‘Classic’ and ‘Gutenberg’ editor. This will also open a door in making WordPress ready for different new editors.

    And, scrap the plans to include Gutenberg in 5.0, develop and deliver WordPress 5.0 on the normal schedule in March or April, and leave Gutenberg out until 5.1 or even 5.2 (call it 6.0 if needed, but don’t make WordPress wait for Gutenberg).

    Report

    Reply

    1. The fact that this discussion is taking place now, after the full year in development, shows had badly this project has been managed. Things like this should have been discussed before the first line of code has been written.

      To clarify, this discussion has been taking place pretty much from the inception of the project, as far as I can recall.

      Seems to be a controversial opinion, but I think the project has been very well managed. If everything was on hold until every piece was “perfectly” planned and discussed ahead of time, we would not be having this discussion, and in many ways would be much further from achieving the goals of this project as we stand today.

      By creating the experience and solving problems alongside discussion and planning, it allows for a project to evolve continuously and validate any ideas with real world implementations, rather than theoretical plans.

      This style of creation leads to “incomplete” features shipping, like meta box support. For the most part, despite what it would seem, most meta boxes actually do work well for most cases with the recent changes and I am certain they will be improved upon in the coming weeks, as has everything about Gutenberg.

      scrap the plans to include Gutenberg in 5.0

      My understanding is that 5.0 ships when Gutenberg ships. The more effort we can put towards making it the best thing possible, rather than burning it down, would be energy better spent.

      Report

      Reply

      1. Seems to be a controversial opinion, but I think the project has been very well managed. If everything was on hold until every piece was “perfectly” planned and discussed ahead of time, we would not be having this discussion, and in many ways would be much further from achieving the goals of this project as we stand today.

        That’s a red herring. No one is advocating that everything be perfectly planned, but metaboxes are a critical feature, widely used in a lot of sites. They’re NOT some minor thing that can be dealt with partially and fixed in 5.x so, yes, approaches for this should have been thought of earlier and while the team might not want to give this impression, it feels like they don’t realize just how central metabox support is to a lot of sites.

        AS for 5.0 shipping when Gutenberg is ready… do you really think we’ll get 4.9 in a few weeks and then nothing for a year if Gutenberg takes that long? I’d LIKE to think the team is prepared to do that, but have we even seen any desired timeline?

        Report


      2. I have tested Gutenberg metaboxes support, and it does work with some plugins, but it is not working with a lot of plugins, ranging from JavaScript errors, styling issues, not saving data properly, to completely broken.

        And, due to the use of IFRAME, pages are very slow loading (everything is loaded twice, for the main page and for the IFRAME), and there are many more issues. To make things worse, use of IFRAME causes problems with in-browser debugging.

        Gutenberg is far from well-managed project. If it was managed properly, metaboxes and other compatibility issues would be discussed before the work has begun, and not after a year of development that all involved knew will be impossible to support metaboxes properly.

        IFRAME is not a solution, and right now we are looking at a high percentage of broken websites.

        There are so many things that WordPress development involves, and the editor as it is now, can’t be considered a priority. And, holding off the WordPress development for the unspecified amount of time until Gutenberg is ready is just wrong. WordPress 5.0, 5.1 and maybe 5.2 should happen on schedule, and Gutenberg might be ready by the end of 2018 for merge. Holding of 5.0 for a whole year is a very bad solution.

        And I don’t see any way for Gutenberg getting merge ready before the end of 2018, considering it’s current state and severe lack of testing.

        Report


  6. It’s great to see comments around this as it shows people want to find a solution, you are being listened to.

    As the design lead of Gutenberg I also want to find a solution to metaboxes, whatever that approach ends up being. I myself want to remain open minded about what that solution may be and try approaches. That’s one aspect of Gutenberg has worked for us so far, trying this and prototyping. That is what is happening right now.

    What we have today is one way metaboxes could work. To find out all the stress cases (they are stress not edge cases as cause stress) and what works even more non-stress cases for metaboxes we need to test. There’s a lot more testing going into metaboxes in Gutenberg now it’s live, over when it was a PR or theoretical discussion on GitHub.

    The fact that as designers of a product, predicting correctly all cases (stress and otherwise) is impossible, that’s usual for a product. That is why we all test, prototype and iterate. You ask the same questions each stage of the product (even up to release), because a new solution may present itself as you work. This is exactly what my comment was referring to. Now we’re testing we can move beyond the predictions, the research and see what does or doesn’t work.

    Report

    Reply

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

    This is just crazy thinking. There are so many use cases for meta boxes outside the editor context I wont even try to list them all.

    Report

    Reply

    1. A meta box at its core, is just a visual piece of UI for interacting with something in WordPress. It may seem crazy, but the reality is that most likely all meta boxes will be replaceable with blocks, and with the client rich experience being provided by blocks, most meta boxes, if not converted, will probably eventually be made irrelevant by a superior block implementation by another vendor.

      It is definitely hard to see how that would work, but I will definitely be posting some examples on my blog before the end of the year to show how meta boxes can be re-envisioned as blocks, and why it would possibly be a better experience for everyone.

      Report

      Reply

  8. The presentation of this implementation as an experiment that “works for now” (but would not be shipped) comes as a surprise after Gutenberg 1.5 arrived with the announcement that “this release includes long awaited meta-boxes support (needs testing!)”

    Is there the equivalent of a product manager on this? Because it sure as heck seems not and I’m starting to wonder about the rather startling naiveté around things like the use of metaboxes.

    Edwin Cromley, a collaborator on the project, said that the team anticipates that certain themes and plugins will be broken and that it is not possible to accommodate every possible use case.

    This is dangerous thinking and Hoffman is right. If this is allowed, WP 5.0 CANNOT be present as just another dot release upgrade. Doing so will break sites and if Matt/Automattic are seeing Gutenberg as a way to maintain and increase market share, they’ll be doing the opposite.

    Report

    Reply

    1. Is there the equivalent of a product manager on this? Because it sure as heck seems not and I’m starting to wonder about the rather startling naiveté around things like the use of metaboxes.

      Yes there is a Design Lead, Tammie Lister (formerly Joen Asmussen), and a Technical Lead, Matías Ventura. Gutenberg is an ambitious project. Under their leadership and management, Gutenberg has come a considerable ways in a very short period of time. Not everyone approaches product management the same way, and it is hard to be everybody’s cup of tea. The controversy surrounding the project is somewhat correlated to the management practices involved which are prioritizing project velocity.

      Most people are not used to seeing the rapid iterative approach being taken where “incomplete” features are shipped. If we step back to the beginning, many people complained about the lack of stable saving, or use of standard WordPress settings, or oddities in the writing experience. There are far, far less complaints about this now, and the same will be the case for meta boxes. It is all just a matter of time.

      This is dangerous thinking and Hoffman is right. If this is allowed, WP 5.0 CANNOT be present as just another dot release upgrade. Doing so will break sites and if Matt/Automattic are seeing Gutenberg as a way to maintain and increase market share, they’ll be doing the opposite.

      To clarify, when anything is changed, it is potentially a breaking change. There is no concerted effort to break sites, in fact any breakage is actively being minimized to great extents. I do not share your same level of foresight, but it would probably be even more tragic if Gutenberg was not a project widely available for all WordPress users. Rather than looking at Gutenberg as it is in this instance, look at its track record of improvement and acknowledge that it is heading in a positive direction.

      Report

      Reply

      1. Most people are not used to seeing the rapid iterative approach being taken where “incomplete” features are shipped.

        Thanks, I’ve been involved in software development since the early 1990s. I’m intimately familiar with iterative approaches as well as more structured, waterfall-style ones. Methodology blinders aren’t useful here.

        The controversy surrounding the project is somewhat correlated to the management practices involved which are prioritizing project velocity.

        Velocity isn’t always the right thing to prioritize and when dealing with the core reason for WP to exist (content creation and management) getting it right is FAR more important than delivering it quickly. Why not use an approach like the team did for the REST API – iterate in a feature plugin that’s not coupled to a release, get feedback, refine and then merge? Sure, target a desired release for merge, but don’t gate that release on the new feature. Why is this tied to a release (and not just SOME release, the NEXT one?).

        Look, I certainly hope Gutenberg straightens out and worked great. I think that, if well executed, it has a lot of potential. But the uncertainty around such a major feature leaves those of us building sites for paying clients in a quandary if we use ACF or similar. Do we build a new site that way? What if despite all of this, such sites break in 5.0 and break in such a way that it’s a non-trivial fix? What about existing customers… if they can’t be upgraded to 5.0 because of breakage, what’s the path forward?

        That’s why the iterative, we’ll play with this and refine over time approach is worrisome. There are thousands of us who build businesses doing this and we need to consider whether or not to stake our 2018 business to WordPress over the next year or if we should use an alternative or if we need to lock things to 4.9 and hope that it will settle out.

        Finally, to reiterate, the need for first class meta box support is not new. It’s been raised, repeatedly, for a year now and we still dont have a way forward. The team seems resistant to the feature plugin approach I mentioned earlier and also resistant to scaling G back to covering only the actual editor. That resistance, coupled with the year long debate, coupled with the uncertainty all of this brings, has me spending time I don’t have looking at alternate CMSes just to make sure I’m not caught out if the rosy scenario doesn’t happen.

        Report


  9. As a contributor to the LONG GitHub discussion about Metaboxes and developers needs around them this is a real kick in the teeth. We’ve been trying to communicate with the core team about the use cases and needs for months.

    We keep getting told “don’t worry we have plans, it will be alright” – well now it’s time to show us the plan and the leadership.

    There are two options as I see it. Either admit that this is a huge, potentially website destroying issue and publicly decouple Gutenberg from 5.0 release scheduling so there is time to sort it out. Or come up with a plan, communicate it and get developers on board working on updating plugins.

    The magnitude of the problem/task ahead is completely incompatible with the outlined timeframe for release. If the core team persists with this approach I can see sites we maintain being stuck on WP 4.9 for years to come or WP being forked.

    Report

    Reply

  10. I don’t mind Gutenberg editor for writing content. I just don’t like the blocks for all things message that some of the Gutenberg team are pushing at the moment. I would not want to be editing a WooCommerce product with blocks.

    The Yoast suggestion respects what people might have done with meta boxes. As an ACF user, I often disable the editor entirely on custom post types and place field groups in specific locations. It feels to me that the Gutenberg editor is hijacking the editor screen with no respect for what another developer would have done.

    Report

    Reply

  11. You know… this entire fiasco of a project has pushed me to do something I’ve been thinking of for awhile. I’m spending this weekend looking at alternatives to WP.

    I develop fully custom sites that make heavy use of things like ACF metaboxes and entirely custom themes and from the comments I continue to hear about backward compatibility, how to use metaboxes and more than anything from the apparent complete lack of product management, I simply can’t trust that 5.0 will not break things in fairly basic ways.

    I’ll lock current client upgrades to 4.9 when that releases and evaluate what to do as Gutenberg evolves, but I’m leery of doing new, substantial projects on a platform with this much uncertainty around something as basic as how content is managed.

    Report

    Reply

    1. I’ve been doing the same thing this weekend, prompted by choosing to withdraw recently from an upcoming project that was to be built on WordPress. This particular client was very understanding, thankfully.

      However, I’ve recently reached out to a different client about a project that was completed in June this year, and I’m expecting a very different reaction. This is a not-for-profit that could only pursue their project in the first place due to a very generous donation. There is absolutely no way they are in a position to pay for remedial work to upgrade data-heavy admin screens to make sense with a Gutenberg workflow. Even though I’m offering to do this work for free, I’m bracing myself for (justified) anger on their part.

      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?

      I completely agree with Anh Tran, this comment is incredible considering the now multiple threads on why attention to existing (not future) metaboxes is critical. Another recent comment by one of the core developers is beyond my comprehension:

      The main difference is that ‘Metaboxes’ have no ‘purpose’

      https://github.com/WordPress/gutenberg/issues/3304#issuecomment-341922758

      Report

      Reply

  12. I have started to wonder if anyone on the core team has developed sites with WP as a CMS for a paying business client.

    I mean: as a small two person agency where a client comes to you and says “We need a system which can allow the team to enter property data with 50 fields of location data, etc. It must integrate with Sage and an existing app our sales team use, oh, and integrate with our affiliates, oh and several other integrations I forgot to mention.”

    One of those jobs. One of those jobs which is maintained by a rotating staff of interns and harrassed managers, and if their email stops working they blame the webdeveloper. Have they ever had one of those careers? Because I do.

    One day soon I will have to tell my clients “You need to pay me to rebuild everything. No, I don’t yet know how this ought to be achieved (as that is not yet decided) but it will need to be done in the next quarter, and it’s not my fault, yes you must pay me. No, I cant explain why this is happening, I know I said Wp was good, but now it all has to change.”

    Has the Gutenberg team ever had a build and maintenance contract on say … 40 to 50 of those sort of CRM jobs? Have the team ever met a client face to face? It seems as if the team came out of a Comp-Sci university degree straight into the ivory tower of code-for-code’s sake.

    It looks really bad from here. I really hope I am wrong.

    Report

    Reply

    1. Agreed. It’s why I’m stopping upgrades at 4.9 until and unless this mess gets straightened out and I’m spending time over the next week trying some other CMSes for use going forward.

      But you (and I) will still need to explain that to the client; “No, we don’t want to upgrade to 5.0. Why not? Well, the editing experience is totally different and…” Yeah, that’s a conversation to have. Even that is a temporary solution – at some point, we need to either redo their site to work in WP 5.x (or 6.x) *IF* possible… or move to another CMS.

      From everything I’m reading here and on the Github issues, the core team simply does not get the world you, I and many, many others live in. There’s a rather arrogant comment on the Github thread that they should just build the best editor possible and then worry about compatibility. From a core contributor. Sorry, but that’s not OK and if one contributor has that attitude, you know others do.

      This project lacks a product manager and really is exposing the downside of developer driven design. I don’t mean UX design which looks like it’s getting attention – I mean product design where the impacts on the real world customer base, including the clients of people who’ve built businesses on WordPress – are accounted for.

      Report

      Reply

      1. at some point, we need to either redo their site to work in WP 5.x (or 6.x) *IF* possible

        I do not think that it would be a viable option as all the cons reported by the community seem to be neglected. Why would this change later?

        Responsible devs who are building WP sites for real clients simply can not afford that level of uncertainity that is coming because of the Gutenberg project. Luckily in the last year i only had 1 WP project as i moved to another CMS earlier. Stopping updates at 4.9 for my old clients sounds a good idea, that’s what i will do as well.

        Report


      2. For that job, and to resolve these issues, you need someone with real marketing chops.

        At the moment, as with several other issues over the years, it feels very much like the inmates have taken over and are running the asylum again.

        Very soon WP is going to reach the tipping point where it will have reached peak installs ~ in the techy/dev market ~ and will need start learning how to convince normal folk that WP is worth them investing their time to learn.

        That won’t happen with GB the way it looks like its going right now.

        If GB does deliver on its promise, everyone wins. But, right now, its far too early to say how it will look and work in its “final” form.

        Be that as it may, by far the THE BEST approach would to choose one of the options Matt put forward regarding GB as a plugin, and/or to investigate further how the Yoast alternatives might work.

        But by far THE WORST alternative would be to blunder on with the GB devs in denial, and a one-size-fits-all approach to WP 5.

        Report


    2. I have started to wonder if anyone on the core team has developed sites with WP as a CMS for a paying business client.

      That went through my mind when Matt bought the *.blog TLD

      Very strange.

      Report

      Reply

  13. What I find most surprising in all this is that the core team don’t see a problem with Gutenberg potentially breaking and crippling thousands and thousands of sites making extensive use of meta data and on the other side they are scared as hell to break some ancient and most probably abandoned sites by bumping WP minimum PHP requirements to at least 5.3.

    Report

    Reply

  14. From Matt Cromwell in the thread:

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

    Replied by Tammie lister with:

    ‘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 think this is seriously underestimating the support for a Fields API. Especially considering that the biggest obstacle and concern for everyone is Metaboxes.

    I’m pretty sure, if given a fields API, most serious developers would be very happy to redevelop their plugins and themes for it. And it would pave the way for Gutenberg to not be such a clusterfrack.

    p.s. Craft is looking more interesting by the day.

    Report

    Reply

  15. Hey, seems some people can continue to develop the very best editor on the whole world for their own. :-) Great effort but the real world and uncountable WP sites simply are not compatible with the way how some develop GB.

    It is simply ridiculous that in about 5 months WP 5.0 will get released and apparently with GB (on by default) the most of the hooks thousands of devs and millions of WP sites rely on will be simply removed all of a sudden. I really hoped that you are just kidding, but as i read there are GB team members who think WP must get rid of metaboxes. I bet you also want to get rid of custom fields as well.

    Well… you could do all these if WP was just a blogging platform but it is widely used as a CMS. You could even do all that if the sitedev could define the structure of the database like in drupal, but in WP one simply can not do that.

    You even could do all these if GB would just replace TinyMCE but no… it simply MUST replace everything and without at least an acceptable transition period. I find it a really strange way.

    Responsible devs who are building WP sites for real clients simply can not afford that level of uncertainity you can apparently afford as core devs. So don’t just wonder if WP will loose a huge share on the market and at the end it will revert back being only a blogging platform thanks for the best editor on this planet (and your truly incompetent manner of developing software).

    Report

    Reply

  16. The worst part of this whole fiasco is the mixed messages we get from the Gutenberg team.

    Matias wrote his famous “Ship of Theseus” post, saying:

    It doesn’t seek to remove existing functionality—shortcodes still work the same way—but introduce new ways of interacting with the content. It is an attempt at improving how users can connect with their site in a visual way, not at removing the flexibility and power that has made WordPress thrive. There might be a time when the old ways become obsolete and disappear, absorbed by the richer and clearer interface of blocks, but we are doing as much as possible to make this a process. The old doesn’t have to disappear suddenly, it can be gradually shaped into the new.

    But then current design lead, Tammy Lister, says this in a thread on GitHub:

    One of the big issues with WordPress in the past from a design perspective has been a spiral of small iterations on top of small iterations. Whilst it works for the first few, over time it adds up to an experience held together with patches of improvements. There’s a lot of WordPress that suffers from this. Editor is one, media is another and there are a whole lot more able to be pointed to.

    Gutenberg has given us space to remove the patches, to look at what we have and build up again. It’s given us as a result the start of a strong visual language to move into Customization and beyond. To actually have a visual language that moves WordPress forward into the next 10 years. Yes, we have to think that far ahead.

    These two views are completely at odds with each other, and to those paying attention to the project, with an eye towards how it will hurt their livelihood, the overall impression is a lack of common, systemic values across the Gutenberg team.

    All this, with the continued confirmation that Gutenberg WILL be in 5.0 is simply exhausting. If there is no possibility of failure, then how can any outsider reasonably expect their input to be heard? Very few plans survive first contact with reality, and the Yoast proposal is a good compromise, with room to expand in future versions, but if there is no way for the Gutenberg team to fail to merge, then why should they feel the need to take a scaled back approach seriously?

    As for me, I’m not so worried about WordPress being irrelevant in 5-10 years. This whole process has me re-evaluating the platform that i love NOW.

    Report

    Reply

    1. That’s why I keep harping on the lack of a product owner. There’s no one to step in and dictate that THIS is the direction so we keep getting mixed messages.

      Report

      Reply

  17. JC mentioned Craft as an alternative. What other alternatives are being seriously considered. I’m extremely nervous to move forward with WP even though I’ve been on the WP train for 13 years.

    Report

    Reply

    1. These articles mention some: Link1, Link2
      To sum it up if you are interested in a platform that even the client can easily use after the development is done than Jekyll, Craft, Contao or Ghost are worth to try.

      If you need something more advanced you might consider drupal 8.4, joomla or typo3. These might be however too complicated for some clients to put new content inside.

      The beauty of WP was that it had a really good balance between these 2 weight classes, but this balance was lost somewhere at WP 4.1 and if GB will be released as we were told until now, then soon WP will be a real rough and unpredictable adventure for the client. I am really sorry to say all that as WP has made me everything so easy in the past.

      Report

      Reply

      1. Perch Runway is also a contender (Perch itself is for smaller sites, Runway is their offering for more complex, content-rich sites).

        Report


      2. I’ve never used Typo2 before, but Drupal is definitely a learning curve which I’ve tried, and Joomla is actually not that difficult. Intimidating at first but once you get used to it, it really becomes easy. I have 10 years experience with Joomla and in the past I’ve had web design (WordPress) clients who needed to build more than just blogs, so I introduced them Joomla and many of them never looked back at WP.

        As I posted a reply earlier, I’m fed up with the core WP, and even Automattic digging into .org, so I’m getting back and focusing on Joomla again. They actually listen to users.

        Report


    2. Sadly, right now, I think that there are no other CMS out there with the kind of community, plugin ecosystem and ease of development that WP has. Please, someone correct me if I’m wrong.

      Report

      Reply

      1. It depends what you need. Ease of dev – others are fine. I played with Perch Runway last night and it as well as Craft are both good. Neither has the ecosystem of WP but they have the basic stuff covered and frankly an influx of new people will only build that out. Plus, well, the WP plugin ecosystem is a mess – 50k plugins, but many are old, abandoned or duplicates of others in features.

        There’s going to be a learning curve and some adaptation if I move… but if I land a $5-15k project can I really use WP with the uncertainty around the editing experience and what it will and will not break? A project that size needs to be good for 2-5 years… I can’t go back to someone like that in a year and tell them I need thousands more to make the site work with 5.x or to move to another CMS.

        While I wish the core team would get that, ultimately I’ll do what’s right for myself and my clients. If that’s WP, great. If it’s not, well, it’s been a nice ride.

        Report


  18. The fundamental problem with Matias Ventura’s vision of building the very best editor first, and then seeing what adjustments might need to be made afterwards, is that he doesn’t seem to understand what the notion of “best” actually means.

    You can’t have something that is “best” in the abstract. It must be “best” for or at something or someone.

    No-one would claim that there is simply a “best” painkiller, or a “best” car or plane. Such a claim would make no sense unless we knew the type of pain and patient involved, what the car would be used for, or how many passengers would be transported and between which airports.

    Similarly, there can’t be a “best” editing interface without knowing what data it is intended to manage or who its intended users are.

    So, Matias – and everyone else on the Gutenberg team – please drop this rhetoric of “best” unless and until you are prepared to say explicitly who and what you are building this for.

    And please don’t think that a glib response like “We are building this for everyone” will wash. If that were true, you wouldn’t even have contemplated using iFrames for metaboxes.

    Report

    Reply

  19. Reading that many developers may freeze sites at WordPress 4.9 if Gutenberg goes core in 5.0, this is not surprising. The primary barrier for Agencies using WordPress for Client solutions was the RoadMap (meaning lack of a clear roadmap), according to our recent WordPress Usage Survey Report by WordPress Marketing. Despite their high satisfaction with WordPress, some agencies express concern about the lack of awareness of the CMS use case and backwards compatibility, as the Codex Support Versions clearly states: “There are no fixed period (sic) of support nor Long Term Support (LTS),” as is typical for most major software platforms.

    Report

    Reply

      1. On the one hand, yay. On the other…. a year in there’s no roadmap. And I get pushback about the management of this project….

        Report

Leave a Reply

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