Gutenberg 7.6 Includes Rotating Tips List and New Full-Site Editing Blocks

Yesterday, the Gutenberg team released version 7.6 of the plugin. Most of the work in this update went toward the upcoming full-site editing feature. The team continues to pump out new dynamic, placeholder blocks for post data. The biggest user-facing feature was the addition of a rotating list of tips in the block inserter.

Version 7.5, released two weeks ago, was the last major release of the plugin that will have features to land in WordPress 5.4, which is currently scheduled for release on March 31. However, bug fixes from 7.6 were ported to the most recent WordPress 5.4 beta updates.

Version 7.6 does not include as many major feature additions as earlier releases. Aside from experimental work on full-site editing, it primarily includes bug fixes.

The announcement post boasts a considerable speed improvement in loading time and keypress events. In comparison to version 7.5, loading time was reduced to 7.7 seconds from 8.5 seconds and keypress event speed was reduced to 48.59 milliseconds from 55.45 milliseconds. These tests are run against a post of approximately 36,000 words and 1,000 blocks.

Rotating Tips In Block Inserter

Screenshot of the block inserter, which shows the tip section that rotates messages.
Block inserter tip section now rotates messages.

In the past, the block inserter had a single tip at the bottom right that read, “While writing, you can press / to quickly insert new blocks.” It was a useful tip, but it was easy to ignore because it never changed. After seeing the same message a couple dozen times, it had become little better than wasted space.

Version 7.6 creates a rotating list of tips. Each time a user opens the inserter, a new tip appears. At the moment, the list only contains five messages but more are sure to come in the future.

There are open tickets to add contextual tips based on block search queries and block-specific tips. Both of those tickets could continue to help users learn the block system and provide a path for block creators to teach users how to use custom blocks.

Currently, the list of tips is static. However, it may be possible for plugin authors to extend it in the future. I’m already contemplating writing a plugin to replace the tips with quotes from Joss Whedon’s Firefly.

Full Steam Ahead with Full-Site Editing

Screenshot of the block inserter, showcasing the post-related blocks for full-site editing.
Growing list of post data blocks for full-site editing.

Gutenberg 7.6 added four new dynamic, placeholder blocks related to post data: featured image, tags, comments count, and comments form. This brings the total to around 12 blocks for full-site editing, which is still a few dozen short of where the platform will need to be before the feature is ready. Most work thus far has gone toward building out blocks that handle post data. Eventually, the team will need to expand to other areas that will need block representation on the front end.

Theme authors looking to test out full-site editing should make sure to check out the block-based theme experiments repository, which continues to see regular updates.

Users can now set the heading level of the site title block. It can also be set to a paragraph. However, it does not include all of the design settings, such as text size or colors, that would come with a regular paragraph block. This is a good first step in recognizing the various ways the site title block will be used, but it will need to evolve into a much more robust block to allow users to do all the things they will eventually want to do with the site title.

At this point, it is hard to gauge what full-site editing will look like. Everything is experimental. It only covers the most basic use cases. I am still cautious about its potential. On the other hand, I am ready to skip ahead a year and see how it all turns out. Every plugin update brings us a step closer, but it is tough waiting to see what the bigger picture looks like as it comes together.

17 responses to “Gutenberg 7.6 Includes Rotating Tips List and New Full-Site Editing Blocks”

  1. Is it my imagination that the plugin version of GB is merely a testing ground for what will be in the core?

    As a theme developer, it almost seems like we have to design 3 flavours of a WordPress theme:

    WordPress with the classic editor
    WordPress with the core GB
    WordPress with the core GB + the plugin version

    It also appears that full site editing is coming much faster than many have anticipated.

    • Yes, Gutenberg is the testing for what will land in core.

      My approach for theme development would be to code against the latest version of the plugin. Then, do final compat checks against core and the classic editor if you want to support it.

      With full-site editing, you’re safe for a while. From the roadmap I’ve seen, they’re shooting for a basic working version by the end of 2020 within the plugin. I imagine it’ll be sometime in 2021 before it is feature-complete enough to be in core.

      • A good suggestion to design against the plugin.

        However, as a theme dev, I am trying to gauge a lifespan of themes as they are today; how long they will stay relevant as WordPress continues down the path they are going. I’m still thinking about theme shops and marketplaces, in general, as to how long they/we have before themes of today are no longer compatible with WP. More so with end-users who are not really prevalent in the future of WordPress and to know that their theme may not be compatible in the near future.

        2021 is really not that far away, less than a year.

        • Definitely. It’s just too early to gauge what theme dev will look like in 2021, but it’s going to make things a bit crazy. I’m thinking that we’ll definitely see a big split between “old” (for lack of a better phrase) and block-based themes. Popular theme companies will likely have to code their themes for both possibilities. Right now, I’m just thinking that will be a lot of duplicated code.

          • Eventually, “old” themes will become obsolete and incompatible. The big question mark is find out when.

            I’ve been exploring the possibility of coding themes for both old and new (block-based) themes. I already code my themes for the classic and the block editor. So, perhaps that means my original flavour list will now look something like this:

            WordPress with the classic editor
            WordPress with the core GB
            WordPress with the core GB + the plugin version
            WordPress with the core GB + Classic editor + Plugin + Block areas

  2. Is it me or now when hovering over blocks there’s no tooltip or indication of the specific block you are hovering over?

    • Hmmm…I actually didn’t notice that until you mentioned it. I am unsure if this was changed in 7.6 or an earlier version. I do have to admit that I think I like it better without the tooltip. It feels a little less noisy in comparison.

  3. The improvement is good, really good. But there’s something that’s hard to understand. All these features is to improve the user experience with Gutenberg. But why don’t they think about developers. If for some reasons a block can’t render itself, an error is shown in browser console and the whole block is lost. You can’t recover it. That’s not the best option to catch an exception. Everybody talk about this way of showing issues, but nobody seems to care about it.

    More than it, the DOM structure in Gutenberg is different from what is rendered on frontend. That’s a problem because as a developer you have to maintain two structures that look the same, and the pixel perfect between the two is hard to.

  4. Try: Create new Post and save it. Type some letters. The “Save” Indicator never turns back to “Saved”, even though the Changes are stored in the Background. Is this a bug or a intended behaviour?

  5. Are there conversations anywhere about best practices for block development in themes?

    But with more and more blocks – and more options for each, wont this impact speed? Isnt it the same bloat we used to criticize in page builders?

    So far, other than custom blocks, and changing default styles, we’ve been removing a lot of options for clients – for easier editing and consistent branding. I’m not sure this is a good idea tho.

    • Yes, there is a block-based themes meeting held by the theme review team every other Wednesday at 16:00 UTC. There should be one this week. The info is available in the sidebar on the Make Themes blog. That would be one of the best places to get a feel for and catch up with what is happening.

      Also, be sure to keep up with the block-based themes experiments repo on GitHub. That is where various developers are experimenting on future theme ideas and how they will work within the block system.

  6. I wonder how the full-site editing experience will compare to other builders such as Elementor, or other page builders.

    • Wait and see. From various comments and questions in issues at github here and there it appears that quite some Gutenberg devs never have seen WPBakery Visual Composer or also Elementor in real world usage or even sites with a bit more complex ACF Pro with repeaters and flexible content fields etc. or themes with own templating systems and builders like directory sites with a few thousand users and hundreds of categories, tags, custom taxonomies, which simply overload Gutenberg completely at this point. Will be interesting to see if/when Gutenberg will finally be ready for professional use.

    • Tina, while this is totally off-topic, I just wanted to say that I love your website name, Her Life Sparkles. Really cool branding. Everything stands out and draws you in to read more.

  7. I think Gutenberg needs to try to stay lean. Hopefully these enhancements don’t increase page weight if you choose not to use the block.

Newsletter

Subscribe Via Email

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

%d bloggers like this: