Gutenberg 0.8.0 Introduces 5 New Blocks: Categories, Text Columns, Shortcode, Audio, and Video

Gutenberg 0.8.0 was released over the weekend with five new blocks, major improvements to existing blocks, and support for more publishing features that have been missing from the new editor’s sidebar. The release also carries out the controversial decision to remove the opt-in usage tracking code from the plugin.

The new Categories block can be found under the Widgets section, as it’s output is based on the existing categories widget. The default display is an alphabetized list of categories, but the block settings include options to display as a dropdown, show post counts, and show hierarchy.

A new Text Columns block allows users to split text content into multiple columns. The settings include a sliding scale for selecting 2-4 columns.

Contributors are calling the Text Block “an initial exploration” of multiple columns for text-only content. Depending on testing, it may not be the implementation that ends up landing in the plugin permanently.

“We’ve been over how difficult it is to get columns right, and also how already today third parties can build this,” Joen Asmussen said. “We may very well want an entirely different implementation than this one. But perhaps it’s good to get this in now and test it. Perhaps this can help inform how a better column implementation can work down the road. In fact we might want to merge this block in now, only to take it back out later again, same as the Cover Text block. For that reason, I think it’d be good to test this.”

The new Video and Audio blocks are geared towards inserting files that have already been uploaded to the media library. However, I found the text on the video block to be confusing. If I was new to WordPress and didn’t understand how oEmbed works, I would be clicking inside the video block to figure out where to paste the URL.

The new Audio and Video blocks mirror the same kind of functionality that users have experienced when adding images to their sites. In the future, contributors may introduce more features to the audio block, such as additional playback types and looping, but the first iteration includes just the basics.

Gutenberg 0.8.0 adds resizing handlers to the existing Image Block, making it easy for users to insert and quickly resize an image. If you review the GitHub ticket for this feature, it’s clear that it was not easy to implement. Image resizing has gone through several changes and may have more down the road, especially as it pertains to the behavior of the caption. Ultimately, the caption field should not be wider than the image so that the two are placed together.

This release introduces a post formats selector to the post settings sidebar. It includes a suggestion based on what blocks are in use in the post. One participant on the ticket noted that the suggestion gives too much importance to the post formats selection and might be confusing to users. The suggestion persists, despite a user switching the format to the one suggested. This is because Gutenberg cannot detect if it was explicitly set by the user or if the user selected the suggestion.

“I happen to agree with you: post formats should go away,” Joen Asmussen said. “In fact part of the genesis of blocks as a concept is to provide a better interface than what post formats did. So the post format selector here is strictly a back-compat thing.”

Gutenberg contributors have also updated the design document for the project, offering more clarity on their goals and concepts they are using to build the editor:

Ultimately, the vision for Gutenberg is to make it much easier to author rich content. Through ensuring good defaults, wrapping and bundling advanced layout options blocks, and making the most important actions immediately available, authoring content with WordPress should be accessible to anyone.

The idea is to simplify content creation for users so that they only have to learn one interface – the block interface. The design document adds several new sections that elaborate on the concept of “everything is a block” and includes best practices that developers can reference when designing their own blocks.

