Gutenberg Engineer Matías Ventura Unpacks the Vision for Gutenblocks, Front-End Editing, and the Future of WordPress Themes

photo credit: KaylaKandzorra i miss you grampa.(license)

In a post titled Gutenberg, or the Ship of Theseus, Matías Ventura breaks down the vision for how the project will transform WordPress’ content creation experience and the decisions the team has made along the way. Ventura describes how WordPress has become difficult to customize, as online publishing has embraced rich media and web design has evolved in complexity over the years.

“WordPress can build incredible sites, yet the usability and clarity that used to be a driving force for its adoption has been fading away,” Ventura said. “The present reality is that many people struggle using WordPress as a tool for expression.”

Ventura’s words hint at the growing threats from competitors whose interfaces define users’ current expectations for a front-end editing experience. If WordPress is to stay afloat in a sea of competitors, it can no longer continue expanding its capabilities while leaving a disconnect between what users see while editing in the admin versus what is displayed on the frontend.

“WordPress has always been about the user experience, and that needs to continue to evolve under newer demands,” Ventura said. “Gutenberg is an attempt at fundamentally addressing those needs, based on the idea of content blocks. It’s an attempt to improve how users interact with their content in a fundamentally visual way, while at the same time giving developers the tools to create more fulfilling experiences for the people they are helping.”

Ventura elaborated on the foundations of the block approach to content creation and how it will expose more functionality to users in a unified interface, bringing more opportunities to the plugin ecosystem. The post offers some clarity for those who have been wondering about the decision to “make everything a block.” Ventura also anticipates that blocks will become a big part of WordPress theming in the future:

Themes can also provide styles for individual blocks, which can, in aggregation, fundamentally alter the visual appearance of the whole site. You can imagine themes becoming more about the presentation of blocks, while the functional parts can be extracted into blocks (which can potentially work across multiple theme variations). Themes can also provide templates for multiple kind of pages—colophon, products, portfolios, etc., by mixing blocks, setting them up as placeholders, and customizing their appearance.

Ventura also introduced a few new possibilities that Gutenberg could enable. He shared a video showing how granular control over each block can pave the way for a future where WordPress core allows for real-time collaborative editing. This is a feature that has been painfully lacking from the CMS but is nearer on the horizon with Gutenberg in place.

“This same granularity is allowing us to develop a collaborative editing framework where we can lock content being edited by a peer on per block basis, instead of having to lock down the whole post,” Ventura said.

Ventura sees Gutenberg as the path to finally bringing front-end editing to WordPress:

Once Gutenberg is capable of handling all the pieces that visually compose a site—with themes providing styles for all the blocks—we end up with an editor that looks exactly like the front-end. (And at that point, we might just call it front-end editing.) Yet we’d had arrived at it through gradually improving the pieces of our familiar ship, in a way that didn’t cause it to collapse or alienated the people aboard. We want to accomplish this in a way that would allow us to refine and correct as we iterate and experience the reality of what is being built and how it is being used.

He likened the challenge of the Gutenberg project to upgrading the materials on a ship while ensuring that it continues to sail. As there are many passengers who depend on the boat, completely breaking it for the purpose of rebuilding is not an acceptable way forward.

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

Comments are not enabled on the post, but it has received mostly positive feedback on Twitter. For some, it clarifies the direction of Gutenberg, the purpose of blocks and the possibilities they enable. Others in the community are on board with the concepts behind Gutenberg but are not comfortable with the tentative timeline for its inclusion in core. Ventura’s post does not address many of the more practical concerns the community has about allowing enough time for the WordPress product ecosystem to get ready for Gutenberg.

Matt Mullenweg has confirmed that Gutenberg will ship with WordPress 5.0 whenever Gutenberg is ready and most recently said that delays on selecting the JavaScript framework “will likely delay Gutenberg at least a few weeks, and may push the release into next year.”

Last week, a post published by Yoast SEO founder Joost de Valk sparked conversation with his proposed alternative approach to Gutenberg, which calls for a slower, staged rollout for plugin authors.

“In this point of time, it’s not possible for plugins at all to integrate with Gutenberg,” de Valk said. “How on earth should plugin authors be able to build their integrations within a few months? That’s not possible. At least not without breaking things.”

His proposal recommends keeping the idea of blocks and making over the admin for WordPress 5.0 but leaving the meta boxes and toolbar untouched.

“We are very enthusiastic about the idea of blocks, but have strong concerns about some of the technical choices and the speed of the implementation process,” de Valk said. “We are also worried about the lack of priority given to accessibility issues in the project. But most importantly, we are very much concerned about the fact that plugins are not able to integrate with the new editor.”

It’s impossible for developers to have a clear understanding of the right way to extend Gutenberg right now. The JavaScript framework for the plugin has not yet been announced and critical issues regarding how block data should be stored are just now being floated for discussion.

“The Editor/Gutenberg team would like the broader core group to start thinking about and discussing how block data is stored,” Ventura proposed during last week’s core development meeting. “We currently (specially after allowing meta attributes) have a lot of ways to store block data, with different tradeoffs. It’s going to be important to communicate when each is appropriate. This will come through examples and documentation, but generally such knowledge has also spread by core contributors doing talks and blog posts, etc.”

