Gutenberg 1.1.0 Adds Autocomplete for Blocks, Developers Elaborate on How New Editor Will Work with Themes

Gutenberg contributors continue marching forward this week on their relentless drive to improve the usability of the controversial new editor that will ship with WordPress 5.0. Meanwhile, discussions about Gutenberg’s timing, implications, UI, architecture, and other aspects of the project continue across the web, as the community grapples with what this new editor will mean for the future of WordPress.

Version 1.1.0 was released this week with a new autocomplete-shortcut for adding new blocks without leaving the keyboard.

Many testers have been frustrated with the amount of pointing and clicking required to create new blocks. Autocomplete for blocks is a new feature that partially answers this problem, but it relies on the user knowing that typing a slash / in a new default paragraph block will trigger autocomplete. It may also be added to other blocks in the future.

“We still need to get the point-click/tap interactions right since most people won’t discover, remember, nor use keyboard shortcuts,” Gutenberg engineer Matías Ventura said in response to user feedback on the plugin.

This release of the plugin adds the ability to remove images from the gallery block inline. It works smoothly and resizes the thumbnail previews to fit the available space after an image is removed.

Version 1.1.0 also includes small updates like the ability to set links to open in a new window, accessibility improvements to the add-new-category form, caption styling for video blocks, adjustments to column width calculation in the gallery block, and many other tweaks and improvements. The Gutenberg docs also received an updated design and improvements to the content.

A Preview of How Gutenberg Will Interact with Themes to Build Websites

Gutenberg engineers elaborated on how they expect the new editor will work with themes in a post on the make.wordpress./core blog. Matías Ventura published two video examples to demonstrate where they see Gutenberg headed on its journey towards becoming a full-fledged website building tool. Ventura said this is the long-term goal after the project completes the post and page editing milestone.

The first video shows how Gutenberg can be used for page building, starting with a blank slate and a theme that defines specific styles for blocks. The second one shows how a theme might include templates with blocks already in place that provide users with a guided page-building experience.

These examples clarify some of the benefits the team is aiming for with Gutenberg and how WordPress theme authors will be able to build more user-friendly experiences on top of the new editor.

“These are quickly put together, but I hope it shows how things can progress even with very straightforward theme integration,” Ventura said. “As soon as we expand the scope and include more blocks (site title, site header, menus, more widgets, etc), and describe a way to store page templates as a «list of blocks», Gutenberg would be fundamentally capable of building an entire website.”