18 Comments


  1. The columns feature took me by suprise but is a great addition. Im happy with the way Gutenberg is shaping up

    Report


    1. Indeed nice, those Columns features. And hopefully this could be the ‘standard’ way for pagebuilders. But the column feature is not yet responsive, guess they are aware of it.

      Report


  2. As long as the Pods Framework will work with Gutenberg I will be happy.

    Report


  3. “Post formats should go away” – how they will be replaced?

    Post format has formattings for many elements, like heading, text, background, etc.

    If there is no post format, then a user would have to construct all these settings/styles manually each time, or there are other ways?

    Report


    1. Do post formats still exist?

      Report


    2. Post formats are ‘just’ a custom taxonomy, so the only change would be how they’re declared in your function.php (or wherever) file. That would also mean you could defined your own formats (such as ‘tweet’) that you can’t do with the baked-in version.

      Report


    3. Post formats are ‘just’ a custom taxonomy, so the only change would be how they’re declared in your function.php (or wherever) file. That would also mean you could define your own formats (such as ‘tweet’) that you can’t do with the baked-in version. All the alls in archive.php, single.php etc would stay the same. Some sort of conversion process / code would be helpful though.

      Report


    4. Just to clarify that statement, post formats aren’t going away. If they ever will, it’ll be down the road, done as a separate task by a separate team, probably like the link menu.

      Post formats are key to the genesis of blocks as a concept. Back in the 3.6 days, post formats as a 1st class citizen were being worked on for core, with a much bigger interface, the idea being that sometimes you want an “image post” to show in a different way than just a post with an image, and sometimes you wanted to show a “link post” where the link received a visual treatment akin to an opengraph card. This idea was sound enough, but the UI was pulled out because it was ultimately confusing.

      They key take-away was that maybe you just want to write, and not have to worry about picking a format that’s abstractly represented in the admin. More than that, maybe you want to write a standard post, but want the image to display the same way as if it was an image post. Maybe you want an “opengraph-style” link card inside that post.

      Blocks can address that by basically making blocks for every post format. Want the image to look big and wide? There’s a button for that. Want a big and bold quote in the middle of your post? Use the pullquote.

      The idea being: the chief benefit that post formats brought — showing types of content in a different way — you can keep that, with a better preview, use those displays in standard posts, and not have to worry about picking a format.

      Report


      1. Wow! With that description, the Post Formats we never got seems like it was a way better idea than Gutenberg! We could have designed interfaces to match formats and given users a logical view for editing various designed templates.

        This would be a great way to manage the separation between graphic designers / layout designers and copywriters, rather than giving content editors the keys to go all Comic Sans / Word Art on carefully designed templates

        Report


  4. As a general rule I think anything that makes it easy for non developer to “design” a webpage pisses me off. But I guess we will see what happens.

    Report


    1. Why? Its an expectation nowadays – and anyways most people stuff it up, then we can fix it for them? At least now they CAN do it themselves. Its that freedom that’s attractive.

      Report


  5. I will find it interesting to see the reception of Gutenberg to the outside world for clients who will only find out about this upon the release of 4.9.

    I’d really like to see how the Gutenberg grows in this respect.

    I’m sure it’s still in the early stages even if it will have to be released first, but the initial idea looks like it will already be useful to some people.

    And from that point onwards we can make it more useful!

    Also like the idea of the column blocks! Simplifying this for clients would make things so much easier!

    Kind regards,

    Mic

    Report


  6. The text columns block is totally useless. Instead of using CSS columns so that the browser can take care for balancing the text in the columns, the block uses hard containers and flexbox. This way the user has to manually select which part of the text should go in which column. Also, the columns are not responsive (which is pretty trivial to achieve with flexbox without media queries) and you get a squished tiny little columns on small screen.

    I know CSS columns are not universally supported, but faking text columns in any other way is plain wrong. Hmm, actually, they are pretty well supported: http://caniuse.com/#feat=multicolumn

    Report


    1. @milen I’m a bit torn on this. I love the concept of CSS columns. The idea of just writing your text freely without worrying about how it will be displayed is attractive. But a developer I’ve rarely found CSS columns to be practical. It never seems to break your content up quite the way you expect it to.

      Lists broken in the middle of an item. Images moved to the next column at certain breakpoints despite being associated with the text in the first column. There are are many more cases. I have almost always found my clients prefer the increased control that discrete containers offer.

      I would agree that the editor should make the columns responsive by default. But as a developer I’d prefer they leave making them responsive on the frontend up to me in the theme.

      Report


      1. @steve, I know what you’re talking about. Browser support for the fine-tuning properties like break-before, break-inside, and break-after is still poor, and that’s the main cause of frustration when using CSS columns.

        And I agree with you that the theme should control how the various boxes appear in the front-end. And for some things it has – the theme can provide the CSS, needed for the multi-column boxes, I experimented with image alignment and I liked the results so much as to extend the options in the current editor for my latest project.

        Report


  7. ODD you did not talk about the shortcode block in the article, but did mention it in the post title.

    This version of Gutenberg is a step in the right direction, but I am still in wait and see mode on this idea.

    Report


  8. I have just started to look into this Gutenberg project so I am not in a position to make specific comment except “It would appear that the Gutenberg team are striving to bring about a major change to the current WP editor; I congratulate them on their achievements to date and look forward to them reaching their goal”.

    There has always been one thing about the WP editor that intrigues me. I use this quote from the article to illustrate – Quick Toolbar: Has inline formatting options, bold, italic, strikethrough and link My question, why has the toolbar not got ‘underline’ included?

    Report

Comments are closed.