We Called it Gutenberg for a Reason

Movable type was about books, but it wasn’t just about books. Ideas spread. Literacy spiked. The elite monopoly on education and government started to crack. Luther’s 95 Theses were printed on a press, rocking Europe, and he issued “broadsheets.” Broadsheets became newspapers; newspapers enabled democracy. The printing press ushered in social, political, and economic sea changes. Gutenberg changed everything.

WordPress has always been about websites, but it’s not just about websites. It’s about freedom, about possibility, and about carving out your own livelihood, whether it’s by making a living through your site or by working in the WordPress ecosystem itself. We’re democratizing publishing — and democratizing work — for everyone, regardless of language, ability, or economic wherewithal.

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.


For those who don’t know we kicked off the Gutenberg project around the beginning of the year, I talked about it and we did our first public releases in June, and the team has been doing weekly updates of the public beta plugin that’s available for anyone to try out in their wp-admin.

When Johannes Gutenberg’s press came out, people mostly used it to print the same religious text monks had been copying. It wasn’t until ten or fifteen years later that people started innovating and trying their hands at new kinds of writing, and the wheels of change started to spin faster. Now it’s WordPress’ turn to do the same. Gutenberg meets our challenges and opportunities head on while simultaneously benefitting everyone who makes a living working in the WP ecosystem. It’s about a lot more than just blocks. Our Gutenberg moves every part of the WordPress ecosystem forward:

Developers and agencies will be able to create interactive templates that clients can easily update without breaking things or dealing with custom post types: Imagine a custom “employee” block that you can add to an About page that includes a picture, name, and bio. They’ll be able to replace most meta boxes, and they’ll get a chance to update old code or clients to work in this new paradigm.

Plugin developers will be able to completely integrate into every part of WordPress, including posts, pages, custom post types, and sidebars without having to hack TinyMCE or squeeze their entire feature behind a toolbar button. Today, every plugin that extends WordPress does it in a different way; Gutenberg’s blocks provide a single, easy-to-learn entry point for an incredible variety of extensions. Some folks have already begun to port their plugins over, and are finding that they’re easier to build and have a much improved UI. I’m looking forward to highlighting those stories as we get further along and more people write about them.

Theme developers won’t need to bundle tons of plugins or create their own page builders. There’ll be a standard, portable way to create rich layouts for posts and guide people through setup right in the interface, no 20-step tutorials or long videos needed. Every theme will be able to compete with multi-functional premium themes without locking users into a single theme or compromising their experience.

Core developers will be able to work in modern technologies and not worry about 15 years of backwards compatibility. We’ll be able to simplify how menus, widgets, and the editor work to use a common set of code and concepts. The interface will be instantly responsive.

Web hosts will have better signup rates, as Gutenberg opens up WordPress to an entirely new set of people for whom WordPress was too complex and hard to set up before. (Remember our goal: to democratize publishing.) Their churn rates will go down: they’ll stop bleeding customers to Wix, Weebly, and Squarespace, and fewer people will abandon their sites because it was too hard to make things look they way they wanted.

Users will finally be able to build the sites they see in their imaginations. They’ll be able to do things on mobile they’ve never been able to before. They’ll never have to see a shortcode again. Text pasted from Word will get cleaned up and converted to blocks automatically and instantly. (I pasted the first version of this post from Google Docs and it worked great. 👌) They’ll start manipulating their sites in ways that would have taken a developer. They’ll be able to move from blogging to using WordPress as a CMS without missing a beat. Editing posts will just work; they’ll write more. They’ll learn blocks once, and then be able to instantly use and understand 90%+ of plugins.

I could go on about how photographers will be able to create rich galleries, parallax images, and better portfolios, or how poets will finally be able to preserve whitespace as they write, but you get the idea. It’s big. It moves the WordPress ecosystem forward, but it also moves the whole web forward.

Which is scary! Because change always is, and this is a big one. But a scary thing is usually a thing that leads to growth, if you can push through it. Ten years ago, agencies and developers worried that software like WordPress would ruin their business because clients wouldn’t need help updating their sites any more, and would maybe even just start building their own sites. But their worse fears didn’t come true — instead, it created new opportunities for everyone.

(People were worried when the printing press was invented, too. A Swiss biologist warned against the “confusing and harmful abundance of books,” but I’d say it all worked out in the end.)

This is not to say that nothing will go sideways with Gutenberg, or that people’s concerns about it are unfounded. Making something people want is really hard to do and easy to mess up — we definitely have in the past. I share many of the concerns or worries with today’s version of Gutenberg, and we’re working to mitigate them. Gutenberg will ship with WordPress 5.0, but the release will come out when Gutenberg is ready, not vice versa. 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.

And as we work, we’re listening: feedback on core and feature plugins gets read, heard, and considered. Every review of Gutenberg, even the rude ones, has a response. Seven months of vigorous and public debate, chats, tickets, and code changesets brought us to where we are today, and there will be  a fair amount more before we can present the Gutenberg vision in a mostly-complete state. I welcome it; apathy would worry me a lot more than disagreement or controversy.

Creating great software will never make every person happy. We’re not creating The Perfect Product, we’re choosing a path between many good options, weighing all of the inevitable trade-offs that come from a change, listening, shipping, and then doing it all over again. Iterating. My life’s work is improving WordPress. 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.

Yes, it is a press, certainly, but a press from which shall flow in inexhaustible streams, the most abundant and most marvelous liquor that has ever flowed to relieve the thirst of men.

Johannes Gutenberg

Thank you to the WP Tavern conversation that helped me write down many of these ideas, and Michelle Weber. This post started in Google Docs then revised in Gutenberg 0.9.