27 responses to “Gutenberg 1.1.0 Adds Autocomplete for Blocks, Developers Elaborate on How New Editor Will Work with Themes”

  1. The video in this post demonstrates how Gutenberg would deal with a custom post type “book”, as it was raised in a comment on a previous post, so this is very encouraging and I congratulate Matías for producing this video. However, it still doesn’t explain how the meta data (page count, publisher, release date, star rating) would be dealt with, I’d love to see that next.

    • More importantly it doesn’t explain how to link the CPT “Book” to a CPT “Author”

      • That’s well outside of the scope of Gutenberg. 😉

        Post-to-post relationships is an interesting problem, but, to take Book/Author relationship example, it can be served by storing the Author ID in the the Book postmeta (and potentially vice versa, for simple lookups in both directions).

    • As far as storing and retrieving data from postmeta goes, I think this could be handled quite nicely for folks transitioning their existing metaboxes to blocks.

      Take this small example of a “Stars Block” that I put together just now (my first ever Guten-block!). It currently stores the star rating inline, in post_content, but that’s really only a very small part of how the block works. So small, I didn’t even need to define where it was being stored. If I did want to define where it was stored, the attribute definition can take an optional `source` parameter, which currently refers to how the attribute is being stored inside post_content, but this could potentially be expanded to allow meta fields to be defined.

      I don’t know if this is the best way, it will take some exploring to find the right way, but hooking postmeta data sources to blocks is certainly not an insurmountable problem. You can read some more discussion on the topic in this issue.

    • I was the one who wrote that comment. I really appreciate seeing a clearer example of how a workflow like that would work.

      I still see big problems with letting users change design elements (i.e. image sizes) and reordering blocks – I hope there is a plan for some sort of block-locking ability or a way of turning off certain block features. But the more I read about Gutenberg I think I’m starting to see the vision – this really does have the capacity to radically change WordPress, which just underscores how much it needs to be done right.

    • Is it still developing using ReactJS?

      Yep. Per Matt Mullenweg there’s supposed to be an “announcement”or something….. soon.

      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.


      Meanwhile development marches on relentlessly, to paraphrase the article, so it’s kind of clear what’s going to happen.

      I can live with all the other issues being raised but it’s the React issue that really bothers me. I don’t even understand how it’s a question. I know that a ton of work has already went in to the product and it would suck to start over, but if that’s what has to be done then that’s just what has to be done. Too bad, sucks, lesson learned, whatever. Pick another library.

      Again, how is this even a question? To me it seems like a slap in the face to have development moving forward full tilt while this major issue remains outstanding – with zero meaningful communication from project leadership, other than stalling, which Matt’s response is, quite frankly.

      I’m so grateful for WordPress, it’s completely changed my life and helped me to build a meaningful career doing something I love. This juncture, to me, it’s just sad, and extremely disappointing.


      • I understand your frustration at there not yet being a definitive answer on the React question, but it’s worth noting that the effort to move Gutenberg away from React (should that be necessary) will be greatly reduced by the existing architecture. Gutenberg blocks don’t implement React elements, they implement WordPress elements.

        Currently, the WordPress element library is a thin layer around React, but it could be transitioned to a completely different library if needed.

      • I totally agree with you @Jimmy Smutek. It shouldn’t even be an option to build something for core with React, due to the nature of its license. To me it just looks like one more step in the Automattic “takeover”. Suddenly, what was a major issue in the past is no more, and seems like everyone inside the project is OK with it.

  2. I’d rather have sandboxxed plugins, themes, comments, and pages, if you don’t mind.

    Creating new content is nice and all, but a little extra stability would be hella useful.

    • You and me, both, Nate. 🙂

      Full sandboxing would be… complicated, due to the nature of PHP. Core does some sandbox-like checks when activating or upgrading plugins, expanding those kinds of tests would go a long way to ensuring a site stays stable. There’s some discussion on this core ticket about ways to improve those checks. If you have particular problems you’ve run into, that’d be a great place to put them.

  3. Autocomplete for blocks is a new feature that partially answers this problem, but it relies on the user knowing that typing a slash / in a new default paragraph block will trigger autocomplete.

    Does it come with a Post-It ™ note to put on the edge of your computer monitor, so you can remember all these cool keyboard gymnastics?

  4. However, the programming of the plugin continues to have flaws that are beginner:
    – There is still no possibility to edit the permalink of the entry you create with Gutenberg. A default is displayed and can not be changed.
    – There is no possibility of setting the spacing or margins in the blocks, so, sometimes one block is placed on top of another (as in the example I attached). The only possibility is to insert an empty block between two blocks with content, but that is a fudge.

    – If you use the keyboard shortcut / to save time and it turns out you are wrong you have to delete the whole block and start over again (eg / heading. Once you put it, there is no possibility to go back or delete the format , just delete the whole block and insert another …)

    I still think that Gutenberg is not a good option to insert into the Core and force us to use it. As an optional plugin would be great for anyone who would be useful, but for the rest of mortals is a delay.


    • nope, still no nested blocks… apparently core isn’t including them in launch features. Personally I believe that to be a foolish move that will lead to a million fragmented implementations.

  5. The first thing the average user will ask is how to put one block next to another. If the blocks aren’t responsive in a grid like fashion, what’s the point?

      • Page Builders borify and fuglify websites that eventually break, couple and require scale. Quality designers/developers Don’t Let Peeps Page Build™. Just like a bloated theme with a billion Google fonts = unsightly bonkerisms. If “Code Is Poetry” via page building then the craft of the webpage as we know it is DOA. They’re called “Users” for a reason. If you want to make them more than that, then point them to those pre-boxed dolla store generi-sites. Ain’t no thang. It’s all hype. Stay a few steps ahead and you’ll all be fine.

      • Well Tai page builders weather you like them or not are going to stay.. We have like thousands of Visual composer based themes to use.

        Page builders are great for columns which Gutenberg has to get right or WordPress is SCREWED.

  6. @Richard Ginn LOL, yeah Visual Composer themes …therein lies the problem. But since you went all-in with VC, just stick with it if you don’t wish to refactor all your WP5.0 sites. VC will adapt. They have to.

    As for Page Building in general, they should be opt-in and/or plugin territory and ALL OF THEM should *now* cater to whatever the heck Gutey is up to–that’s a safe bet.

    I don’t mind if they stay. I want them to–so we can bounce metrics off them. There’s always a place for cheap budget pseudo-competition. I’ll never lock my clients into a tool I don’t believe in. That’s stealing from my clients. It’s lazy. Quality is a craft, blah blah blah. But the C in CMS stands for “Content” and not “Builder.”

    The Net is plagued with garbage content. Gar-bagé!!! (screaming with French accent) All this fluff is just perpetuating a demise in the Quality of Digital solutions.

    WP is fine where its at (market fit) and has a rare opportunity to dee-stroyyyyyy (epic echo) the “competition” right now. I’m just gonna kick back, light up and watch this all unfold at Ye Ol’ Tavern. Cheers!


Subscribe Via Email

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

%d bloggers like this: