Cancel

Justin Tadlock

Gutenberg 10.1 Enhances Reusable Blocks, Updates Social Icons Spacing Options, and Normalizes Image Block Toolbar

Gutenberg 10.1 landed yesterday with several new features, many of which focused on improvements to the interface and user experience. Users can now control the justification of items in the Social Icons block. The new release also enhances the UX for creating reusable blocks, groups the Image block toolbar controls, and introduces categorized template parts in the site editor.

The development team corrected two dozen bugs for this release. As usual, they continued to polish the site-editing experience, which should land in WordPress later this year.

One of the better improvements to the UX is with the dragging performance for the focal point picker. Users can test the Cover or Media & Text blocks to see it in action.

Spacing Options for Social Icons and Buttons

Adjusting the spacing between the Social Icons items in the block editor.
Adding space between items in the Social Icons block.

The Gutenberg development team added the justification toolbar control to the Social Icons block. This allows users to determine how they want their social links to display. The following are the current justification options:

  • Justify items left
  • Justify items center
  • Justify items right
  • Space between items

The Buttons block now has the space-between option, which gives it and Social Icons the same flexibility as the Navigation block.

The Social Icons block still has left, right, and center alignment options too. This is separate from the justification setting. In comparison, the Buttons and Navigation blocks only have wide and full alignments if the active theme supports them. However, the Social Icons block does not have those options. These blocks’ alignments should all have parity unless I am missing some crucial reason for the difference.

Reusable Blocks Updates

Modal overlay for naming a reusable block.
Modal for naming, saving, or canceling a reusable block.

The development team continues to refine the reusable blocks feature. Version 10.1’s highlight is a new modal that pops up when first creating a reusable block. It has a simple title field along with buttons for canceling or saving. The cancel feature is also a new addition.

This modal clears up a problem introduced in Gutenberg 9.7. That release moved the title field for the reusable block into the sidebar panel. If users did not have that panel open, they could easily overlook it.

“Based on these changes, the UI for reusable blocks is most likely going to see some iterations in the upcoming weeks,” said Gutenberg developer Riad Benguella at the time. The team has delivered on this promise.

Gutenberg also uses this new modal as part of its template creation flow in the site editor.

The editor toolbar now displays a reusable block’s name when it is selected in the content canvas. This adds clarity and helps users better see what they are editing. Users can also update the name of a reusable block from within the editor sidebar.

One issue I still have with reusable blocks is when using wide or full-aligned elements. Once a block is saved, it displays at the regular content width, making it less of a WYSIWYG experience. There is an open ticket for this bug. However, it has seen little movement as of late.

Semantic Toolbar for Images

Viewing the Image block toolbar's new grouping that separates meta, block, and inline sections.
Grouped sections in the Image block toolbar.

The Image block’s toolbar received an upgrade. Its controls are grouped, with each group separated by a border. The toolbar follows a specific order: meta, block-level, inline-level, and more options. The goal is for controls on every block to use this order, which translates to a standard UI that users can follow.

This improvement for the Image block brings enough clarity that I already want this across the board. There is an open ticket to normalize the toolbar for all blocks.

Categorized Template Parts

General template parts category in the site editor.
“General” template parts category.

For the experimental site editor, a new patch to group template parts landed in the latest release. The UI change separates parts into four categories: headers, footers, sidebars, and general.

I could not get this feature to work. There are no clear instructions for theme authors to follow. Header templates named header-one.html went to the general category. Template parts in sub-folders, such as header/one.html, also failed. Even just plain header.html did not get grouped.

While there is obviously a bug, I am excited about the prospect of categorized template parts. It is a preemptive step toward decluttering the interface.

The problem with the current approach is that it is unnecessarily limiting. It assumes that headers, footers, and sidebars are the only specific categories of template parts needed. By defining them in core, we lose all flexibility. In past themes, I have built more content-related template parts than I have for those three groups. Under this system, all of these would be tossed into a “general” category with every other template.

