Gutenberg 8.3 Updates Block Categories, Includes Parent Block Selector, and Adds New Design Controls

Yesterday, the Gutenberg team released version 8.3 of the ongoing plugin behind the block editor. While much of the focus for the team is on the upcoming full-site editing, this update includes several user-facing features, such as a reorganized set of block categories, a parent block selector, a spacing control, and link color options.

One smaller enhancement includes the ability to filter the Latest Posts block by author. The level control for the Heading block has also changed. Instead of selecting the level in the block options sidebar, the level selector is now located in the editor toolbar.

In Gutenberg 8.2, hitting the Enter key within the caption field for an image block created a new paragraph. In 8.3, that feature has been extended to all blocks with captions.

The team corrected over 20 bug fixes in the latest release. On the whole, the new plugin update appears to be solid after a day of use. However, some of the experimental additions, such as the new padding control, may be worth some concern. Theme authors need to start testing this, providing feedback, and making sure development is heading in the right direction.

New Block Categories

Screenshot of the Gutenberg block inserter.
New “Design” category in the block inserter.

The Gutenberg team has renamed and reorganized the block categories. The new list seems to make more sense and is better consolidated into proper groups:

  • Text
  • Media
  • Design
  • Widgets
  • Embeds

While I am a fan of the new category names, I find the categories useless for any practical purpose at this point. Ever since Gutenberg dropped the tabbed interface in the block inserter, it has felt like a large wall of blocks. My eyes naturally skip by the category names as I scroll and scroll and scroll through the list of available blocks to find that particular block I need. I almost always use keyboard slash commands for inserting blocks. In those cases where I don’t, it is not an ideal user experience, and the new categories do not help much.

Select Parent Block

Hovering over the editor toolbar to find the parent block selector.
Hovering over toolbar to find parent block selector.

One of the more frustrating experiences in Gutenberg is attempting to select a parent block in a nested-block scenario. Far too often, users feel like they are clicking around at random in the hopes they hit that sweet spot where they can actually navigate to the block they need to edit. It is an exercise in frustration in the best moments.

The Gutenberg team took a step — a small step — toward alleviating this pain. When hovering over the “change block type or style” button in the editor toolbar, a new button appears to select the parent block.

I am unsure if this is the right way of handling the problem. I would like to see some experiments with some sort of arrow button that appears without hovering. For now, I am satisfied that the team is attempting to solve the issue and hope that future iterations improve navigation within nested blocks.

This feature does not seem to work when the top toolbar mode is enabled. For those who use this mode, the best way to select a parent block is via the breadcrumb navigation at the bottom of the editor.

Experimental Spacing/Padding Control

Using the new padding control for the Cover block.
Adding custom padding to a Cover block.

Theme authors can now add support for an experimental padding control via add_theme_support( 'experimental-custom-spacing' ). When supported, the end-user will see a new Spacing tab under the block options sidebar for the Cover block, which should be available for other blocks in the future. By default, users can control the padding for all four sides of a block with a single value. They can also “unlink” the padding and control the top, bottom, left, and right values individually.

Presumably, the Gutenberg team will extend this spacing feature to include a margin control too. It would be the natural move and one in which I hope that leads to the death of the Spacer block that users have had to live with for the past couple of years.

However, I am not sold on allowing end-users to control padding with explicit values. Haphazardly changing padding values will break the vertical rhythm that many theme authors take the time to meticulously calculate. When using pixel values (the default), users will most certainly run into issues with tablet and mobile screen sizes. Essentially, it will create a complete mess of spacing.

I am not against the idea. I want it done right before this lands in WordPress. Theme authors should be able to register named classes that are handled via the stylesheet. This goes back to the idea of WordPress having a design framework. Create a set of utility classes for spacing (oh, hello, Tailwind). Let theme authors define the spacing based on their design. Let users choose from those. Then, provide a custom option for those times where users want to take matters into their own hands. At that point, they have made an explicit decision to break away from the design flow the theme author has chosen.

Link Colors

Selecting a link color in the block editor.
Selecting a custom link color.