105 thoughts on “We Called it Gutenberg for a Reason

  1. Gutenberg is something Automattic needs, not something the WordPress community needs. This seems like a blatant conflict of interest if you ask me. Just take a look at all the negative feedback from developers in the plugin’s review page and Tavern.

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

      1. Gutenberg is something I would like to see in the core, but I personally, and a lot of other people involved in WP community are worried about the current development process and lack of proper answers to many questions asked in the forums, on GitHub in WPTavern and many other websites.

        And so far, there are no clear answers on use of React (it has no place in the WordPress due to the anti open source license from Facebook) and with all the negative backlash about the React, development progresses with React and WordPress is the only major open source project that seams to be completely silent on this issue. React needs to be replaced with something else, before anything else is done with Gutenberg. The more development continues as it is now, the more time will be needed to replace React later.

        Backwards compatibility is still a major problem that has no clear answer. Meta boxes and all the current hooks used in the editing process must remain in use, and Gutenberg can’t disrupt the essential part of the WordPress experience that millions of websites depend upon. 99% of websites I worked on use at least one custom meta box and at least 3-4 plugins with metaboxes. Expecting major rewrites for all the plugins using meta boxes is unrealistic with project that has no documentation (Gutenberg is 5% documented from what I have seen, following the same lack of documentation as the rest of JavaScript in WP). I agree that metaboxes should be replaced at one point, but not before Gutenberg is merged to core with full legacy support, and then allowing 3-4 major WP releases for plugins to catch up.

        Release schedule is another major issue. With so far seen release numbering, we are close to Gutenberg 1.0, where in reality, Gutenberg is now maybe reaching 0.1 version. Or maybe the versions will go past 0.9 to 0.10, 0.11, 0.30 and more. With only 1000 or so installations using Gutenberg for testing, with so many issues and problems, so many unresolved legacy things, Gutenberg might be ready in a year to be considered for merge. Yet, it looks like that WP 5.0 is slated to get Gutenberg even if that means waiting unspecified amount of time for that to happen. WordPress will soon get version 4.9, and after that work must go with 5.0 and 5.1 with previous release tempo, and maybe at the end of 2018 we can think of WP 5.2 and Gutenberg in it. We need 100.000 or more users actively testing and discovering bugs to even begin to see all the problems Gutenberg has.

        I like the idea of Gutenberg, I even like the current interface and the workflow, but all these things I listed need serious answers before we can continue anything. And, Gutenberg project lead is already thinking of the merge proposal after WP 4.9. That is just crazy unrealistic.

      2. 1. Best to engage on Github and the Slack chats for highly technical questions, not Tavern or forums.

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

        3. 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. But I would say that plugin authors should start updating their plugins in late September if they want to benefit from Gutenberg’s launch.

        4. Gutenberg 1.0 will just be the next update, then it will go to 1.1, 1.2, etc. The version numbers are incrementing every week. I also would love more testers of the the Gutenberg plugin. Development has been coming along really great and based on everything I’ve seen so far I think it’ll be ready long before the timeline you are imagining.

        In a few weeks we’ll be able to do some programs and promotions to get wider use of the plugin. Today it’s not quite ready for that as we’re still addressing known issues, so there’s not as much utility for additional users or testers yet.

  2. honestly, i did like to see people break things – like themes, plugins, codes…. only then do you learn from your mistakes and become better at something.

    wordpress needs a full system restore feature, let new beginners toy with everything and have the ability to roll back in the even the theme breaks – with a click of a button. or somekind of ‘safe mode’ like windows.

      1. Yes please! I’m a music producer and content creator (don’t make fun of me), and I started to learn about web development this year, but my mistake was to start learning with my main site instead of using a test installation. I already know what tools I want to use to build my site (no more testing for me), and I’d like to have a fresh start.

  3. Hey Matt, thanks for such a thorough write-up. A few days back, I was thinking to pen down similar thoughts about Gutenberg and its impacts on the tech world. But you’ve got it covered. 🙂
    I think all these points lead to better productivity no matter to which field you belong. 🙂

  4. Hi Matt.

    Thank you for this insightful overview. We are all very excited to see WordPress moving forward in such a promising way.

    I couldn’t help wonder about a few questions that are still not quite clear to me:

    1) Will Gutenberg function as a true WYSIWYG page builder, allowing users to craft visually-accurate page designs, similarly to how Wix or even existing Page Builders like Elementor and Beaver Builder do?

    2) Will Gutenberg be integrated into WordPress core, or will it remain a non integral plugin?

    Thank you.

    1. 1. The first version will be a page and post builder, and then we will take the block concept to replace widgets, menus, and have themes that allow you to build entire sites. It’s more structurally focused than a pure WYSIWYG approach, but people will be able to see and understand the relationship to the structure and visual appearance of their site much, much better than now.

      2. The goal of the plugin is to come into core so that other plugins and themes can start to build on it as infrastructure. Over time it will allow us to reduce and simplify a lot of the code and interfaces in core.

      1. Hi Matt,

        thanks that you’ve recently started to address some of the concerns around Gutenberg. It certainly helps to understand Gutenberg better and to get an idea of where this is heading.

        I think the reason for most of the concerns, confusion and frustration around Gutenberg was that these answers were missing from the start. Gutenberg was introduced as a better editor, but then people started to realize that it will be so much more, something that basically will replace WP as we know it today.

        It’s probably understandable that many developers didn’t like the idea from the start, especially not if it wasn’t clear before that this will happen, and also the questions that were asked and the concerns that have been raised were not properly addressed. There were no clear answers until recently. And still it’s not completely clear when and how all of this will happen, which makes it kinda hard for businesses to plan ahead.

        I understand that Gutenberg may be top priority for Automattic at the moment. But there also are thousands of other businesses in the WP ecosystem that are running their day to day business and don’t have the time and resources to completely dig into Gutenberg. Usually that wouldn’t be much of an issue, but since backwards compatibility doesn’t seem to be a thing anymore in WP (Yes, I understand why), there is quite some pressure as you probably can imagine.

        Other businesses may have been working on new products for months, they may be close to release or maybe just starting out. As a company it probably wouldn’t be a great idea to release new stuff now, just to realize that it needs to be recoded a few months later. That’s what I mean with that businesses can’t plan ahead at the moment because there is so much uncertainty.

        For example you mention that widgets will be replaced by Gutenberg as well in the future. Well, basically most of our business depends on widgets and to be honest, I have no idea what “widgets will be replaced” exactly means. Of course I understand that they will need to be recoded into blocks, but when will this be necessary? How will it needs to be done and will this be documented somewhere? What will happen with sidebars? Will there be backwards compatibility for existing widgets? etc…

        This is just one example and I could go on and on. Please understand that while you just say this and that will be replaced, for other companies in the WP ecosystem (which may not have the time and resources to be heavily involved in Gutenberg) these replacements basically mean the need to reinvent their business and recode lots of stuff to make their products Gutenberg ready. This isn’t something that can be done in a rush or within a few months, it needs time.

        I think so much of the frustration in the community is based on this rush. It may be the case that Automattic had this planned since months / years and now it totally makes sense why you never wanted to have widgets and other stuff in themes on WordPress.com (which was hard to understand before), but for most developers this whole Gutenberg thing came as a surprise and now suddenly everything needs to happen quickly.

        Ok, it may be the case that you (with the resources of Automattic) can develop Gutenberg at such a pace, but that doesn’t necessarily mean that other businesses in the WP ecosystem can reinvent their products at that pace while taking care of their day to day business at the same time. It’s also worth mentioning that most end-users don’t even know what’s coming.

        With that said, I think if there would be better communication and a clear roadmap about what to expect and when, there would be less frustration, confusion and resistance. Overall WordPress needs to evolve, I think nobody is arguing about that, but I also think it would be a good decision to do this while having the WP ecosystem on board, with clear statements and a roadmap which helps businesses to plan ahead.

      2. Michael:

        Thanks for your comments! At the moment we are threading a delicate balance between communicating what will be possible and what we are focusing on. It’s very important to communicate the overall vision for a full Gutenberg experience—one which spans across the post editor and full site building. At the same time, we have to be conscious we are building this in stages, precisely to give time for the concepts and implementation to settle while we figure out possible ways to handle various transitions. The first version of Gutenberg is not replacing sidebars or widgets, but it should start to give an idea how widgets could be transformed into a more pleasant and visually clear experience.

        These are things that have been brewing since the post formats days (when the idea of blocks of content was first introduced). It is important to look far enough into the future, to see where we are heading; to look back to see what has failed or worked for us in the past, as we plan ways to transition into the new; and to the present demands, so we can iterate while providing tangible value to people using WordPress right now.

        In practice, replacing widgets is not something that will happen overnight. The most plausible scenario is that Gutenberg will offer a better way for you to code widget-like functionality that optimizes for a visual presentation in the edit context. That doesn’t mean your previous widgets shall stop working. Even in the current state of the plugin, you could create a block that has a visual representation in the editor but renders your widget exactly as it is coded on the server. I expect that there will be block utilities to facilitate migrating a widget interface to a block interface. The team, or the community, may create a way to render existing widget interface as a block through an API endpoint. It may not be the best experience compared to native blocks, but it would give a path to transition.

        One of the reasons for our approach to the post structure was to not break the expectations of how things work, and how things are rendered within themes. The goal is to make it possible to transition as smoothly as possible to a better paradigm without breaking any content. In a way, widgets are looking to be similar to shortcodes. We are not removing shortcodes with the first Gutenberg version. In fact, we have a block to help write them and visually separate them from the content if needed. We need as much participation from the developer community as possible to solve these various needs. If something is not yet handled it doesn’t mean a disregard for it, just the reality that we cannot tackle everything at once. As the plugin matures, it is becoming easier to see what is possible, and that gives us all a better framework to discuss options and tradeoffs.

      3. Hi Matías,

        thank you very much for taking the time to reply and for providing some addditional information on the transition phase. I think these kind of insights are very important for the PR related to Gutenberg. In my opinion much of the resistance against Gutenberg in the community is related to lack of information and communication.

        Providing more information and especially documentation on how developers can transition legacy code into something that will work well with Gutenberg will help increase the acceptance of Gutenberg. What may be obvious for the folks that work at Automattic, may not be that obvious for other people who only read the vague information that is publicly available.

        At least it’s good to know that you plan to replace things slowly while giving developers enough time (months / years) to adapt to the new system and the way of handling things. Anything else probably wouldn’t be justified, especially not when you take into account that everything you do will potentially affect a 3rd of the internet.

      4. Absolutely. Since things are beginning to stabilize, I am going to be focusing more on documentation in the coming weeks. We already have a decent collection over here, which we need to find a nicer home for!

  5. Spent last five days digging deep in the core code of Gutenberg. I am trynna connect a completly different set of blocks API based JS framework with WordPress.

    1- First three days, I was like “Gutenberg sucks”.
    2- Then I ended up writing a few simple components which integrated very well.
    3- Now I feel like a lot can be done with Gutenberg which was not possible before to be done in this way. What I built is easy for end users. What else I should do is what I am thinking right now.

    One thing is it’s say: I am afraid how Gutenberg will affect the current eco system. But it can make WordPress cool again.

    Thanks for sharing the insights!

      1. Sure thing!

        I really think that we should invest more in teaching people what Gutenberg is and how to get started with Gutenberg’s development. It will def soften the blow — esp. for all the tech debt that’s being not dealt with.

        The comment from mobile removed all the emoji in my comment. Not sure why. Anywho, it got the message across (though it sounds a tiny bit weird with emoji).


    1. Ahmad, did you find any good resources for digging into Gutenberg, or was it mostly by reading the code? Have you added the components to Github? Would love to take a look and start to get a feel for what Gutenberg development will look like.


  6. This comes at the right time for me. I switched to Squarespace earlier this year after perhaps a decade at WordPress – for many of the reasons Gutenberg has come to pass. It may well tempt me back.

  7. Thanks for writing this. I’m still in the Gutenberg skeptic camp, but I’m hopeful and this made me more hopeful. FWIW, I’ve tried hard to use every version from prototypes to 0.9, and tried to provide critical feedback that I think is important to making it an valuable part of WP core.

    Admittedly cherry picking a bit I find it notable you copy/pasted in the first draft because one of my challenges has been I don’t feel Gutenberg has good flow between blocks when writing original content. I think supporting copy/paste workflows is hugely important too, but native long form writing, particularly around keyboard shortcuts and smooth, natural transitions is still a rough spot in Gutenberg.

    The prospect of something like a “employee block” is intriguing, but I need to say first that CPTs (custom content types) aren’t bad things, they make sense to site owners. They’re the foundation of WordPress being useful as a CMS. The challenge for longevity and data portability they make sense to be created in the plugin space, or dynamically in core/database space. Then displayed and styled in the theme space. I have yet to see/understand how Gutenberg proposes to bridge this divide such that a user can change themes and have a predictable experience to custom content type display. This was a problem post formats tried to tackle, but unfortunately (I think) failed to achieve.

    Still hopeful and watching carefully.

    P.s. It might be reassuring to folks to explicitly says that Gutenberg is following semver and that teams not expecting to go from 0.9.0 to 1.0.0 into WP 5.0. Rather we might see 0.35.0 before 1.0.0… assuming that is indeed the case, I’m just guessing.

    1. The prospect of something like a “employee block” is intriguing, but I need to say first that CPTs (custom content types) aren’t bad things, they make sense to site owners. They’re the foundation of WordPress being useful as a CMS.

      I’ll highlight this portion rather than post my own comment. This is my #1 concern with how Gutenberg is being approached is that it shifts more decisions and content entry to a visual medium. I certainly understand some of the benefits this can bring, but I’d reiterate the point in this comment: breaking up content makes sense to users once grasped and is extremely powerful.

      An “employee block” in Gutenberg sounds great for layout, but I struggle to understand how that translates to generating a list of Employees in a state (by a Taxonomy term), reordering employees by last name, or writing a custom REST API query to return a specific set of employees on an internal dashboard.

      Gutenberg seems to be saying “the content means how it looks” when that historically flies in the face of what “content management” means. I see advantages to this on small sites, but I cannot wrap my head around the idea of scaling visually-driven content management.

    2. One way I see custom post types is a ‘best option’ not ‘best solution’. They are there to fill the gap when nothing else was able to. What Gutenberg gives is the potential from an experience view to get a best solution. That’s exciting.

      1. Hey Tammie – I’m not sure I understand what you mean by “One way I see custom post types is a ‘best option’ not ‘best solution’. They are there to fill the gap when nothing else was able to.”

        It seems like you’re saying you think CPTs are bad and/or blocks are going to be better. It also sounds like you’re suggesting blocks are somehow a replacement for CPTs which is where I’m really confused.

        I’ve read the Gutenberg devdocs on surge (BTW, coming along but you really need to publicize them more, because they are what shifted me from the stance of Clif Seal and a few others here that this project is totally without vision and direction, to “well maybe there is some kind of plan and this will be OK”).

        Anyway, I recall reading in there a “latest posts” block being scoped out. I assumed from that, that someday blocks would be able to reference CPT content, no?

        If a user sees an employee block mid page they’re going to be able to click on it and update the content. That change is going to be posted back to the employee CPT and that change is reflected everywhere from the employee directory search results, to the “about department X” page, to the employee of the month index page, etc… The underpinning of that employee block is _going to be a CPT_, no?

      2. Thanks for the reply Jon (@jb510) (going to use your handle reference here as think we can only go 2 comments deep and want to respond to you), apologies for not being clear.

        Blocks as a starting to be a solution that is the best one for things like various forms of content. For example, let me step into a personal experience to demostrate. I remember a long time ago when I was freelance I would just like most use CPT a lot and metaboxes. When I think of the cases I used those for, the majority it wasn’t the best UI or experience for users. I was coping with the best tools I had to use.

        Blocks are better tools – in a lot of these cases I am talking about the experience not what lies underneath. If you think of content, it breaks down into blocks. This is a notion design is following with things like Atomic design. Development is the same. Blocks interestingly enough make sense for the human brain. We see in simple shapes. A great illustration of this is how you learn draw by breaking an object down to simple shapes.

        You are correct, latest posts and a whole host of widgets are already being looked at. For reference: https://github.com/WordPress/gutenberg/issues/1594.

        The point about publicising and promoting docs is well made, so thank you for that. It’s a good note to take as a project, so thanks for that feedback.

      3. Tammie – I’ve been pushing for a content block editor for 6+ years when first dreamt of an “image block that could dynamically pull in metadata like a copyright”.

        So… I’m 100% on board with the theory of Gutenberg and blocks. I just want to see the UX be _amazing_ and the DX (developer experience) be amazing too.

        Right now I find the content creation in Gutenberg painful. Way to much pointing and clicking is required. Keyboard shortcuts/nav would help. Content is still doing unexpected things (as of 0.9) when the block type is changed (ie. list to paragraph and back to a list).

        The relates to my early comment about blocks and theme changes. Stuff that’s coming along… just stuff that makes the finish line seem really vague and really far away without major compromises that would make it not _awesome_.

      4. Anyway, I recall reading in there a “latest posts” block being scoped out. I assumed from that, that someday blocks would be able to reference CPT content, no?

        Indeed. (Also, there’s already a “latest posts” block available since several versions ago.)

        The underpinning of that employee block is _going to be a CPT_, no?

        Correct; or maybe user meta-data. The point being—and this also with regard to Mark’s comment above—that “blocks” are primarily about how you interact with data in a visual way, not where such data is stored, which can be on different places depending on the architectural needs.

        Way to much pointing and clicking is required.

        I hear you. Probably next version will include a feature to quickly insert any block by typing / and autocompleting. We still need to get the point-click/tap interactions right since most people won’t discover, remember, nor use keyboard shortcuts.

  8. Hi Matt,

    Thank you for the detailed insights. Gutenberg is definitely going to change a lot of things in WordPress ecosystem.

    I just got to make one thing clear at this point, once Gutenberg is merged into core in 5.0 will it replace the TinyMCE completely, or will be added parallel to that?


    1. Gutenberg uses TinyMCE, so a better way to think of it is that Gutenberg is a new version of our approach to TinyMCE. It will the default experience of WP, for people that want to use something more like what’s currently there we’ll have a plugin they can use.

  9. The whole technology era is based on good changes or reverted bad changes.
    I think Gutenberg is a great shift in the content editing process and along with more small changes will be a ramp for the whole community in terms of flexibility, accessibility, and reduction of dead timings.
    Thanks for these words

    1. I read through your piece carefully along with your replies to some of the basic questions I’ve also had. I may come off sounding naive in my comments/questions, but it won’t be the first time in my 61 years of life. First of all, I appreciate this reply, “…for people that want to use something more like what’s currently there we’ll have a plugin they can use.” I was hoping Gutenberg would remain a plugin, but if that’s not possible, this a poor second as long as it will really give us a similar experience we work in now. I also want to acknowledge and thank everyone who has ever written a line of code in WP from Matt on down. You’ve allowed me to earn money doing what I love.

      When my clients just want a snazzy site without a lot of data, I stick with HTML5/CSS3/JS. When we start getting into a site being data-driven, while I am comfortable writing PHP and MySQL, I’d rather not have to worry about how the dark side is going to try to gain entry this week, so I turn to WordPress for my client. I do so primarily because of it being open source and free – I won’t lie! But I also do it knowing I can tell my customers that they need not fear about their data because of the core code as well as the good plugins that handle security.

      With that possibly boring background, here’s what I don’t get: Why does WordPress, the open source, free environment, feel the need to ‘compete’ with anything? Why the focus on that? WordPress has gotten to where it is as a result of what it is. In essence, why is an open source, free CMS being handled as a business, when it makes no money, never turns a profit, and never will?

      I will continue to turn to WordPress as one tool in my toolbox to best serve my clients’ needs. I’ve used WP and its plugins for the past 6 years because they enable me to build a nice website that does what my client needs it to do in a rapid period of time. When WordPress stops being that, I will turn to something else – maybe these other sites you’re competing against. It’s that simple for me. But here’s the thing: WordPress won’t lose a dime when I do! Therefore, I would hope that the people who continue to make the decisions as to the future of WP would remember who uses it, and why. We are the customers.

      I’m old enough to have learned in my professional and personal life that mankind is resistant to change. However, I’ve also discovered that this resistance doubles and triples when stakeholders feel as if they aren’t heard or they’re not getting the whole story regarding a change that on the surface doesn’t make sense to many. You’ve addressed some of that above, but my question still remains: why are you paying more attention to the ‘competition’ than to the very people who use the product? Everywhere I’ve gone and everything I’ve read say the same points: 1) Why? Why are you going to do this to the WordPress population – put third-party plugin companies completely out of business, confuse my clients so that I lose them, alienate the WordPress community over a vision you have – in general, put this out there, wait for the mess to clear up, and see who’s left? It’s wrong. The community that has taken WP to their hearts don’t deserve this. 2) Why can’t it continue to be a plugin – at least for a year or two? Let the community decide if they want it or not? If the numbers show that a tremendous percentage of developers are installing it, them make the permanent move. This would certainly address the concerns of ‘competition’ while giving the community a choice. In the period of time it is a plugin, we could read about people who have used it for this or for that and how wonderfully it has filled a gap. We could be ‘sold’ on it by our own community. If I hear enough people talking a product up, I’m going to investigate it. I’m curious that way. I think others are too. Conversely, if I read the same repeated questions and negative comments about a product, I’m going to stay away from it until the questions and problems are addressed.

      I believe that something that so fundamentally changes the game for thousands of people who make a living or partial living from WP should be voted on before the first line of code is ever written if it is indeed going to become part of the core of WP. It should be an open process that involves the community – a real democracy.

      As it stands now, my understanding is this: the co-founder of WP has unilaterally decided that this change is what is best for WordPress. After reading the above, it sounds like a business decision for what is after all a non-business. This decision is going to adversely affect some percentage of the community who make their livings from WP, which doesn’t seem to concern the co-founder.

      If my understanding is incorrect, or my alternative idea doesn’t hold water, I welcome enlightenment in the true spirit of open communication. If, however, it is more or less correct, I reiterate my puzzlement over why it’s being handled the way it is.

      Thank you for writing to us about this important change. I welcome more such pieces in the future. They do much to include us into the conversation.

      1. You raise an interesting point (amongst so many other good points, forgive me for pulling out just one):

        “I would hope that the people who continue to make the decisions as to the future of WP would remember who uses it, and why. We are the customers.”

        What exists right now is a WordPress that works for some, but not all of our users. For those it doesn’t work for, it causes stress, real issues and often results in them going to use something else. That something else often is not open source. Business issues aside, that’s not great if you’re passionate about open source to see. I know for me, that feels like the project needs to do better. It’s also often not great for the users as they go thinking it’s a better experience and get trapped.

        Gutenberg and a lot in-fact of the work happening with 4.9 and around WordPress right now, is to make it work for more users. To try and remove those frictions. The points where people just hit a block and can’t go beyond. It’s kind of amazing to look back and see with each release truly the experience is getting better, little by little, for more and more users.

        Feedback in whatever shape is important, it’s crucial to any project. The feedback received so far is shaping Gutenberg. That is incredible and that will continue. Open source is what the people that contribute make it, Gutenberg isn’t going to be any different to that. It’s made with feedback, tests done, patches made, blog posts written, tutorials … the list goes on.

  10. Matt, I’m excited for the potential that Gutenberg portends for the future, but scared to death that it’s implementation will break by existing clients websites.

    We use Advanced Custom Fields extensively and, last time I checked (a couple weeks back), the Gutenberg team reported that they didn’t have solution developed for the PHP meta boxes employed by ACF. I was especially concerned to read that they hadn’t addressed the issue because they lacked resources to devote to the task.

    Is there going to be a version of WordPress that will get long-term support for those WordPress sites that can’t be upgraded to 5.0 without breaking?

    1. There won’t be a version of WP like that, but there will definitely be a plugin that gives you the legacy / old edit page. Make sure to let ACF know that Gutenberg compatibility is a top priority.

      1. Matt, I think there is a fundamental problem that doesn’t seem to be addressed here: the fact that meta boxes can offer functionality which goes past the page block paradigm.

        Take for instance Yoast’s meta boxes – these have no place in Gutenberg as it has been currently imagined, because they are not block components of the page. They are used for meta SEO information.

        For another example, consider an ACF checkbox field that toggles if a post should appear in site searches or not. How would this work as a block? It wouldn’t, because it has to always be there, it’s not something that the user adds into the page.

        So it’s not as simple as the ACF creator working on “Gutternberg compatibility”. There are fundamental issues on a paradigm level. The meta boxes need to remain in the editing page for these kind of functionality.

      2. Since he cares and he listens, I’m sure that Elliot Condon already knows, but I’ll be sure to communicate with him.

        Does a plugin that gives legacy / old edit pages mean I can upgrade to 5.0 and my websites will operate properly?

  11. WordPress shouldn’t call itself a true CMS until it can handle allowing more than one person edit/own content. Without plugins, one of which Automattic *used* to contribute to (https://github.com/Automattic/Co-Authors-Plus), this isn’t possible. The concept of a “group” seems foreign to WordPress, so how am I supposed to roll this “CMS” out to my users if they can’t collaborate? I’m supposed to tell my marketing department that each person can only work on content they created? Or am I supposed to throw privacy and security to the wind and give all my users the ability to edit everything in the system?

    C’mon folks, it’s 2017, instead of trying to re-invent the editor how about you finish adding the core CMS functions that your competitors already have?

    As for Gutenberg, I’m very concerned about how this will be forced upon developers, users, and admins. A change that’s a big as this should be eased in, not flipped like a light switch. You’ve seen the outcry and feedback, yet you seem to be ignoring your core base of users, which could be a very serious mistake.

    1. Thank you for your feedback, we’ll definitely keep multi-author support in mind for future versions. The vast majority of WP sites only have a single author, so it’s been an area we’ve thought best left to plugins so far. There is an update for co-authors plus on the horizon, and it will be updated for Gutenberg, it would also be great for other enterprise WP hosts besides VIP to contribute more to foundational enterprise plugins like that.

      1. The vast majority of WP sites only have a single author,

        You happen to have any data available to back up that statement, or is it grabbed out of thin air just like all your statements involving numbers?

      2. Piet, I do! 96% of sites that run Jetpack have a single author. It’s a little higher on .com. The “grabbed out of thin air” part of your comment stung a little, please consider being nicer when writing on the web because comments can read harsher than you may have intended.

      1. It’d be nice if the issues with React licensing could be discussed in the open vs behind closed doors. I understand security issues being kept private, but not something like this.

      2. In fairness React licensing issues have been discussed pretty openly in several venues. WP Core has been pretty clear that there hasn’t been a decision made yet. I’ve also personally inferred that at this point they want a little space, or cooling off period, before bringing it up again.

        I think many feel like Gutenberg is forcing the issue (I feel that way). However, the Gutenberg team said at the outset that choosing React because that is what they were most comfortable with at the time and needed to get started and go fast. That decision didn’t, and hasn’t, obligated core to React. I fear it’s biased things tremendously, but that’s different than making it a forgone conclusion.

    1. I also think the lack of main-column metaboxes are an issue. Another section for metaboxes under the main content seems important to have, as things like Yoast, Woocommerce or an ACF repeater field are going to struggle to fit on the current right-side column, and auto-expanding the right-side column seems disorienting, reminiscent of Windows 8 which removed the start button only to bring it back. The mental workflow / eye-tracking path also is to continue on to those meta boxes below after writing the main content before bouncing back up to hit publish.

  12. Thanks Matt for this thorough post on your views. While I do not agree with everything in Gutenberg (and have posted my thoughts in relevant places), I do feel that this project is something WordPress has needed for quite some time.

    The thing to remember that while it “appears” that the community is against this, the WordPress conversations tend to be dominated by a few loud voices in the community. With WordPress being used by millions, it is hard to accurately get the community’s opinion based solely on 20 to 30 voices seen on WP Tavern comments or Twitter.

    The fact of the matter is that the loud voices are not always typical of the average WordPress user as we know that the average user isn’t usually the one keeping up with WordPress news on places like WP Tavern.

    Also, can you link to the source of the “the 157 million small businesses without sites” stat? Would love to read more of that study’s context.

  13. As lead developer of the Pods plugin, I’m glad to hear that legacy php meta boxes will be supported for a few releases at least. I’m very excited to start using the new meta boxes from Gutenberg once the API supports it and gives us more to utilize. As soon as that’s available, count us in for immediate adoption.

    I definitely can’t help but think that if Fields API was in core prior to Gutenberg, the whole problem behind legacy php meta boxes could be at least somewhat mitigated because they could use similar code that would just ‘work’. I hope that Gutenberg accepts PHP configurations for the boxes / forms, similar to how Customizer works (it does a bunch of JS!)

    I haven’t had as much time as I wanted to be able to spend on Fields API since I’m no longer sponsored by a company to spend countless hours tweaking it and lobbying for it’s inclusion. But the need is still there. Do you see Fields API still being a priority after Gutenberg is released, or will the Gutenberg API eventually replace everything in core with some sort of unified API that lets you interact everywhere you need to for Posts, Terms, Users, Comments, and Media (along with other custom meta types as plugins add their own).

    1. Change is inevitable… and kudos to all the changes you’ve helped push over the years to make WP what it is today, despite push-back.

      Overall, the concept of Gutenberg is great, and I agree that we do need a better interface if WP is to grow long-term, I can see Gutenberg being (one of) the next big step(s) for moving the WP project forward. I’m not saying I’m welcoming this with open arms just yet, but I’m hopeful and look forward to being able to do some awesome stuff with it!

      However, from a plugin developer point of view, I find it quite scary to be hearing about release plans for a core part of WordPress when there are no clear plans/documentation etc. about how plugins and custom post types that rely on meta boxes will integrate with it. It’s coming off as very premature…

      As an example relevant to your endeavours… WooCommerce; How can you create a product in the Gutenberg editor? A product is partly visual, but then there’s lots of data associated around it that needs to be input on the product editor, and I don’t think the sidebar on Gutenberg is a fitting place for it… the fact that there seems to be little in consideration about these kinds of plugins worries me.

    2. I definitely can’t help but think that if Fields API was in core prior to Gutenberg, the whole problem behind legacy php meta boxes could be at least somewhat mitigated because they could use similar code that would just ‘work’.

      I tend to agree. There are areas—as Gutenberg communicates primarily through the REST API—that would benefit from further development on the API side. If we had endpoints that handled the display and communication of meta-related functionality it would simplify interoperability of the two paradigms.

      A product is partly visual, but then there’s lots of data associated around it that needs to be input on the product editor, and I don’t think the sidebar on Gutenberg is a fitting place for it…

      Plugins like WooCommerce have been definitely considered. In many ways, they are the reason why blocks of content are being pursued. Blocks won’t be tied to showing purely presentational content. You could render a full meta-box in the place of a block and handle saving through the API outside of post_content. There’s a lot of flexibility there. Blocks are about how you interact with the data and providing the clearest experience to users, as it’s often cumbersome to connect how data on a field is going to affect how things look. It’s about giving a consistent way and UI expectation to users.

      Some things that currently exist as CPTs probably won’t have to be anymore, specially if they are purely about presenting rich content. Of course, valid use cases for post types would remain, and things like disabling the block editor, or setting up CPTs with already configured blocks that act as meta-boxes and cannot be remove by the user, should provide a lot of flexibility in terms of development.

  14. I’ve tested a few Gutenberg releases and do see the huge potential it can have, especially when multiple columns / nested blocks (https://github.com/WordPress/gutenberg/issues/428) gets solved. Mixed with the 4.9 target of Customizer changesets and it paints a VERY compelling user experience.

    Can you expand a bit on your employee bio example from “Developers / agencies” paragraph? It hits on two aspects to Gutenberg (CPTs and post meta) that I have struggled to understand the rationale for and/or how to approach in the post-Gutenberg-in-core world.

    1) Why would the bio NOT be a separate CPT with it’s own required block structure (office, phone, manager, skills, etc)? That way a theme / template could offer a corporate directory of sorts and the ‘About page’ would then use an “Employee block” to pick from created employees akin to how image block can pick from media library.

    2) Implementations that leverage meta frameworks (ACF / CMB2 / Pods / etc) for data entry generally rely on access to that data via wp_query arguments or Rest API to build advanced layouts and functionality. Will block level info be similarly queryable? How would one filter employees by location / skill / etc? Or going further on the customization side would a plugin like FacetWP have anything in the block world to hook onto?


  15. Hey Matt – I think most people are open to Gutenberg, even enthusiastic about the long term prospects. And I think most recognize this kind of change is needed to keep the WP editing interface fresh and up to speed in a competitive digital landscape.

    But EVERYONE I know is profoundly concerned about the impact on backwards compatibility and the existing theme and plugin ecosystem.

    Historically, WP development has placed great emphasis on compatibility. But by it’s nature, Gutenberg has more breakage potential than anything in recent WP history. And I’ve seen many indications that the Gutenberg team has either a) put eye-brow-raisingly little thought into compatibility concerns given the magnitude of this change or b) has simply accepted that breaking compatibility is the cost of progress for such an important change.

    This openness to breaking things seems to be compounded by a desire to move too fast on what is an epic change.

    As a result, many in theme and plugin community, and many developers/freelancer/agencies who have deployed highly customized sites, are legitimately concerned that you all are about to drop a bomb on the ecosystem.

    Bomb = widespread breakages, massive frustration among end users, massive time and monetary costs on the developer community to adapt codebases and fix broken sites, and all of this likely done under conditions of crisis and urgency because the project was rushed to release before the ecosystem was ready for it.

    You have a history of profoundly strategic and careful thought about such issues, so I’m sure you’re aware of the negative possibilities here.

    Would you willing to share your thoughts for how important compatibility concerns are to you during this process, or conversely how willing you are to tolerate compatibility breakages for the sake of getting Gutenberg out?

    PS. A secondary, special request: I don’t know what the timing expectations are for WP 5.0, but can we please, please, please not do an epic release of this kind at the end of this year just before the holiday season? 🙂 Doing may well ruin holidays for thousands of us throughout the ecosystem if we need, as expected, to work double time to adapt our codebases and respond to crises resulting from the release.

  16. Hi Matt,

    Thanks for sharing this. I am excited about the possibilities Gutenberg brings especially for users. The fact that users won’t deal with shortcodes and yet build awesome websites is a great move forward.

    In general, with what you have outlined in this article and your replies to some questions, Gutenberg will be of great benefit to everyone in the long run despite having negative feedback from developers in the plugin’s review page.

  17. Something like Gutenberg is overdue. We need modern content creation and layout tools. I appreciate that you are willing to take a risk and I think that reinventing the editing screen is both big enough to make a difference and focused enough that it shouldn’t take years to achieve.

    Has a decision been made on what the legacy meta box support will look like? Or are you just saying that we won’t be happy until we figure it out?

    I appreciate your communication, especially about not shipping it until it is ready (did you see what I did there?). Onward and upward.

  18. Matt, please fix the form builder situation next.

    Each form builder has its own ecosystem, strengths, and problems.

    It would make more sense for there to be a basic form framework every form builder (and theme, and general plugin) can build off of.

    I’m building a site right now using Beaver Builder, Popup Maker, and Gravity Forms. And each one has an option for capturing leads and sending it to MailChimp.


    I welcome the day when I can switch out a form extension without having to replace every form on my site.

    Thanks for hearing me out.

  19. Thanks for this Matt. This seems a logical evolution to address some of the issues WP has developed over the years.

    What I would say is that uncertainty is the enemy here, as you have eluded to. For example, those of us running micro-agencies supporting small-time businesses and non-profits have developed fairly complex solutions using tools such as ACF to work around the limitations of the native post editor.

    What we’d like to understand is how long these solutions will stand up for as WP evolves though the versions post-5.0? While redeveloping these themes to use the new core ‘blocks’ features might be the ideal solution, many loyal clients may not have the capacity or will to invest in this. Given the majority of WP sites don’t have enterprise grade investment behind them, longevity matters. In fact, one of the reasons we stopped using Joomla for client work was the number of road-blocks that kept being erected in the upgrade path.

    Encouraging innovation while protecting legacy users is always a tricky act to pull off. Thanks for your work in this community.

  20. Gutenberg does sounds like a cool idea, if everything goes well it will revolutionize how people create websites, I tried the plugin and I liked thought behind it but if you want to compete with Wix or Squarespace or even weebly you have to improve the plugin by heaps and bounds. I will try my best to give suggestions on improving the plugin in the github page. Thank you.

  21. Uff. I’m so happy.

    I finally be able to build the sites I see in my imagination. If I’ll be able to do things on mobile I’ve never been able to do before… and kill the need to see a shortcode again. That is just great.

    It’s time to wp.

  22. Dear Matt:
    I am a founder of a blog (wpnovatos.com) and conductor of a weekly podcast in Spanish where I periodically post content to help beginners understand and use WordPress.
    I think your comment is great, as an idea of ​​the future. However, I have been able to test the Gutenberg plugin in phase “Alpha” from the beginning and to this day I still do not find the utility you explain.
    Both my personal opinion and that of most of my readers, all I get using the blocks is a waste of time in the layout of any post.
    Something I do now in 5 minutes, it would take more than 15 to do with the blocks … if this happens to regular users of WordPress, I do not want to imagine how long it would take to do a small company that is not accustomed to working daily with This tool.
    Keep in mind that working with a Word document is something that the vast majority of us are accustomed to make it easier for everyone to use the current WordPress editor.
    I reiterate that, as an idea I think is great, but I do not see right that we force all WordPress users to use it. Perhaps the best option would be to leave it as a plugin and make its use optional by users who favor this tool.
    In any case, I applaud your effort to try to improve the tool to be able to compete with platforms like Wix and I ask you, please do not rush into the launch of Gutenberg.
    Most sincerely.

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

    I feel like this type of thing is where the community gets less interested in your vision and more worried about its implementation. “Gutenberg will ship with the WordPress next version after Gutenberg is ready—and here’s what ‘ready’ means…” would ease many concerns.

    For lack of a better term, it feels like WordPress is being held hostage by an unclear vision. It’s clear to you—and, perhaps, a few others—but the rest of us see something half-baked. With that comes valid concerns that Gutenberg will actually ship earlier than it should in order to not hold up the release, thereby causing disruption to millions of people.

    To alleviate those fears and help others gather around your vision, I think being more public about what “ready” means would go a long way. It gives people something concrete to respond to—whereas right now, it can feel like we’re debating about something in your head. I would welcome that type of leadership on this project and I think others would appreciate it, too.

  24. How will Gutenberg effect current Page Builders like Elementor, Beaver and Divi? Will those still work? Do those devs need to make many changes or will they become obsolete?

    1. Several of the page building plugins have been talking and working already with the team that is focusing on the next stage after Gutenberg. That’s going to be the Customization focus. It’s a little early to say what route that will take. Gutenberg is focusing on the editing experience right now.

      One thing to note, testing and lots of it with every plugin will be needed, as Gutenberg reaches merge proposal.

  25. Hi Matt
    I’ve been using WordPress since the beginning, when an installation of WordPress was a terrifying (I’m not techy at all) adventure.

    Gutenberg sounds amazing — just what I want. Over the years I’ve had many WordPress sites, and I love WordPress even more than I did in the first years.

    I’m looking forward to Gutenberg; it sounds as if it will reinvigorate my websites. And my business, come to that.

    A huge THANKS! for all you do, to everyone involved, and to you, for having such a clear vision. You know what I want before I have a clue myself.

    Can’t wait to use Gutenberg. 🙂

  26. Hey Matt! Thanks for the post. I’m wondering, will Gutenberg work well with page builders like Elementor and Beaver Builder and the newest I saw was Sekta? Or will it completely make those useless and thus any sites built using them would suffer some form of incompatibilities? I tested the beta in very early stages, and I certainly will go test again soon and in particular how it plays with these builders, but would love your input as to plans for how it will work with things like this going forward.

    On another note, what about plugins like ACF and MetaBox? Will those be functional too after Gutenberg is released into the wild? I love that this will make WordPress easier for tons more people, and actually from the screenshots I’ve seen, it make WP come back up to speed to play against all the new ‘options’ out there. Excited!

    1. It is still a little early to say what will happen to plugins and builders. Initially Gutenberg is focusing on the editor. The next stage is for the Customization focus (the building of pages).

      One thing that will need to happen is a lot of testing of existing plugins with Gutenberg. That’s how we can ensure things do work and limit issues. Ultimately though more and more plugins won’t be needed – or at least so many together to achieve simple things. This benefits users and creates a better, more unified experience for all.

  27. “I also would love more testers of the the Gutenberg plugin.”

    How would one get involved in that Matt? Have some time to give back to the WordPress community and my background is as a Quality Assurance Tester.

    1. More testers the better Darren, thank you so much for offering to help there! Currently there are some tests here: https://make.wordpress.org/test/handbook/call-for-testing/gutenberg-testing/.

      If you keep your eye out in the next week or so on: https://make.wordpress.org/test/, a testing plan call will be going up. That’s the ‘home’ of testing for WordPress and maybe of interest to you anyway. This call will be for amazing people like you to help contribute.

      Again, thanks because testing matters and experienced testers like you really help the project.

  28. Hi again! I’ve been returning to this post over and over just to see the comments section. I just started this year to learn about web development using WordPress; One thing that isn’t crystal clear to me is if Gutenberg would make kinda obsolete the need for plugins like ACF and Pods to create Custom Post Types and Fields. I’m running a new entertainment blog where post types such as book reviews and movie reviews with their proper custom fields will become something really useful.

    But now I’m restraining myself from doing this, and instead I’ll keep posting new entries as simple as possible, so when Gutenberg comes out officially, the transition won’t be that complex. So, is it right to thing that I’ll be able to create custom post types and fields with Gutenberg?

    Thank you so much in advance! I hope you can work an integration with Amazon S3 buckets and improve the current gallery widget on Gutenberg, including a lightbox feature.

    1. Roverd – Awesome you’ve joined the ranks of those using WordPress for web development. You’ll find a huge support community around the world!

      To answer your questions Gutenberg will not make plugins like ACF and Pods obsolete. Nor will it make page builders like Beaver Build obsolete. These plugins will likely adapt to Gutenberg or new plugins will come out that provide similar functionality with better integration with Gutenberg.

      Gutenberg will always be an content editor, but it will never create custom content types (CPTs and Custom Fields). It also will not provide every advanced type of block you might desire. For example you might want a “Book” CPT, and you might want a block that displays that as a book cover, author name, excerpt and ISBN number. Maybe that would call come from custom code, or from a plugin called “Book Content Type” or maybe a combination of Pods and Beaver Builder… at this point we don’t know all the things people will do with Gutenberg.

  29. If it will give us everything ACF does then it will be great to not have to use an extra plugin for new sites and not having to deal with weighty/clunky page builders for off-the-shelf template sites. And having this for pages rather than posts would be good although I can see it being useful for posts too…

  30. I would suggest making it possible to disable Gutenberg. Also, I hope it won’t mess up the older WordPress posts. If these points will work, it should be OK and I’m looking forward to trying it.

  31. I probably won’t jump on board until I see how the dust settles but I am looking forward to seeing a serious attempt at something revolutionary. For a while I’ve wondered how in 5 or 10 years from now WordPress will possibly be able to compete. It’s already being held back by its older parts. I’ve been dreaming of a total rewrite a la Ghost but Gutenberg is exciting.

    “Some folks have already begun to port their plugins over, and are finding that they’re easier to build and have a much improved UI. I’m looking forward to highlighting those stories as we get further along and more people write about them.”

    Please do!

  32. Hey Matt – I just wanted to say keep up the great work on Gutenberg, I have always loved the idea but was a little scared by the earlier beta versions but now I am loving seeing the weekly improvements – it’s kinda the highlight of my week.

    The team is doing a great job to incrementally fix bugs and make improvements. The pace of what they are achieving is outstanding.

    I’m also on a personal level really happy with Gberg now – I’m using it for writing on my own site and am very close to using it in production, it has the potential to really improve my workflow (especially once front end editing comes into play).

    I’m personally really excited for the future of WP.