This is not an argument for WordPress to have a category to meet my needs. Instead, put this into the hands of theme authors to make the best decision for their theme. Create a way for end-users to categorize their custom template parts as a next step.

Sure, create some defaults like headers, footers, and sidebars. That makes sense. Just hand over some of the control.

Category: , ,
Tags:
10

10 responses to “Gutenberg 10.1 Enhances Reusable Blocks, Updates Social Icons Spacing Options, and Normalizes Image Block Toolbar”

  1. Having the ability to edit a Reusable Block in a post is interesting, BUT with over 40 contributors and over 600 core contributors how is it possible that NOBODY has figured out that if anyone who is not an Administrator or Editor, when editing a post that contains Reusable Blocks and clicks on a Reusable Block, they will crash the entire post with just that one click?

    My answer to this would be for those who are not allowed to edit a Reusable Block (only Admins and Editors can edit them), the RU Blocks to be locked in posts and pages and not editable, just like they were a few versions before.

    Also, are the accordions in the Block Inserter ever coming back, or we the peasants do not deserve to have nice things anymore?

    Create forum topic from comment

    • I find that this tends to be the issue with the block editor. Many things about the editor are well implemented. While for some basic content insertion, inline, the editor is usable enough, but it tends to get more cumbersome as you try to become more daring. When you start to look at FSE it really is an not an elegant experience. It all feels like a geeky project where you need to be in the know.

      Considering many page builders seem to have cracked many of the issues that the Gutenberg doesn’t want to address, I would say we are falling between two stools here.

      I found the following on LinkedIn last evening, and I quote:

      “I have been looking into this for quite a while! Since late November the most recent change in Google left many WordPress sites with a bad score on page speed insights, with little to nothing to do since the new quality standards address certain programming practices that WordPress as a platform has to its core files architecture. Testing around there are quite some plugins (paid ones) that address this issue and the Guttenberg block editor functions better than other platforms like Divi or Elementor. E-commerce sites like shopify have no issue with the new standards on UX and speed Google has launched. So for now and until Google finish this change to a full positioning factor we are stranded at sea with WordPress. The question is if WP is going to address this on the free side of its platform or capitalize with plugins, making SEO a pay per positioning?
      What do you think?”

      Sebastian Pinto makes some good points there. I disagree a little with what he says on picking out Divi and marking it down compared to the block editor. He is correct about paid for plugins. In this instance, yes, WP Rocket at $49 is probably good investment, if you are using Divi. I tested it recently and was impressed how it addressed very easily the core web vitals that Google expects now.

      I have also being testing the Kadence block based theme, which is very good by the way, and, while on initial testing it scored well, when I realised that the imported theme was very light on images, as soon as I started to add some to match what was on my own Divi site, that score started to slide very quickly. Again I suspect that WP Rocket would address this.

      In any event, it isn’t as if Elegant Themes are unaware of the issues it must address and, to this end they are going to work on some of the underling issues in the foundation of the theme, even going so far, I hear, as to remove the shortcode base, if that is possible at all. Maybe the underbelly will be block based? 🤔

      Getting back to Sebastians contribution on LinkedIn, I would be focusing on getting the core block editor working well before tacking FSE. The powers to be at WordPress set up the scenario of either block editor or page builder camps, which is not helpful at all. This has been the problem with WP for the last while where conflicting approaches by plug-in vendors to dealing with, or not dealing with the block editor, has been a pain for end users.

      On your comment Nick, in terms of usability, page builders are way ahead, and despite performance issues, this is where Divi excels, like clearly defined settings groups that get presented selectively with the accordion convention you mention. With the block editor, while many of the core features are usable, there are many parts of the UI which are like looking into a field of thistles.

      Create forum topic from comment

  2. For the grouped template parts, if the theme does not define an area (in theme.json) for a template part, it will be grouped in General (uncategorized).

    For example TT1 Blocks theme defines the template part areas like this:

    "templateParts": {
    "header": {
        "area": "header"
    },
    "footer": {
        "area": "footer"
    }
}

    This seems to be missing from the theme developer documentation.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

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