Cancel

Sarah Gooding

Matt Mullenweg Addresses Concerns About Gutenberg, Confirms New Editor to Ship with WordPress 5.0

Matt Mullenweg published an appeal to WordPress users over the weekend in a post titled “We Called it Gutenberg for a Reason.” In it he offers a better look at his vision for Gutenberg, which he contends will be as transformative for WordPress’ future as the first movable type printing was for Europe’s printing revolution.

Mullenweg identified the new Gutenberg editor as the tool that will enable WordPress to meet its competition and the opportunities available in the small business sector:

WordPress’s growth is impressive (28.5% and counting) but it’s not limitless — at least not in its current state. We have challenges (user frustrations with publishing and customizing, competition from site builders like Squarespace and Wix) and opportunities (the 157 million small businesses without sites, aka the next big market we should be serving). It’s time for WordPress’ next big thing, the thing that helps us deal with our challenges and opportunities. The thing that changes the world.

Automattic has been moving towards offering better support for small businesses with its 2015 acquisition of WooCommerce and steady commercialization of Jetpack, with plans targeted at business owners. The company is poised to capture even more of the self-hosted small business market by allowing customers to tap into WordPress’ third-party ecosystem.

However, many vocal opponents to Gutenberg (and the changes that will come along with it) are concerned that the project is being developed chiefly to serve Automattic’s customers and corporate interests.

“Gutenberg has been mainly introduced by one particular company which seems to be in urgent need to compete with other SaaS businesses,” WordPress theme development company owner Michael Hebenstreit said. “That’s fine, but then keep it as a plugin for at least 1-2 years, put it on WordPress.com (to gather real live feedback and usage data) and nobody will have any issues with that approach.”

Mullenweg addressed concerns that Gutenberg is being developed for Automattic’s customers in a reply to a similar comment on his post.

“There definitely is a contingent that seems to think that, but if you think through it logically it doesn’t make sense: if it were just to benefit Automattic it would be far easier and more advantageous to just do Gutenberg unilaterally in Calypso, where it would primarily benefit WordPress.com,” Mullenweg said. “Doing it in wp-admin and core first involves a lot more discussion, public feedback, backwards compatibility concerns, and breaking a lot of new ground for how core uses Javascript, and because it’s in core the benefits will accrue to all hosts of WordPress, many of which directly or indirectly compete with Automattic. We are reading and trying to learn from all the negative feedback though, even when it’s from people who haven’t used Gutenberg much yet.”

Those who build websites for clients have voiced concerns about how Gutenberg will affect their businesses, whether the brand new interface will drive users away from WordPress. Developers and product owners are eagerly awaiting more answers on what it means for existing plugins and themes in the ecosystem, as the project has yet to iron out some of the more technical details regarding extensibility and support for metaboxes. This naturally raises concerns about Gutenberg’s timeline.

“Gutenberg will ship with WordPress 5.0, but the release will come out when Gutenberg is ready, not vice versa,” Mullenweg said. “We still have target dates to help us think about scope and plan for all the supporting documentation, translation, and marketing efforts, but we’re not going to release anything until Gutenberg is something the team working on it agrees is ready.”

WordPress users have been conditioned to anticipate releases on a regular schedule but the new approach to core development will allow for the next major release to wait until the targeted features are ready. Mullenweg confirmed in the comments of his post that Gutenberg will ship with a legacy interface to offer backwards compatibility for PHP metaboxes that have not yet updated to be JS-powered.

“Some things like toolbar buttons will definitely need to be updated to work with Gutenberg, other things like Metaboxes there will be no problem to provide a legacy interface for a few releases,” Mullenweg said. “But I would say that plugin authors should start updating their plugins in late September if they want to benefit from Gutenberg’s launch.”

One of the most prevalent concerns that remains is React’s licensing issues, which came to a head after the Apache Software Foundation added Facebook’s BSD+Patents license to its Category X list of disallowed licenses for Apache PMC members. Facebook’s engineering directors considered re-licensing the project but decided against it, citing “meritless patent litigation” as the reason behind adopting the BSD + patents license. The WordPress project has yet to announce its stance on the decision.

“We anticipated a decision on React around the Apache deadline (closer to now), will have more to announce about WP and Gutenberg’s approach here in the next few weeks,” Mullenweg said.

He also reiterated how invested he is in the WordPress project and ecosystem as a whole. His post elaborated on the many benefits he anticipates for plugin, theme, and core developers, agencies, users, and hosting companies. He challenged the WordPress community to see Gutenberg in the same light.

“My life’s work is improving WordPress,” Mullenweg said. “I firmly believe that Gutenberg is the direction that will provide the most benefit to the maximum number of people while being totally in line with core WordPress’s philosophies and commitment to user freedom. So keep giving us your feedback, and let’s push through the fear together. It’s worth a little discomfort to change the world.”

Category: ,
Tags: , ,
120

120 responses to “Matt Mullenweg Addresses Concerns About Gutenberg, Confirms New Editor to Ship with WordPress 5.0”

  2. First:
    Metaboxes, just leave my metaboxes alone, the kind of work i do, barely, if ever utilizes the content field anyway.

    Second.
    Divi: better than guttenberg
    Avada: better than guttenberg

    I am not excited about Guttenberg. Im sure Matt in his heart of hearts believes this is an essential step for WordPress.

    But seems right now, it only causes more problems than solutions.

    Create forum topic from comment

      • It should make sense, i’m not talking about the themes in themselves. But the page builders they are pre-packaged with.

        Both far superior to the current version of Guttenberg. Which I know is still in development phase and may improve drastically. But in it’s current state , i don’t see the value that Guttenberg project would add to a WordPress installation.

        You have a visual builder (sort of) in the backend in the form of Guttenberg. But the changes being made won’t be apparent or necessarily be the same as the one on the front end.

        Secondly there still is no grid layout system, so How exactly does it affect websites that aren’t blogs isn’t clear to me ( i would love an explanation).

        Create forum topic from comment

    • DIVI: shortcode littered
      Avada: Shortcode littered

      Anything that uses Live composer: shortcode littered

      how is this better?

      Beaver Builder, Elementor and Site Origin Page builder are more inline with WordPress methods.

      I think Gutenberg is good as it aligns WordPress with Drupal. Drupal has a lot of tools for page building and making fully custom sites without touching code. They meet enterprises needs all the time.

      Just need to iron out the details.

      Create forum topic from comment

    • First:
      Metaboxes, just leave my metaboxes alone, the kind of work i do, barely, if ever utilizes the content field anyway.

      As somebody who has written countless meta boxes over the years, I completely understand this mindset, though I think it illustrates one of the most common misunderstandings of the purpose Gutenberg aims to serve.

      Picture a typical page currently: it might contain a header, “content” section, sidebar, and footer. Within the “content” section you might see a title, post meta information about the post, some content, some meta information from a meta box, then perhaps an author box.

      Gutenberg looks to consolidate a lot of this stuff into one field via a block editor. And I can see how that might seem scary (and even in some cases unnecessarily complex), but try to imagine it from the authoring perspective.

      If you assume that certain elements, such as the title, info about the post, and the author box might still be handled by the theme, then all that’s left is what would traditionally be considered to be the “content field”, anything coming from post meta via meta boxes, and the sidebar, let’s say.

      If this were something like a product page, maybe there would be a lot more post meta fields in play. Either way, the same concepts apply.

      Doesn’t it make a lot more sense to not only configure the meta and widget information inside a block using standardized controls the user already knows how to use, but also place it where you want it in relation to any other content? The whole idea of the block editor is to get out of the mindset that content and meta are mutually exclusive. Together they represent content and should be managed in the same place.

      I recognize that the idea of redoing work with little obvious benefit sucks. Ultimately, though, there would be a solid benefit because you’d be participating in unifying the experience for your users. Bringing control of what to display where introduces an immense level of flexibility not currently possible.

      The meta box API and editor as separate concepts together represent the wild west of content authorship; Gutenberg represents the industrial revolution: combining the cart and horse into one unified machine.

      Create forum topic from comment

      • @drew, It is totally irrelevant how gutenberg might be used and if it is better or worse than the current arrangement (worse since you lose flexibility, and so far the JS produced by core is horrific and un-maintainable, but lets put it a side). The fact is that the community of theme and plugin developers do not want to put any effort into adjusting for gutenberg right now, which means that if gutenberg will be released right now nothing will work with it (is EDD ready for gutenberg?). People that use themes and plugins which are totally perfect for their site right now will not be able to upgrade to 5.0 since it will break their site, or at least workflow.

        Gutenberg is a huge step back from what made wordpress into a success, rigid limitation replace flexibility and hackability. I fail to understand how any developer can see it as a good thing.

        Create forum topic from comment

      • If this were something like a product page, maybe there would be a lot more post meta fields in play. Either way, the same concepts apply.

        @drew I don’t think the same concepts apply in cases like these. On a typical product page you are likely only to have a short paragraph description that may or may not require a WYSIWYG editor. The rest of it – pricing, sizing, image gallery, variations, etc – should all rightly be meta boxes.

        I could see an argument for a “modular” product page where you arrange blocks like reviews, video, gallery, etc but in my experience the client that prefers that level of creative control is the exception and not the rule.

        Then there are cases where you don’t need a WYSIWYG editor at all like in the case of a location post type for a store locator. Or cases where the post type is private so it can be used on other pages ( testimonials, staff members, etc ) but does not have a page of it’s own. A “pagebuilder” is completely counterintuitive here.

        I think the Gutenberg editor is great and will greatly improve the long form content editing experience in WordPress. I just want to make sure we’re not forgetting that not all content fits this mold. Meta boxes should ideally remain first class citizens and be allowed to live along side the new editor.

        Create forum topic from comment

      • Drew, honest question: how is Gutenberg going to “unifying the experience for your users”? With the current meta boxes, we have complete control over how everything looks and works. A page or any custom content editing page can contain a Title box, optionally a content box and all kinds of boxes right below that. With exactly the form fields needed to input the content and other info. With exactly the design that’s needed for that input. From a few simple text fields, dropdown elements, checkboxes, to really complex layouts as you see in Woocommerce, for example.

        And building that interface currently is very easy. Every developer with a bit of knowledge in HTML/CSS and PHP can do it. Pushing everything into Gutenberg will make things extremely more complex to build. Instead of a simple $_POST to the server of some variables, everything is going through a whole new React stack and complex content/markup language/system consisting of html comments.

        Create forum topic from comment

      • @Drew

        This is a great explanation. Gutenberg is about converting the need for discrete data—which meta-boxes provide—from one of indirect manipulation (you edit a field somewhere and you don’t know how your site will look after) into a direct and richer visual experience. It doesn’t treat meta-boxes as second class; it attempts to bring them front and center through blocks that are optimized for visual editing.

        Create forum topic from comment

      • Doesn’t it make a lot more sense to not only configure the meta and widget information inside a block using standardized controls the user already knows how to use, but also place it where you want it in relation to any other content?

        Holy cow, with respect, no. I totally agree that the current model needs improvement, and I see a lot of good in Gutenberg. The current rigid content box is unsustainable when the rest of the world is providing a better content-building experience.

        But folding custom fields into that? Letting users re-arrange
        where those fields appear? That would be good in a few instances, and catastrophic in others. Not every use case supports a content-building experience, and in fact most don’t.

        Basic example off the top of my head. A “book” custom post type. In your site’s design, there’s a left sidebar with meta info about the book (page count, publisher, release date, star rating), plus a central column with the book title, cover image, author, and synopsis.

        How do I build this, if WordPress removes custom fields and expects us to put everything in Gutenberg? How is the authoring experience improved when instead of filling out 7 fields and hitting publish, the author now has to rebuild a layout every time they want to add a book?

        These seem like really obvious and fundamental questions so as I write this I’m now wondering if maybe I’m missing something and Gutenberg has just been poorly explained. I have played around with it, though not for a few weeks.

        Create forum topic from comment

      • How is the authoring experience improved when instead of filling out 7 fields and hitting publish, the author now has to rebuild a layout every time they want to add a book?

        I am not sure what you mean with “rebuild a layout”. In this case, the user would click “new book”, and they would be presented with an editor that has already a “book title”, “book cover” (where you can directly upload or drag an image), “book author”, “book synopsis”, and “book information” blocks already laid as they would appear once published. The “book information” block would contain seven fields for those specific bits of information.

        Create forum topic from comment

      • From this exchange, I think I understand now why there is so much resistance to Gutenberg, and it basically boils down to those people working on it (including Matt and Matías) being unable to communicate properly how it will be used, and by who. Let me explain:

        Michael in his comment said:

        How is the authoring experience improved when instead of filling out 7 fields and hitting publish, the author now has to rebuild a layout every time they want to add a book?

        To which Matías replied:

        I am not sure what you mean with “rebuild a layout”

        This is the key of the issue: there is a miscommunication of how Gutenberg will be used (to create content? create views? create metadata?), and by who (the client? the developer?). So far, Gutenberg is still an idea, since there is no proper documentation about it, and the preconception of how Gutenberg will be used is different in each person’s head.

        So, going back to Michael’s comment, this is what I assume he had in mind:

        Who:
        – the final user (as in, a client filling in content, with no IT skills)

        How:
        1. The user creates a new custom post “Book” on the editor
        2. There is nothing on the main window, just an empty space
        3. The user needs to add all blocks that represent the book only to fill its content (that is what he means by “create the layout of the book”), in this case he has to click on “Insert block” to insert blocks “title”, “cover image”, “author”, and “synopsis” one after the other, and in the proper order
        4. Concerning the metadata (i.e. blocks “page count”, “publisher”, “release date”, “star rating”), the user is lost, since this information appears nowhere on the final page, so where should the user drag-and-drop it into?
        5. The user has go through these procedures for each single new book to create.

        Cumbersome, right?

        If I’m not mistaken, part of the problem here is the misconception that Gutenberg IS a page builder, with a drag-and-drop functionality. The medium is the message, then that’s how Gutenberg will be used. However, Gutenberg is much more than that, a page builder is just one of its potential use cases, not the only one. (As much as not every tool is right for every job, page builders are suitable for many things but not for everything, such as the book example shows)

        Now, this is what I assume Matías has in mind:

        Who:
        – the developer, to create the view and establish pre-defined blocks that will be needed
        – the final user, to fill in the content

        How:
        1. The developer creates the view for the custom post “Book”, establishing that blocks “title”, “cover image”, “author”, and “synopsis” will all be needed. They are predefined, and already placed on the layout when creating a new book on the editor.
        2. When the final user goes to the editor to create a new book, the main window is already filled in with all needed blocks, and on their final position. These blocks initially have some random content (Lorem ipsum…) so the user clicks there, and can edit the content on place
        3. The user never needs to drag-and-drop any block from the side, everything is already on its place
        4. The metadata (“page count”, “publisher”, “release date”, “star rating”) are all fields within a block called “Book”, which is highlighted on the right (as much as we have “Documents” and “Block” tabs, we could have a tab “Book” in between, with empty fields for all needed metadata)
        5. Notice that the metadata is NOT to be moved to the main area. It is configured always inside a block on the right, and there is no visual representation of it.

        To pay attention: in a way, there are still metaboxes, at least in concept, but they are not called metaboxes anymore, they are blocks as everything else. And that is part of the miscommunication problem, because when it is said that metaboxes will disappear, developers freak out and attack Gutenberg, since they depend on metadata for a lot of things. It would be better to say that metaboxes will just be created in a different way, and possibly even to keep on calling them metaboxes (just to reassure everyone), even if technically speaking they are no different than any other block.

        I believe that Morten Rand-Hendriksen got it all right in his post, when he said:

        …WordPress you’ll go there to create views by writing some content and/or pulling in different blocks of content to form a whole

        and

        In simple terms, it is a shift from WordPress as a platform for publishing content to WordPress as a platform for managing views.

        Create/manage views… yes, but who will do that? The user? Or the developer? And when? In the case of writing a blog post, with blocks of images and text added in a custom order, the user will be creating a view while creating content, both of them are intertwined. However, in the case of the custom post type “Book”, the view must be predefined, so it’s only the developer the one creating the view, not the final user.

        I think that once the use cases are all clear, then we’ll be able to say who the solution is for and what problem the solution is trying to solve… until then, it’s a very muddled conversation.

        Create forum topic from comment

  3. The most important thing in what Matt says seems to me to be the part which is taken as requiring no explanation. The reason why Gutenburg is a top priority, he explains, is to help WP keep increasing market share. What’s not explained – it appears because it’s obvious, at least to Matt, that it doesn’t need explaining – is why WP’s top priority is to keep increasing market share, at the expense of other possibilities for development priority.

    I mean, obviously everybody wants their software to be used. Software with no users will ultimately be abandoned and never improved. But for an open source project with 25%+ market share, is it obvious that increasing this figure is the #1 priority?

    As opposed to, for example, improving the technical quality of the internals, fixing long-standing bugs or significant design mistakes (probably all of us who spend time in Trac are aware of lots of these which are a blight on our ability to do more coding and less providing support and working around them), performance issues (about which you could say much the same) and security concerns (e.g. having updates supplied from wordpress.org being signed and verified, which I understand the core team see as low priority), for example?

    So, for example – what market share does WP have to reach, before it becomes a priority for the time to be invested to bring WP up to the standards that other open source PHP products, with less market share, are meeting? Clearly, the answer is “not now”; that being so… when?

    It may well be that the argument has been made and I missed it. I’m not saying that there is no argument. I am saying I’d be interested in seeing that discussion take place, unless I did indeed already miss it.

    Create forum topic from comment

    • I like the Gutenberg as an idea, and with current progress, it might even get to the point that is actually good. But, as you have stated, there are so many other things under the hood in WordPress that need to be addressed: start bringing the old code up to date with dropping support for PHP 5.2, improving updates security, fixing bugs and issues that linger in Trac for years.

      I know that many issues in Trac have gone without the progress because no one wants to work on them, but that is exactly what project leads need to organize, like with any other business, assign tickets to developers and expect them to do their job. Open source projects sometimes lack the will to deal with tough tasks, and everyone wants to work on new and exciting features, no one wants to clean the toilet.

      Current WP development looks like that, we are painting walls, while water is eroding foundations of the house.

      Create forum topic from comment

    • Perhaps but Mullenweg wants to unify the WP Community by providing a 1st party page and eventually a site builder that eliminates the need for 3rd party user experience fragmentation. This is the beginning of the end of 3rd party page and site builders.

      Regardless of whether anyone truly wants such a thing, not offering a unified building experience will prevent Mullenweg from achieving his goal of increasing WP market share. You will be assimilated.

      Create forum topic from comment

      • I could be wrong, but I don’t think unless the pace of development increases exponentially, this looks to be a real threat to the better page-builders. They’ll stay far enough out in front to be of value to the people that value something beyond the default.

        And… if you’ve ever started with a ‘blank slate’ with a page builder, it doesn’t spell the end for designers/integrators either. Desktop publishing apps didn’t spell the end for designers, even though everyone could now do digital typesetting… it just spelled the end for a lot of traditional typesetters who refused to learn the new tools.

        Traditional theme-building, IMO, has been dead for a while. This just puts a more flexible toolset in the hands of more people out of the box. And, unless I’m misunderstanding (I haven’t used Gutenberg itself), it just lifts the design to another level (i.e.: styles for the ‘blocks’ or complexity of arrangements and integrations). For example, there are companies now making pre-defined templates, layouts, and customizations for page-builders.

        Create forum topic from comment

  5. I really don’t get this:

    We have challenges (user frustrations with publishing and customizing, competition from site builders like Squarespace and Wix)

    A product with a market share of nearly 30% has challenges from products having less than 1% market share – and wants to mimic them? Where in business world something like that ever happened?

    Strange logic.

    (don’t tell me it’s for avoiding them to also reach 30% as this would really be nonsense…)

    Create forum topic from comment

  6. “Some things like toolbar buttons will definitely need to be updated to work with Gutenberg, other things like Metaboxes there will be no problem to provide a legacy interface for a few releases,” Mullenweg said. “But I would say that plugin authors should start updating their plugins in late September if they want to benefit from Gutenberg’s launch.”

    I just hope some documentation or a thorough guide on how to migrate current metaboxes to their JS equivalent is provided. The precedents are not encouraging. There is, as yet, no decent documentation for the current media modal, a feature introduced FIVE years ago.

    Create forum topic from comment

  7. With all due respect to Matt, he doesn’t seem to have a clue as to what fixes WordPress needs to be able to compete with the likes of Squarespace.

    Reminds me of how the large American car companies miserably failed to understand and compete with imports in the 1970s. Or how Blockbuster was famously embarrassed and ruined by Netflix.

    Has Matt ever, from the point of view of a non-techie, compared the experience building a website with open source WordPress to building a website using Squarespace? How does Gutenberg at all address the differences? What business owners are going to care, let alone choose WordPress over Squarespace because of Gutenberg?

    Create forum topic from comment

    • Has Matt ever, from the point of view of a non-techie, compared the experience building a website with open source WordPress to building a website using Squarespace? How does Gutenberg at all address the differences? What business owners are going to care, let alone choose WordPress over Squarespace because of Gutenberg?

      Exactly my thinking as well.

      Create forum topic from comment

    • Has Matt ever, from the point of view of a non-techie, compared the experience building a website with open source WordPress to building a website using Squarespace?

      I’d actually say Matt more than most considers the non-techie perspective. You have to remember that even as he shepherds WordPress the open source project, his bread and butter is still building experiences for millions of .com users, and I’d venture a guess that the majority aren’t “techies”.

      What business owners are going to care, let alone choose WordPress over Squarespace because of Gutenberg?

      “Website in a box” providers like Squarespace and Wix are always going to be a competitive threat because they’re inherently easier for potential site owners to build with. The level of effort and barrier to entry are almost nonexistent. It doesn’t even matter if they’re better (in many ways they aren’t), but they’re absolutely going to be easier almost 100 percent of the time.

      Because of this, pretty much the only chance WordPress has to compete is to lower the hurdle of self-hosted just enough that it’s still worth taking the leap. If WordPress continues on its current trajectory (sans Gutenberg), the cost of that leap will continue to rise.

      Matt thinks the way to keep the leap cost low is to fundamentally change how WordPress approaches the big picture of site building, and I agree. The definition of “content” has changed over the last 14 years, and WordPress needs to address that change to remain relevant in the long term.

      Getting Gutenberg right is going to be very hard – there’s absolutely no getting around that. If anybody here thinks Matt isn’t incredibly aware of the repercussions of screwing it up, they haven’t been paying attention. There’s a reason there’s no 5.0 release date, it’ll ship when Gutenberg is ready and not a minute before.

      In the meantime, absolutely everyone who uses WordPress for anything – whether they agree with the direction Gutenberg is going or not – should be at least giving the current iterations a try and writing feedback down somewhere people can read it. Gutenberg isn’t going to become great if it’s built in a power user echo chamber.

      Create forum topic from comment

    • “Has Matt ever, from the point of view of a non-techie, compared the experience building a website with open source WordPress to building a website using Squarespace?”

      Thanks for raising this, I have and I definitely think it’s important for more people in the WP community to try the same. If there is a specific type of user you think would be valuable for me to learn more about I’m happy to video or screen share in with you running a test.

      Create forum topic from comment

  8. September of which year did Mullenweg refer to in the quote below? September 2017 or September of 2018?

    But I would say that plugin authors should start updating their plugins in late September if they want to benefit from Gutenberg’s launch.

    Create forum topic from comment

  9. Finally I got a better idea what this Gutenberg is about. To get rid of widgets, menus and all that “legacy” things and “merge” them to the one tool looks innovative. Now it’s more clear why so many people fear this … it will change whole WP experience and it looks promising.

    Maybe if there is more “open source” communication what WP team cook behind the scenes, everything will be received easier by whole community.

    I think the explanation (market share, competing with 0.1% competitors …) is not enough. People can support this better, if they know and somebody explain them real benefits of this change, what Matt’s post relatively does.

    Create forum topic from comment

  10. Ok im going to throw my 2c in here regarding some of these comments especially the need for Gutenberg.

    Has Matt ever, from the point of view of a non-techie, compared the experience building a website with open source WordPress to building a website using Squarespace? How does Gutenberg at all address the differences? What business owners are going to care, let alone choose WordPress over Squarespace because of Gutenberg?

    Gtuenberg is just one piece of the puzzle in streamlining the wordpress user experience. I believe that Gutenberg will be used in conjunction with new meta options and front end editing capabilities to allow a user to do everything from the front end of the site.

    This would be critical for my clients, at the moment the experience is good, but fragmented. For example to edit the menu, or widgets I advise my clients to use the customizer, but then to edit the page content they need to use the pagebuilder plugin – for a seasoned user this is fine but for newcomers its jarring having to go back and forth. Then on top of that any meta changes need to be done from the backend – its just too much.

    Also people are questioning why we would want our clients to be able to edit these settings in the first place. My response would be that we need to change with the times, do we really want to be billing our clients for simple backend work like adding testimonials (Custom post types), adjusting settings or do we want to be doing better things?

    What do I mean by better things?
    I started my business soley focusing on web development, but have since moved into more of a digital management space (digital advertising, SEO, optimization, reporting, app development) and found this to be immensely more interesting. Rather than just creating a website and handing it over, I know have a much bigger role in the success of that business through its digital channels which are becoming increasingly important.

    We really mostly only work with the average eveyday business in our part of the world so budgets can be tight. This is why I totally understand the ethos of Gutenberg.

    Gutenberg will help us to make websites faster and easier and spend more time focusing on the success of our clients.

    It might be a little rocky but change is going to happen so embrace it!

    Create forum topic from comment

    • Re: “Gutenberg is just one piece of the puzzle in streamlining the wordpress user experience.”

      Possibly. But like other dominant market leaders, WordPress appears to be moving far too slowly to be able to keep up with its much more nimble upstart competitors.

      I mean, could WordPress’ process for making changes be anymore slow-moving?

      Create forum topic from comment

      • Scott you take it as self-evident that slow-moving (in relative terms) is a bad thing. Can you point me to a ‘upstart competitor’ that is nimble and makes discontinuous leaps in innovation while juggling a user base even a 1/10th the size of WordPress? And why is it that the nimble upstarts (often while cannibalizing vc funds) are growing at a relatively insignificant rates?

        Create forum topic from comment

        • Hi Peter, Are you saying that you’re happy/impressed with the pace of WordPress’ changes and improvements? And for anyone unsure about how dangerous small, niche and disruptive upstarts are to established companies, I recommend Googling: blockbuster vs netflix case study.

          Create forum topic from comment

      • I code so I like things to move quicker so I can build the things I want to build more easily. But I don’t feel artificial urgency to push change just to meet an existential threat or just to wow users to a larger market share.

        No niche, small disruptive start up is building a community driven OSS project that can promise a decade of stable progress with thousands of contributors and a mature ecosystem, so I don’t regard what is out there today as the competition. Not advocating complacency here, but I think its bad to try and outdo ‘competitors’ who offer something entirely different. How long do you think Medium is going to last? What happened to Posterous? How much money does Wix put into purchasing customers? What is the ceiling for Ghost? None of what they do should have a bearing on WP decision making.

        None of the existing projects out there are offering a quantum leap in innovation, which is the kind of disruption that puts out the incumbents. WP is an incumbent, so is Google and Facebook, none of these are currently threatened by alternatives.

        Create forum topic from comment

  11. We have challenges (user frustrations with publishing and customizing, competition from site builders like Squarespace and Wix) and opportunities (the 157 million small businesses without sites, aka the next big market we should be serving).

    I’m a fan of Gutenberg; re-thinking of the blocks/widgets will be amazing and i can see a lot of improvements for users to control their sites.

    But I’m very curious what that impact on small business owners would be. My opinion: very very minimal impact. I’m making websites for more then 10 years, as a one-person business i’ve reached a lot of those small businesses. The majority of them simply don’t want a website because they’re just happy with how things are going. And if they want a website, they have no budget and more important to know: they don’t even care about which CMS to use.

    So, Gutenberg alone will not expand that market share towards small business unless we marketing and advertising it like crazy; as the opponents do.

    Create forum topic from comment

  12. The changes that are imminent in the CMS space are well beyond what Gutenberg or any of the 3rd party editors will address. The future of CMS is JAMstack + headless + static content generation. IMHO the best investment of effort and resources is in developing the REST API.

    Seems to me WP is enhancing the driver experience in a future of driverless cars.

    Create forum topic from comment

  13. I’m aboard with the design objectives of Gutenberg, I’m excited about it. Making a better world class editor is a worthy goal in and of itself. And the potential for making theme creation and customization even better (see roadmap) is even more exciting still.

    I just am very suspicious about the way we are going about it. I think we should be very careful about pushing for market share as a overt goal, it’s not how we should measure success or how our compass should align. I’m doubly suspicious that we’ve been entertaining a framework that is contradictory to WordPress approach to OSS over they years, which tells me that we’ve reached a stage where the ‘ends’ justify the ‘means’. That’s a very dangerous place to take the project in.

    And regards to what the ‘competition’ is doing, WordPress has done very poorly when it has tried to reflexively respond to perceived pressure to ‘keep up with the joneses’. See the post format UI disaster. I think other site builders and other CMS like projects should not push us in one way or another – it distracts from what makes WordPress work so well as a community driven project.

    Somewhere couched in the motivations of Gutenberg and ever increasing market share is an element of vanity. For wanting to be the biggest, sexiest and greatest (and for feeling anxiety about losing appeal). That’s a double edged sword that is.

    Create forum topic from comment

    • Interestingly, I think despite much of the discussion couching it as an arms race for more marketshare, it’s actually more about even remaining relevant in the long term. The last couple of years have seen explosive growth in the page builder space, so it’s almost inevitable that WordPress core itself would move in the direction its extension market is going.

      Of course, there’s value in being second – you get to learn from mistakes already made by the others who came before you.

      Create forum topic from comment

      • I think they look at what’s possible on a platform. Other platforms, say something that isn’t OSS or an OSS project that doesn’t have traction don’t get the benefit of having all these possibilities to offer business owners. And a large community + free + control is better built-in marketing than any other competitor can offer. It’s social proof, it’s an abundance of developers, it’s an abundance of solutions on offer to meet biz demands.

        Create forum topic from comment

    • WordPress it not a community driven project. Community just help with this project. All important decisions are taken out of community. That also explains all your confusion Peter. Do you think that any community will place Hello Dolly in core, promote current featured plugins, hosting page and tons of other things in WP core how they are now? (wordpress.com, React, auto-update, huge legacy code …)

      Create forum topic from comment

      • @Peter, not a community driven project? Over 60 million people have tried WordPress, there are many thousands of developers releasing over 50 thousand plugins and themes for free, between 100-500 contributors work on every major WordPress release. And anyone can become a contributor, no matter what company you work (or don’t) for, what country you come from or what your first language is. It’s a community driven project if there ever was one.

        Create forum topic from comment

        • re: not a community driven project? Are you saying size matters? If so, isn’t Ford a “community driven project”? Since 1903 Ford has sold around 400,000,000 million (!) vehicles, and countless people and businesses have bought Fords, and countless people and businesses specifically contribute to and work on Fords.

          Create forum topic from comment

      • I agree with you here Peter.
        The problem here is not if Gutenberg is good or not.
        The problem is that Gutenberg is going to be in 5.0 because Matt has said that. Not because is ready or because the community has decided to use it (less than 3k installs at the moment) or because the community is demanding for it. It is just because one guy said so.

        We think that the community decides, and this is what happens when the community decisions are aligned with Matt desires.
        When the community decides something that Matt does not want, then we can see who is really deciding and moving this.

        This is for me the bigger problem and the one that need to be addressed.
        Gutenberg could be good or bad, but discuss about that and you miss the real problem here.

        Create forum topic from comment

  14. I like the Gutenberg concept – the block approach fits well with the model I currently strive for when customizing the current WYSIWYG editor for my clients.

    But I am scared for what will become of the standard meta box approach. In my work it’s very common for me to have custom post types where the WYSIWYG editor is secondary to meta fields. For example, a product post type that just needs a short description but several meta fields for pricing, sizing, image gallery, etc. Sometime I will remove the WYSIWYG editor entirely i.e. for a store locator post type.

    Has anyone seen any information about how they plan to handle post types that don’t require a WYSIWYG editor or only need short form WYSIWYG content?

    Create forum topic from comment

  15. Wix and Squarespace get mentioned in the same breath as Gutenberg, every time the topic comes up.

    So all this seems to be centered on WP(.com) profit motive. I can’t believe it’s a romantic tale of the open-source heroes ‘winning’ against the evil capitalist companies…sorry.

    Today, if you asked the average non-techie person if they’d use Wix, Squarespace or WordPress to build their business website, they’d probably react the same as if you asked them do you want a sandwich, a salad, or a bag of flour for lunch.

    The question at this point is, is this a war that can be won? First to market is huge leverage; and don’t forget those companies are flush with cash and are not standing still, either.

    Create forum topic from comment

  17. I don’t understand what the issue with Gutenberg is. Sure it’s a different way to look at editing in WordPress. Though I would have to ask the question, how many here that are saying Gutenberg is bad for WordPress, go around and install a copy of Advanced Custom Fields, Divi, Beaver Builder or some other content block type creation tool?

    I for one am glad that core is tackling a block builder for WordPress. I wasn’t around for when Custom Post Types, and Custom Fields were introduced, they were already a part of WP when I started using it, but I wonder how many people were opposed to those additions?

    We’re still very early in the development stages of Gutenberg, sure the plugin is at 0.90 for versioning, which is very close to a 1.0 version. Even if it reaches 1.0, will it get merged into core and be released or will it wait for a certain amount of features which are functional or a particular feature set to be complete? Or will it get bundled with core and be part of the install/update like Akismet is or Hello Dolly?

    There seems to be a lot of unanswered questions as to how it will be released, and exactly what features it is expected to be released with. Change can be a hard thing to accept, and in the software development world, it can be even harder since changes seem to be made much quicker.

    I’m excited to see how Gutenberg continues to develop, and I’m looking forward to being able to dig in and see how to create a content block.

    Create forum topic from comment

    • Well Joe version 1.0.0 is out today. They have to get it right so based on the way they are going version wise if they do 50 more updates to the plugin before if goes into the core it will be at version 6.0

      Create forum topic from comment

    • @joe I was around before Custom Post Types and I can’t speak for everyone else but I was super excited. I’m excited for Gutenberg too. I think the block approach is fantastic. But I’m also a bit concerned.

      Though I would have to ask the question, how many here that are saying Gutenberg is bad for WordPress, go around and install a copy of Advanced Custom Fields, Divi, Beaver Builder or some other content block type creation tool?

      I think that is a valid point but I would say that, for most developers, Advanced Custom Fields does not fit with the other two examples.

      I use ACF on nearly every project. Gutenberg does not replace the functionality of ACF for me. Gutenberg currently treats ACF and indeed every other meta box as a second class citizen. For many content types and use cases this will be very detrimental for user experience.

      Take for example products in an e-commerce store. Products typically do not need a long form content editor – just a simple text box for a short description will do in most cases. The important bits – price, sizes, image gallery, etc – are all the domain of custom fields and meta boxes.

      With Gutenberg as it is today you’d have this giant editor taking up the screen with just one paragraph of text and all of the important fields hidden away. Not ideal :-/ Even if you can disable the Gutenberg editor entirely for a given post type what does the resulting edit page look like? If you have two entirely different experiences for users it could be confusing.

      Create forum topic from comment

      • @Steve

        Your example of a “product” data is a good one. The pieces of information you mention don’t have to be hidden away with Gutenberg, quite the contrary.

        When the user starts a new “product” the page could be already filled with a “product” block, which has a short field for a description, a drag-and-drop placeholder for a product image, the price field, etc. More configuration options could be shown in the block inspector in the sidebar. This block could look exactly like the theme does, which means people would see the effect of changing or modifying a product information immediately.

        Part of the point of the project is precisely to surface structured content in a way that is as visually clear to edit, just as regular posts can be. Your product information is not tucked away in meta-boxes, but it is the primary thing you’ll see in the canvas, and the one you can directly edit.

        Create forum topic from comment

      • @matias

        I appreciate that you have given thought to how people might address use cases like this. The ability to pre-define and perhaps lock in ( i.e. can’t remove, can’t move, and/or can’t add new blocks ) a block or set of blocks for a given post type or page template would go a long way to easing my concerns with the editor. Is that part of the plan?

        Unfortunately I’m still not 100% sold on the product example you have described. The visual editing sounds great and intuitive but I’m not sure how well it would work with more complex products.

        I have a client with products that have multiple sizes and variations with multiple images and unique meta data for each variation. Some of this information is not exposed visually on the product page. Some of it is available in modal windows. I can’t imagine I would be able to make all of this visually editable. I can throw a lot of it into the block inspector which is okay I suppose but that is an extra click or more to get to something that is immediately available and prominently visible as a meta box currently. That is assuming they know which block it is associated with.

        I also have visual elements on the product page that respond to either other meta data either on the product itself or elsewhere in the site. For example the product category is displayed below the product name. Will methods be exposed to allow blocks to visually respond to changes to other blocks or meta box values?

        Even if your answer to both of those concerns is “yes, we’ve thought of solutions for all of that!” I’m now worrying that I may have to have to write my front end twice for every editable element on my site.

        Then of course there are post types where there is no single applicable visual representation for Gutenberg to show. Locations in a store finder or cases where WordPress is being used to power an API for example. Is there currently a plan for how to address these use cases?

        Sorry, I don’t mean to berate or attack you and your team’s efforts on this project. I am very excited about Gutenberg and think it represents a huge improvement to the experience of editing long form content in WordPress. I can’t wait to impress our clients with the new ease of visually building dynamic rich content pages and posts.

        But I am concerned that the current approach will be detrimental to the user experience for many common use cases. Alternatively it may be a net positive change for user experience but at the cost of greatly increased development time and cost for more complex CMS uses where we already struggle to convince clients to go with WordPress over say Drupal or Expression Engine.

        Create forum topic from comment

      • No offense taken, I appreciate the feedback.

        The ability to pre-define and perhaps lock in a block or set of blocks for a given post type or page template would go a long way to easing my concerns with the editor. Is that part of the plan?

        Definitely! Pre-set blocks that guide a user through setting up content is something I’m looking forward to see.

        Some of this information is not exposed visually on the product page. Some of it is available in modal windows.

        You would still be able to do all this. You could render a purely configurable box below your block, or open modals to configure. The “edit” interface of a block is completely customizable. See how the image block can open the media library, for instance, but also offers direct drag and drop. Settings that don’t have a direct visual representation can still be rendered there. For blocks like “latest posts” we chose the inspector, but if you have things that are _crucial_ yet not visual, you can render them directly within the block.

        If a post type is purely about data and has no tangible visual representation then it would likely remain as it is now. A post type should be able to say “we don’t need the visual block editor” and they’d just get whatever else they register to manage information. The chrome of the editor (header and sidebar) may remain to make the experience consistent, but the main content could be filled with the meta-boxes and custom fields instead.

        My only point is that many of the current meta-boxes and fields implementation do have a visual impact on the front-end, and Gutenberg should allow developers to connect those two things better without sacrificing the separation of data.

        Create forum topic from comment

      • @Matias

        It’s good to hear that pre-set blocks/layouts is something on the road map or at least up for consideration.

        I realized I didn’t address something in my last reply – going back to the example of the product post type you mentioned that ideally we would construct blocks that would visually represent the product page. My understanding is that this content, which now includes some structured data like price and sizing information, would now be stored in post_content as HTML comments.

        Is the expectation that developers will be expected to parse post_content to access this structured data?

        Create forum topic from comment

    • @Joe-“I wasn’t around for when Custom Post Types, and Custom Fields were introduced, they were already a part of WP when I started using it, but I wonder how many people were opposed to those additions?”

      I was around then and the difference to me is that these features added obvious value and flexibility that transformed a previous blog only system to a more CMS like system. Suddenly you could do more than blog! These additions didn’t replace anything or force you to use them. They were optional and you had a choice. Ignoring them caused no ill effects.

      However, Gutenberg will change everything and there is little to no choice in the matter. Those who simply ignore Gutenberg will do at their own peril. It will take the features people have grown to love, the flexibility that has seen them through several sites / projects and replace it with an inferior alternative that will take several years to reach parity with what already is possible.

      Have tested each version, it seems reasonable that the project expects you to redo much of what already works well with little return for your time investment. If you’re not a developer though, you may be likely spared the effects of the update and instead love Gutenberg out of ignorance for it is bliss after all.

      Create forum topic from comment

  19. While probably a small question in this bigger discussion, how will Gutenberg impact email newsletters?

    Any time I’ve used a builder (Divi, Storyform, etc.) it’s always messed with the format of the email version of the post due to blocks and shortcodes.

    Will this also be an issue with Gutenberg?

    Create forum topic from comment

    • As I understand it, the current answer to your question is that all the blocks will be output as just raw text in feeds, since they are wrapped in comments. This is a pretty poor solution, as removing the custom rendering of a block could leave orphaned text that makes no sense without context.

      The way this should be solved is by having Gutenberg store to a structured format like JSON/MobileDoc, and then have a set of “renderer” functions that handle outputting it to feeds, content, excerpt, search cache, etc. That way, the renderers can decide what text is relevant in what contexts.

      Create forum topic from comment

      • So if it’s raw text, does that mean formatting like blockquotes and bold, italic, etc, are lost?

        I use Postmatic for my email delivery, and they allow users to create an email-specific version of a formatted post, in case of any shortcode issues, etc. So, I’m mostly good.

        But I’m curious about other vendors and how they pull a post from WordPress, and how Gutenberg will impact that.

        Create forum topic from comment

      • comments in html…. this like like stepping ten years back in time to before there were shortcodes. Subscribe2 worked that way and cfromsII as well…. and both had a tinymce interface that let you insert the form as a “block”.

        Everything old is new again, and obviously no one want to learn from the mistakes of the past (will gutenberg let me find in which post an image is used? guess it is not a requirement :( )

        Create forum topic from comment

      • I’m sorry @matthias, but Gutenberg is already “breaking a contract” with how every plugin expects the editor to work. If you’re gonna make a breaking change, you need to go for it properly. You could easily shim get_the_content() to render on the fly from a structured format, or simply store a cached flat copy in post_content() for compatibility.

        Either option would leave the source of truth as a standards-compatible structure that can work to reduce the hacks necessary for rendering, rather than increase them. The idea of going to all the work of parsing unstructured data to a structure every time someone hits edit, and parsing it back on save is just insane.

        you have a good, extensible format, and you save it as a hacky, non-standardized format.

        back compatibility is not an excuse for undermining the entire basis of a project (the data-structure).

        Create forum topic from comment

      • You could easily shim get_the_content() to render on the fly from a structured format, or simply store a cached flat copy in post_content() for compatibility.

        What happens with other tools that edit post_content? Users would be making edits to a source that is no longer the canonical one, and risk both getting out of sync and losing content when you regenerate the flat copy and overwrite it.

        I disagree it is undermining the basis of the project.

        Create forum topic from comment

        • Yes, reworking the editor to a structured format requires reworking the tools that write post content… You could make life easier for these third party tools by providing an interim parser for legacy tools that would intercept api or xmlrpc edits and convert them to the new structured format on the fly, but the primary data storage method must be a real, structured format. Otherwise you spend ten more years lagging behind with a data structure full of a decade of hacks, clinging to the idea that fixing them would be a breaking change, while every other editor surges ahead using a real data structure.

          You are extremely concerned with old tools that interact with post_content in a non-standard or non-interceptable way, but that ignores new third-party tools that deserve to benefit from real structured data, rather than having to re-implement the decades of hacks involved in the current monstrosity that it post_content.

          Gutenberg is the one breaking change that is being forced. It is the one chance to make the data right, as every additional breaking change will undermine consumer trust. You are doing it once. Do it right.

          Create forum topic from comment

      • Would it not be a good idea to engineer the blocks API is such a way that it is capable of functioning in both scenarios (post_content html as the source of truth vs a structured data/json model)? Does not seem like a lot of extra work to me, but I could be wrong.

        It would be nice to be able to explore the idea of json/structured data. Quill/draft/prosemirror all have unique advantages over Tinymce and this could be a good opportunity to grant people the ability to explore those advantages.

        Create forum topic from comment

      • @greg it is kinda depressing that after 15 years and after good developers have messed with wordpress, the wordpress api is still just a thin layer above direct DB access. When your thinking is stuck with how things will be stored in the DB your options seem to be much more limited.

        15 years and there is no proper API to get the “raw” post content without it being filtered and changed. If there was such an API and plugins that use post_content directly would have been kicked out of the repository, the question of how things are being stored would have been “just” an implementation detail.

        Calling post_content a “source of truth” is actually so funny and sad, as gutenberg is still using the the_content filter which means that “truth” might have been changed tens of times from post_content until it is being handled by gutenberg.

        Gutenberg is a great opportunity to break things and make a better infrastucture. The attempt in half arsed backward compaibility can only result with gutenberg not being useful or (as it seem the direction is right now) backward compatibility being broken, but for no gain

        Create forum topic from comment

        • I agree entirely. Gutenberg is a great time to make this refactor. 5.0 is a major version, which justifies improvements to the data structure. I have no idea why the core team seems to be so afraid of fixing the awful hacks that WordPress has carried with it for the last decade.

          Create forum topic from comment

    • Calling post_content a “source of truth” is actually so funny and sad, as gutenberg is still using the the_content filter which means that “truth” might have been changed tens of times from post_content until it is being handled by gutenberg.

      Where are you getting this from, Mark? Gutenberg uses the “raw” shape of the post, which gets sanitization, and definitely doesn’t pass it through the “the_content” filter.

      Create forum topic from comment

  20. These statements seem to be slightly contradictory:

    “Gutenberg will ship with WordPress 5.0, but the release will come out when Gutenberg is ready, not vice versa,” Mullenweg said.

    but

    . “But I would say that plugin authors should start updating their plugins in late September if they want to benefit from Gutenberg’s launch.”

    Now I realize you can rationalize those but that sure doesn’t sound like 5.0 will come out whenever, but that it’s worth it to start updating plugins now. No one would do that if they knew the release was, say, a year away. What that indicates is that there’s at least a tentative release date in mind… and I don’t know that Gutenberg will be ‘ready’ anytime soon.

    More than functionality and even more than the impact on our businesses, what worries me about Gutenberg is that it fundamentally changes a lot and could easily break a lot of sites. I can’t see the project testing with an extensive array of themes and plugins never mind the combination. What happens to, say, Divi users who aren’t on the current version of Divi? What about page builder users who are likewise not on the current version of their plugin or who update WP before updating their plugin? What’s the testing plan here?

    It might be an unfair comparison, but the 3.0 release of WooCommerce broke quite a few installs because of a fairly simple change. Sure, it’s fine now… but the point is that the impact of this was missed.

    Create forum topic from comment

    • but the 3.0 release of WooCommerce broke quite a few installs because of a fairly simple change

      A fairly simple change? They removed certain APIs and changed array structures. it was a bloody mess. Unfortunately, this is what many of us have come to expect from Automattic. This is no different, sorry to say.

      Create forum topic from comment

    • I have nothing against a new default editor. I have plenty against this new default editor. Gutenberg isn’t perfecting craft, it’s adding a new layer of hacks on top of a completely overburdened and hacked together data-structure.

      “Perfecting your craft” often means throwing away the bad parts and starting over, and as WordPress’s bad parts go, post_content is by far the worst.

      Create forum topic from comment

      • Just in case: While I’ll not continue to respond to the third basemen in this thread, I’d already read the open reply on your blog site. I understand and don’t disagree on a number of points there (although I found the “lie” accusation unnecessary and unhelpful) . As I responded below, I get the concerns. But the editor is far from done, and we’re not going to see a ground up rewrite of core, as cool as that might be. I’m trying to be more pragmatic in my aging I suppose. Cheers.

        Create forum topic from comment

        • I’m sorry that you feel that way about the concerns of many in the WordPress community. To clarify, I have never advocated for “a ground up rewrite of core”, but rather occasional changes to fix things that were missteps made years ago, before people knew what WordPress would become.
          Matt said that a new editor every decade makes a lot of sense. I’d argue that a revision of underlying storage methods should see the same sort of timeline.

          In case you are interested, I laid out a theoretical timeline for how this launch could be handled, so as to make the transition as smoothly as possible. you can find it here: https://gschoppe.com/wordpress/the-gutenberg-that-could-have-been/

          Create forum topic from comment

            • I’m sorry, perhaps I misunderstand you, but when you say “a laundry list of core issues”, it sounds as though you are describing those as out of scope of the editor rebuild. If so, I would argue that a move to structured data requires revisiting the incompatible parts of core, rather than treating them as immutable. Gutenberg is a fundamental change to how WordPress works, and a major version is the right time to make sure it is able to integrate tightly and set a smooth path forward.

              Create forum topic from comment

              • Thank you. My “list” was focused on your points about deficiencies with shortcodes, images–structural content. I understand that for sure. I’d love to see some of these deficiencies addressed. Aside, I think those structural / meta issues have made a very rough go for REST-API integration into admin, which is really important to folks like me who build decoupled UI. I do wonder if there’s a point where we end up with a breaking version and split maintainers for legacy. Dunno.

                Create forum topic from comment

      • I understand this was bound to cause some nail biting. There are legit concerns for sure. But a lot of hyperbole as well. I think the more the more involved devs get in up front, the less they’ll risk missing the dance on this one. 😁 If not already, highly recommend checking in on the #core-editor channel on slack for latest discussions, and GitHub of course.

        Create forum topic from comment

      • @John Teague,

        You say there’s “a lot of hyperbole” about Gutenberg. Please point me to anything Greg Schoppe has said that is hyperbole.

        His concerns are about fundamentals. And he’s been “involved,” as you suggest, right from the start. Yet the Gutenberg devs refuse to pay attention except to acknowledge that what they are doing is a hack.

        Frankly, if the Gutenberg devs won’t even address those fundamentals properly, then the rest of this discussion (whether hyperbolic or not) is just noise.

        Please explain why anyone using WordPress as a CMS or for business purposes should entrust their sites and data to a hack.

        Create forum topic from comment

      • @John Teague,

        No, I’m not confused, but you might be.

        I know you didn’t expressly accuse Greg of hyperbole, but I just wanted you to confirm that he wasn’t indulging in it.

        Why? Because your confirmation highlights two facts:

        1. Your suggestion that devs should “get involved” makes little sense. Just look at the responses Greg has received.

        2. There is no reason why anyone using WordPress as a CMS or for business purposes should entrust their sites and data to the Gutenberg hack.

        Create forum topic from comment

  22. One of the most prevalent concerns that remains is React’s licensing issues…. …the WordPress project has yet to announce its stance on the decision.

    “We anticipated a decision on React around the Apache deadline (closer to now), will have more to announce about WP and Gutenberg’s approach here in the next few weeks,” Mullenweg said.

    When can we expect the “more” to be announced on this issue?

    For anyone interested, there’s an open GitHub issue on the Gutenberg project here – https://github.com/WordPress/gutenberg/issues/2298

    Create forum topic from comment

    • the problem is that you are breaking things without improving them. Introducing a new hack into the awful non-datastructure of post_content is not an improvement. It is a massive step backwards. With that in mind, a lot of people would rather not break things at all, if the result is going to be just a bigger pile of hacks.

      Create forum topic from comment

    • Actually @matt, matias is claiming that nothing will get broken at all. There is no agreement at all right now that gutenberg breaks things. Now if there is an agreement that things are being broken, it would have been worth to discuss what kind of breakage will be most beneficial, but we are already at “feature complete” stage, and doesn’t seem like any one is actually intrested in having any kind of technical discussion.

      TBH, I think gutenberg is good for me personally, as it will push “integrators” to the outskurts of wordpress development, and I will be able to charge more. Not sure why do I even bother to object to what is being done.

      Create forum topic from comment

  24. There is still a lot unclear and a very contradicting message, reading comments in this thread.

    On the one hand, WordPress developers are reassured their website with custom post types and meta boxes will not break.

    On the other hand, Matt is urging everyone to learn Javascript and React and to make sure to update their plugins and themes in 2017 (“Plugin authors should absolutely start updating their plugins to work with Gutenberg this year, 2017.”)

    I have about 70 client websites build on WordPress, most using custom meta boxes. All very small businesses or non-profits. One of the main reasons I chose WordPress is that changes almost never break anything. I can come across WP sites on very, very old versions, update them to the latest 4.8.1 and everything still works. Themes I build 8 years ago still work.

    Who is going to explain to those clients their websites are going to break? Who is gong to explain to them they need to have their websites rebuild (that’s what it comes down to)? Who is going to pay for the massive amount of work needed to rebuild meta boxes in Gutenberg blocks?

    This is not hyperbole. Rebuilding those 70 websites will take me many months, at least. Most clients will not pay for that. But I also can’t leave them with websites not being upgraded. And even if I somehow manage to rebuild everything, nothing has improved. For example, a client who needs to edit their “Project” or “Event” custom post type still fills in a couple of form fields.

    Create forum topic from comment

      • Sorry but that’s not a solution. Having to install and depend on a plugin to keep a “legacy” system working. Sooner or later that will break something. And it will mean you can’t use new features without breaking everything.

        Meta boxes are such a core part of WordPress and are being used by developers and agencies for tons of things. It’s one of the reasons all those developers and agencies chose WordPress as a CMS in the first place and not something else. It’s one of the reasons not using something like Joomla is that with each version (1.* to 2.% etc) many things break and you have to do a full “migration” to the new version.

        I really don’t understand why Gutenberg cannot just be used for the content editor, while leaving meta boxes for meta content (!= content) alone.

        Create forum topic from comment

  25. I am very concerned about the direction of Gutenberg. In my opinion this “Post Edit Screen” replacement is way out of scope of replacing TinyMCE editor.

    The scope creep on the project has been raised numerous times, and to my knowledge, has not been addressed in detail. See the github ticket regarding metaboxes for details.

    If we could get a complete answer as to why Gutenberg needs to be a full screen replacement, and why metaboxes are considered “legacy” maybe we would better understand the philosophy behind this.

    I feel some of us are seeing the editor developers wanting to build something new and cool, ( which is great ), but maybe got a little bit carried away working with the fun stuff and replacing everything. I also think there is a bit of not invented here syndrome. Every time I hear “legacy metaboxes” I basically hear, that was invented a while ago by others so it’s old and no good. You need to get on board with the cool kids and re-do everything in the latest ( current ) fad, React.

    How many years will it take before we start to consider React, the new editor and blocks “legacy” and “not invented here”. I guess probably not long, backbone.js and the 3 year old completely redone media library is probably starting to loose it’s cool factor.

    Create forum topic from comment

    • I’d point out that the “drama” label is relative depending on what side of a spirited debate your on. So, if your a fan of Gutenberg, just because you’re annoyed by people who are expressing they’re not a fan doesn’t necessarily mean they’re being dramatic. Just saying.

      Create forum topic from comment

  27. This is all eerily reminiscent of MSFT’s 2001 decision to dump Visual Basic 6 and force everyone to VB.NET, breaking ALL kinds of legacy code in the process and forcing devs to relearn their craft. Well, at least from a dev’s POV. That debate and resistance to that change went on for YEARS…and MSFT basically said, ‘oh well, this is the future, get on board or get left behind.’

    Sound familiar?

    No one remembers VB now. ;-)

    Tread carefully, Automattic. Pissing off a majority of your dev base for a pet project is not a wise move. Ignoring them is worse.

    If you folks love this thing so much, leave it on wp.com, where it belongs. Leave .org alone. Don’t force it on ALL of us because there is some kind of scare over things like WiX and SquareSpace.

    Just MHO, having been through this kind of thing once.

    Create forum topic from comment

  28. From the perspective of this humble web designer, Gutenberg is the final straw. I’ve been a user and promoter of WordPress for ten years and it has provided me with a low-cost way to create custom websites for my clients. I’m not a programmer–never was and never will be–but I could still learn to create templates that met my clients’ needs, and empower them to run their own websites.

    I often got folks started on WP.com if they didn’t have money for a custom site. However, after the “Beep-Beep-Boop” fiasco I advised against using WP.com. Why? Because the environment became, IMHO, very user-hostile. Features were added, features were taken away, the UI changed willy-nilly, without notice and with no regard for the expectations of the users. The forums were full of people with problems and complaints but those were mostly minimized. I work with primarily non-technical people, many of whom are older–and constant changes are anathema to these folks. “Get over it and learn the new way” is not how I treat my clients!

    Even as WP.com got more chaotic, self-hosted WordPress continued to offer an environment of predictability and stability. But recently Automattic’s tentacles have driven deeper into the self-hosted space, primarily via Jetpack. Now it is clear that self-hosted WP is not an independent entity, but a fully owned subsidiary of Automattic, and Automattic is in the business of growing its market share regardless of its impact on WP.org. Fine for Automattic, maybe not so fine for the legions of independent WP developers. Who can say? There does not, as many commenters have noted, seem to be a very clear path forward.

    Is Gutenberg an opportunity for improving WP? Quite probably. However, what happens to clients who cannot afford to pay for major revisions to their custom theme? What about the cost of re-training? I cannot absorb those costs, and frankly many of my clients can’t either. They will be left with an out-of-date and thus insecure installation.

    There’s always a watershed moment with any technology, and I’ve reached mine. WordPress gave me a good ten-year run, but I’m done with it. I cannot continue to invest in a platform that has transformed from being stable, user-friendly and accessible to one that is profit- and “market-share”-driven.

    If you’re still monitoring this discussion, Matt, here’s a tidbit for you: I am now recommending Squarespace to all my clients who need a new or refreshed website. SS’s support and help resources are FAR superior to WP.com’s offering; the UI is stable and intuitive; and e-commerce is baked right in. For my customer base (micro businesses, shoestring nonprofits, and personal blogs), Squarespace is the perfect platform for the price. (Yeah it’s rude for promoting the competition but I am totally serious about this, and no, I am not a shill for SS.)

    Create forum topic from comment

    • Good points, Adrienne. But ever since a web designer friend of mine convinced me to try out WordPress back in 2009 or so, I’ve questioned why so many web designers push something as complicated and time-consuming as WordPress.org on to small businesses.

      WordPress is amazingly powerful and flexible. But it’s overkill for most small sites. And let’s face it, unlike Squarespace etc, there’s zero business-level support.

      Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.