Further collaboration from the broader community of WordPress core contributors should bring the project closer to being able to deliver the documentation developers need in order to follow best practices for extending the new editor. In the meantime, Ventura’s post is a great read for understanding the larger vision behind Gutenberg and where it is headed.


16 responses to “Gutenberg Engineer Matías Ventura Unpacks the Vision for Gutenblocks, Front-End Editing, and the Future of WordPress Themes”

  1. New low in how core developers avoid community feedback. Apparently now it is not enough to subscribe to make email updates, follow discussions on slack and follow development on github, but you also need to follow all developers on twitter and friend them on facebook.

    • That’s not really a fair assessment, Mark. 😕

      Matías wrote a post about the vision for Gutenberg, his personal blog is a great venue to publish it. The post has been widely shared on Twitter, and now has a Tavern article written about it, less than 24 hours after publishing. Even if it wasn’t published through an official channel, it’s pretty hard to miss.

      Feedback is always welcome, I’m sure Matías will be reading the comments here, if there’s anything in particular you wanted to bring up.

      • Very well @Gary, but there was never any discussion about this stuff, there should be a community discussion before such things even start development. I for example to not see any competition to wordpress that anyone in the community which is not in the hosting businesses should care about. Obviously, just because I am not in that businesses (gained some black hair since I stopped doing that) do not mean that automatic, wp-engin, godaddy etc do not deserve to be heard, but there should be a discussion even if it is obvious automattic controls the cards. It might also be useful for automattic, because it is not secret that there are some smart people around here that do not work for it, and maybe they can contribute something smart.

        And from the more realistic aspect, in wordpress core, whoever writes the code control the feature. From that perspective there just can not be a “private” post by Matias about gutenberg.

        Related sidenote: Last core meeting we were promised a discussion about the comments in the post content issue. Almost a week later, and a guy starts wonder if there was a discussion but it was “private”.

        Unrelated sidenote: I hope no wordpress user read that post because basically it says “wordpress users are technological idiots that can not learn anything, therefor we should aim to their limited technical IQ level”. I do not remember when was the last time that I worked for someone that technology challenged, including the guy that basically does tourism blog site.

    • Perfectly said. This is being done in such a way to generate the illusion of discussion and the appearance of visibility, while in reality the users/developers are being ignored in favor of hosting companies and insiders.

      If I was running a company, a post on my personal blog as the authoritative post determining the direction of the company would be strange to say the least.

      To think that shares on Twitter mean having discussions is hilarious. “Widely shared”? Really?

      This is a train wreck and the apologies for it are even worse than the original problem.

  2. Kudos on this strategy:

    With the abstraction blocks provide, we can also build several tools that take advantage of the fact the full document is broken down into smaller units with semantic value

    Given the explosion of different devices with different screen sizes and ways to interact with them (be it a laptop, smartphone, smart TV, Apple Watch, the new Google’s in-ear headphones, or who-knows-what-else will come in the future), a CMS needs to have true separation of content from form. Otherwise, when a new device comes out and we need our content accessible there too, we may discover that it’s not suitable, and will have to spend looong time and money to reformat it accordingly. (Source: presentation Content in a Zombie Apocalypse, by Karen McGrane.)

    Having documents split into smaller units will help capture the content in a cleaner, presentation-independent way. It makes WordPress more resilient, readier for the whatever the future may bring along.

  3. Firstly, thanks for featuring this article Sarah. It’s great to get more insights into the project out there.

    Mark k, you raise a good point about making sure all articles like this are known about. That said, in this case it certainly has been widely spread. As with anything I am sure we can all get better at surfacing the content.

    It’s worth considering that sometimes a lot of getting feedback isn’t visible. You may not see people reply to forums, reviews, reading all feedback and taking time to reply to comments on blog posts. It’s being done though.

  4. Really well written article. It’s the best explanation to date of the vision and purpose of Gutenberg – should be part of official documentation IMO.

    It sure is an ambitious plan though and seemingly a long way from the current plugin. Doing all that they plan to do while maintaining backward compatibility and not inciting a riot from folks scared of such a big change isn’t a task I would want to take on. So if nothing else kudos to the team for its courage.

  5. There is one thing I do not understand. If the goal is to make this a front end editor, then why isn’t it a front end editor?

    It’s one thing to say we will have an editor that “looks like front end”, versus an editor that actually activates in-place, while a logged-in user is on the front end.

    Also, the goal of collaborative editing on a page while locking/unlocking elements on the page seems to be a pretty narrow use case. Is this really a gaping hole that users are begging for?

  6. The thing about building your business on WordPress is that you have to get it in your head that, while perhaps not technically speaking, WordPress is Matt Mullenweg’s project.

    So, knowing that, and seeing that thus far he has lead WordPress down a path that has profited tens of thousands of us over a long period, it becomes easier to accept his vision for Gutenberg.

    Bring it on.

  7. The problem with the Gutenberg project is less the technical vision than several other things. In no particular order:

    1) The market and enduser vision, i.e. the main rationale. Having a clear vision here should have led to a list of features that need to be done in order to get a credible v 1.0 out the door.

    2) The lack of consideration given to things like metaboxes which made people feel like the team wasn’t thinking things through.

    3) The lack of a roadmap with any detail. “5.0” is not detail. We have little to no insight into what features are being planned, what the timeline is, what the minimum features for a 1.0 Gutenberg are, etc.

    4) The lack of a strategy for dealing with compatibility. How is this being testing with Divi, Avada, Woocommerce, etc? What about Pods, ACF? What if a site doesn’t have a current version of those? What about custom post types?

    5) The assertion that this WILL ship live in 5.0 and not have a controlled rollout with life as a beta/RC level plugin (where features are frozen). Given that we’re on 4.9 that feels like it’s very soon. Speaking of soon…

    6) The utter lack of any date transparency. It’s one thing to say “5.0 will ship when Gutenberg is ready” but a) who decides what ‘ready’ means (see above) and b) what if Gutenberg really isn’t ready for 12 more months? Will the release really be held that long or will it be shoved out the door? This is exacerbated by statements saying things like the JS framework decision “will likely delay Gutenberg at least a few weeks, and may push the release into next year” when it’s utterly ridiculous to talk about a Gutenberg release in the next 3-4 months.

    Sorry, core, but this project hasn’t been well managed from any of these standpoints and the fact that we STILL lack transparency on the roadmap from both a time and features perspective and that we’re getting semi-official statements scattered around the web vs in a central, official place does not inspire confidence.

  8. I found his vision compelling, and look forward in hopes it can be realized.

    However, he made one statement that I find very worrisome, as someone who has literally spent the past month on two different MySQL data merging and cleanup projects with over a GB of content each:

    Blocks are also able to save attributes in meta fields, if needed, granting continuity to existing features. Overall, the concept of the block is not about where it stores data, but how the user interacts with it.

    The worrisome part is that his statement implies that meta fields will be the proverbial “red headed stepchild” when compared to structured data in $post->post_content. And from that I am concerned that most WordPress authors will end up storing independent data in post_content rather than in meta fields because they won’t know any better.

    Why does this matter? It is effectively impossible for create reliably WHERE clauses in SQL on the structured data that will be found into post_content. And it is effectively impossible to reliably update MySQL data using SQL UPDATE statements into a structure post_content.

    The project I just worked on for one (1) month would have taken three (3) months if not more had much of that data been in post_content!

    The same is true when some boneheaded plugin developer decides to store PHP serialized data in meta fields. (Carbon Fields did that in version 1.0, but thankfully fixed it in 2.0. The project I worked on included in-part moving or version 1.0 to 2.0 )

    I really hope to see that all fields have an option for storing in post meta and that really good inline wizard explains to
    walks the user through selecting the proper storage method.

    • I shared the same concerns. We are currently building a web app using WordPress as a CMS with the help of ACF. We have 10 different custom post types and each CPT uses 15 custom fields on average. All the custom post types are linked to each other via bidirectional relationships.
      We don’t use the tinymce editor at all for any of the CPTs.
      We certainly hope that post meta data will not be stored in post_content. How would we query the post data using GraphQL or the REST API!?

  9. Honestly, I think publishing an article trying to wash the face of the Gutenberg project and not open the readers’ comments, is not to be too brave …

    It was a good attempt for Matías to try to convince us that it is “obligatory” to make a drastic change to move forward.

    I agree that the improvements are really necessary, but the complete improvements, not the mid-improvements, with schedules made to counter, trying to finish in record time a project that has been stored for years in a drawer.

    As much as Ventura says, the project does not favor the daily work of an average user at all, it slows down and delays a lot of publication as I have explained several times.

    It does not compensate the time investment that requires writing a simple post with Gutenberg with the result you get.

    I still think that the best option is to leave it as a plugin and that user who really wants to use it.

    When on the part of Automattic have to be constantly justifying why Gutenberg is wonderful, let’s think about the reason … surely over the coming year we will have a plugin (freemium) that will adapt perfectly to Gutenberg and there we will know the real reasons for this drastic change.

  10. I understand the worry of the community. Change is scary and let’s be honest a lot of people have a legitimate dog in this fight. That said I am taking a wait and see approach. As it currently stands it’s obviously not ready for prime time. I do feel that in when it finally goes live it will open a bunch of great possibilities. Block level control with attaching meta to a block as opposed to a post sounds interesting to me. It might even be interesting to see custom blocks although it sounds like you will be able to write custom code to control block output. Exciting stuff.

    Worst case there will be a mass exodus to Drupal and wordpress and joomla will chill in the corner. I’m still pulling for you WP!

  11. Storing structured content in raw HTML with comments is not an acceptable path forward. It means that any time the HTML standard evolves, or a design change requires a change to HTML syntax, that has to be made in every post. Then, by allowing users to enter “html mode”
    and manually modify the structure, they are guaranteeing that updating all the posts programmatically will fail for some posts.

    When you throw away everything that is good about structured content, in the name of smooth continuity, what you are looking at is a Ship of Feceus.


Subscribe Via Email

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