One of the tougher hurdles theme authors have had to face when styling for the block editor is figuring out what to do with link colors when the user changes the background color of a block. Users have long had control of the text color in that scenario. However, link colors could quickly become inaccessible or just downright ugly. Forward-thinking theme authors would style those link colors so that they inherited the text color, but that is not always the ideal solution.

That’s where user-controlled link colors come in. To add support for custom link colors, theme authors must opt into the feature via add_theme_support( 'experimental-link-color' ). This will add a new color selector for the Paragraph, Heading, Group, Columns, and Media & Text blocks.

Unable to get this feature working with the theme-support function call, I had to dig into the code a bit to find the issue. For theme authors to add support for link colors, they should also define their default links as shown in the following CSS code snippet:

a {
	color: var( --wp--style--color--link, #000 );
}

WordPress will automatically set the --wp--style--color--link variable. For further specificity, theme authors can also target .has-link-color a.

21

21 responses to “Gutenberg 8.3 Updates Block Categories, Includes Parent Block Selector, and Adds New Design Controls”

  1. I would love to see spacing and margins handheld like the font sizing options, with he ability to define preset spacing options that can be selected via a dropdown and then an option to have enabled or disabled custom spacing.

  2. I see some fixes in the production versions, how can I download/compile a production version build?

    I think the team should think about pushing some nightly testing plugin like for WordPress in order for people to be able to install nightly builds.

    Kind Regards

    • To my knowledge, the ‘production’ (which is the equivalent of the ‘master’ branch at https://github.com/WordPress/gutenberg) isn’t automatically built and shared as .zip file to public.
      However, you can build it yourself but if you are not familiar with npm, git, and the command line; it’ll take you several hours to learn enough basic terminology of git, npm and the command line to do so.

      I wrote how I do it and does expect that you have npm and git installed and that you are using linux or mac os x)

      I run ubuntu, so I created an alias, which, for your bash/command line,
      is a shortcut that when you type the alias in to your command line and press enter, a series of commands or instructions are run altogether, so I don’t have to remember all of these further steps, I can just type in ‘gbupdate’ and about 3-10 minutes later, you have the newest version of gutenberg ready to go.

      Here’s what my alias looks like:

      alias gbupdate=’cd $zach && git checkout master && git fetch upstream && git checkout master && git merge upstream/master && npm install && npm run build’

      before going further:
      If you only have one site (or environment) where you edit your theme, try out with new plugins, etc, I would be careful running this. There’s times where the newest version will unintentionally break an existing block(s) or will have changes in the interface without any documentation why (unless you really dig into the code)

      If you’re ok with this, you’ll have two options:
      A] Cloning the copy of gutenberg and keeping it in sync

      B] Forking your own copy of gutenberg and keeping it in sync

      (There are differences between cloning and forking, that is beyond this article at the moment; I have forked my own copy and proceeded that way; your alias will be different if you only clone)

      With that in mind, here’s my alias:
      alias gbupdate=’cd ~/vvv/www/zach/public_html/wp-content/plugins/gutenberg && git checkout master && git fetch upstream && git checkout master && git merge upstream/master && npm install && npm run build’

      Your command will not be exactly the same as mine but you can base it off of mine…

      cd ~/vvv/www/zach/public_html/wp-content/plugins/gutenberg
      – this is a shortcut to the folder where I originally cloned and downloaded my fork of gutenberg from github. (Zach is just the nickname that I gave to the site)

      git checkout master
      – this tells git to go to the master branch which is the leading branch

      git fetch upstream
      – tells git to get code changes from the upstream (which is the main Gutenberg project https://github.com/WordPress/gutenberg) (if you haven’t already, here are directions to add your upstream from github https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/configuring-a-remote-for-a-fork)

      git checkout master
      – you may not need to run this again, but I do to be on the safe side.

      git merge upstream/master
      – merges those downloaded changes in your folder

      npm install
      – this re-installs, updates any dependencies, of which there’s a lot, for gutenberg.

      npm run build
      – this builds the gutenberg code, so after this command is run, you can now use the newest version of gutenberg on your computer.

      more on the differences between npm install and npm run buil https://stackoverflow.com/posts/53311374/revisions

      To be honest, I wasn’t quite sure of the differences until I wrote this up.

      Separately, if you want the zip file that you can share it with friends, etc:
      npm run package-plugin
      This will delete some of the installation things (I’m not exactly sure what; but I know after I run this program, I have to rerun all of the other commands to get back developing again)

      Now…. Requiring all of this knowledge – git, npm, and the command line can seem like it’s a lot but it’s very useful knowledge to have, not just with troubleshooting gutenberg, but for building and using other software projects and libraries that use node and its package manager, npm.

      And yes, for those who wanted to test out the newest version of Gutenerg, requiring to know all of this is sort of a barrier for people ;
      that’s partially the development team decided if you want to test and share feedback, to use the plugin which releases updates, it seems every few weeks https://wordpress.org/plugins/gutenberg/

      It’s sort of a tradeoff to decide at what point you want to be involved with steering the direction of Gutenberg.

  3. I often work with design apps. Today I like Affinity Designer for creating one page lay outs. There we have the same with nested frames or even objects that stay below one other. Selecting them isn’t easy. But in Affinity Designer they use levels which show up in a sidebar. Even if I use groups of elements, selecting a element there is the way I like.

  4. There may be a problem with to 8.3 update. After the update, when trying to create a new post, I get a white screen. I changed to the default theme, disabling all plugins (except Gutenberg.) The show seems to stop when I reactivate Yoast Version 14.3. I swapped SEO Framework for Yoast and all is good.

  5. Gutenberg has been a complete failure. It is now required to have a good page builder on any WordPress site because there is no way I would ever use Gutenberg.
    I was very much for Gutenberg when it was first introduced. But I simply can not use a page editor that I have to relearn every couple of weeks because they change the block layout, or functionality. It has really become a joke.

    • The main problem with any page builders like Elementor, WPBackery and so on – they are 3rd party plugins and require updates even if they are bundled within any premium theme, so you have to rely on theme devs when they update plugins and so on. In 2020, everything should work right out of the box, so it’s kinda strange and unsafe to rely on various third-parties. Also, what I learned from several years of using visual composers – these plugins are bloated with options, they are hard to master, heavyweight and if you decide to move from one page builder to another – your site is dead.

      In my opinion – Gutenberg is cool and modern builder, stripped off from complexity and unnecessary features though it’s really hard to build “professional” sites with it.

    • I wouldn’t recommend the plugin if you feel like things are changing too fast. Using Gutenberg is essentially like living on the bleeding edge, so things are expected to change rapidly. Sticking with WordPress-only will allow things to simmer down a little since it gets a major update every four months or so.

  6. Has anyone checked the filter by author in the Latest Post block in a site with a great amount of users?

    We have had consistent problems with the post author selector in some of our sites, which hold some thousands of users including clients who interact in our support forums. Creating a page and checking in the console how the editor tries to load all users in batches, until the page is frozen, as reported in GitHub in several tickets for the last 2-3 years. There is a proposal for an autocomplete component, but not completed yet. We had to manually disable the specific REST API endpoint to be able to do some basic work.

    I assume that the Latest Post block, and its author selector, will suffer from the same problem, so sites already using this block that also happen to hold a great amount of users might find out a surprise when editing a page containing the block.

    Just my 2c on the new features. Probably it might be a good idea to consider performance on expensive components before spreading them into the wild. 2 years for some basic functionality like being able to set the author of a post without needing to load all your site users sounds like probably too long for a bug to live.

    • I thought that might be an issue when I saw how they were loaded. I didn’t test it on a site with a large author number for this reason. I’m assuming this is more of a “version 1.0” of the author dropdown. Otherwise, it’s going to be problematic when it drops in core.

  7. I want to get manual builds depending on the milestone, is that possible?

    I currently run the following commands:

    git clone https://github.com/WordPress/gutenberg.git
    cd gutenberg
    npm run build:plugin-zip

    The problem with that is that I believe I got a build that includes things from milestones like “Future”, while I would only want to have a build based on the next milestone.

    Any idea how to achieve that?

Newsletter

Subscribe Via Email

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