Gutenberg 0.2.0 Released, Adds New Custom HTML and Cover Image Blocks

The Gutenberg plugin is moving fast with version 0.2.0 now available. This is the first release since the plugin was added to the directory last week. It includes two new block types, along with other new features, improvements, and fixes for many bugs that previously severely impaired the editor’s usability.

A new Custom HTML block allows users to add HTML and click to see a fast preview within the editor.

The new Cover Image block lets users place an image in the content with the background image fixed by default. Users can also specify text to have overlaid. Gutenberg developers emphasized that this feature should not be confused with the “Featured Image” panel which is already working in a similar way to how it has in the past.

While testing the Cover Image block with Twenty Seventeen and Twenty Fifteen, I was unable to get it working correctly on the frontend. Within the editor it works beautifully but once I launched the preview I found that, regardless of which positioning option I chose, I could not get the full image to display. The size of the image’s output was only as tall as the overlay text. If there was a right way to position it, I was unable to discover it. I checked with the development team and Matías Ventura said they are not loading styles for blocks in the front-end yet. Blocks like Cover Image that need CSS to display properly will not look right at the moment, but the plan is to focus on adding CSS for these this coming week.

A few of the notable fixes and improvements include the following:

  • Added button to delete a block
  • Added button to open block settings in the inspector
  • Rename “Freeform” block to “Classic Text”
  • Added support for pages and custom post types
  • Added ability to select all blocks with ctrl/command+A
  • Automatically generate wrapper class for styling blocks
  • Avoid triggering multi-select on right click
  • Avoid being keyboard trapped on editor content

As of today, Gutenberg has more than 500 active installs. The development team is planning on shipping weekly releases to the WordPress.org plugin. If you want to keep up with the releases, subscribe to the make.wordpress.org/core blog. Feedback is welcome on Gutenberg’s GitHub repository as well as in the #core-editor channel on WordPress Slack.

20 Comments


  1. right hand do not know what left hand does :(

    @weston removes pure html widgets from core, probably to never return (no, the planned html code, or whatever it will be called in the end, do not let you add all html tags) and @afrecia justifies it by saying that wordpress should make user publish good semantic html instead of an html soup, and now gutenberg puts raw html right into the editor in a prime location….

    very sad lolz.

    Report


    1. And whether it is a good idea or not in general, the preview is most likely a bad idea from security POV. Running just any random html code which might be written by anyone, you better have an extremely good sanitation. this should be a plugin to gutenberg and for sure not released in version 1.0 of it.

      Report


    2. @mark The Text tab of the TinyMCE Text widget allows the same HTML as you can put in post content. The new Custom HTML widget coming in 4.8.1 will allow all of the HTML that was previously allowed in the Text widget as well. In all cases, however, the ability to put absolutely any HTML has always been restricted based on whether or not the user has the unfiltered_html capability. Admin users on multisite installs (who are not superadmins) for example cannot put script tags in post content or text widgets. Nothing is changing here.

      Report


      1. OK I stand corrected. Still do not explain the one hand pushing into semantic only publishing and the other pushing into adding the ability to create an html soup.

        Report


      2. @mark These are simply different priorities from different contributors. I don’t think they necessarily contradict. I absolutely agree with @afercia that WordPress should try as much as possible to produce semantic markup out of the box, and this is exactly what Gutenberg does. Nevertheless, there are use cases for when straight HTML needs to be entered, such as when pasting embed codes from 3rd parties (e.g. MailChimp). The introduction of the Custom HTML widget and block are not attempts by contributors to push for users to create HTML soup, but rather it’s an effort to empower users who need that ability (as they always have).

        Report


  2. Gutenberg for many reasons, is and will be a disaster. This is the cruelest thing they are doing to us to date! Simply said, there is absolutely no need for this useless Gutenberg. At the very least they should give us a simple way (filter) or a setting to turn this disaster off and go on in the business of building websites, with our shortcode buttons and Meta boxes. Gutenberg is not just a new editor, it is a whole new way to configure the edit screens, getting rid of meta boxes, theme options, etc…

    For me, Automattic is quickly turning like Microsoft – forcing things on their customers with things they don’t want and truly hate. Distraction free useless writing anyone?

    Report


    1. While shortcodes are fine for more expert users, they are hopeless for non technical users who can end up mangling them or unable to use them because they don’t understand the attributes.

      Using Gutenberg I think you could write your own “block” that does whatever the shortcode was doing – and arrive at a more elegant solution most of the time.

      Meta boxes are the issue and I’m sure it’s one they are going to address in time. This is a very early look, but we do need a way to add very visible fixed content areas so things like ACF, Yoast, etc. can be “in the face” of users and not tucked down the side in an expandable box.

      It would also be nice if you could pre-configure a bunch of blocks and make them mandatory – maybe including them in a page template or something. There are numerous use cases where you want your author to have a choice of a few fixed formats (the layout and content areas for a homepage could be different to the about us page, etc).

      Report


      1. Hi Miles,

        I would totally agree with you if this was 6-7 years ago. Now when somebody writes a shortcode also makes a custom MCE button to generate the code, some with the default parameters, or the more sophisticated ones, would open a dialog box, have you fill the parameters, visually choose color, image, etc… My problem are not the shortcodes, those are working for now, it’s the lack of the custom MCE buttons. Also, do the blocks support php, or html only? Some shortcodes need php as they check for logged in/out users for example. Besides, adding 30-40 custom blocks (from the shortcode conversions) to the existing ones, do you thing the end users are not going to be totally confused and overwhelmed?

        I hope you are correct about the Meta Boxes that they will address them. But until these 2 things are done, Gutenberg will be a total disaster, and will always stay useless, thanks to the dozens of page builders, if somebody wants something more than a simple editor, or shortcodes. We spent hundreds of hours if not thousands, in following their coding standards and developed those things through the years, and just like that, we are being told, to scrap everything and start from fresh and now code block, without weighing the real advantages vs disadvantages of this monster. Let’s not forget, these are the people who gave us distraction free writing, something that the vast majority do not care or use, and yet, here we are in the verge of pushing things on us that we don’t want, with the potential of breaking thousands of themes and plugins. Don’t believe the hype of this thing, it will probably be the most hated thing in WordPress.

        At the very least, they should give us an out to return back to the TinyMCE, at least that way, EVERYBODY would be happy.

        Report


      2. With shortcodes, it’s no so much the insertion that is the problem (although that can be an issue), it’s more people deleting a square bracket or part of an attribute that stops something working.

        e.g. Many people insert their Forms via a shortcode, which is an incredibly fragile way of doing things.

        Besides, having square brackets with cryptic codes inside makes it look like WordPerfect circa 1990 to someone non-technical!

        I’m sure it would be easy enough to write a plugin to revert to TinyMCE if they don’t offer Gutenberg as an option in the first instance.

        I can see some negatives to Gutenberg, but I think at this stage constructive criticism is what’s called for to make a promising start into an awesome finish.

        Report


    2. No one is forcing this on anyone, it’s a preview of a proposal. Nor am i particularly sure what Automatic has to do with this. But i know people like to blame them for all the supposed ills.

      It’s a preview of whats to replace the main content editor, not a redesign of the edit screen. While I agree that the UI they choose is confusing, i highly doubt that it’s the proposal to strip out any and all custom meta fields. No the preview doesn’t help us to understand how that will be handled but lets not be overly hyperbolic.

      Report


      1. The confusion here may come the fact that Mullenweg actually describes it as an edit screen replacement in a recent WordCamp Europe Interview video.

        There is also confusion surrounding whether the goal of WordPress 5.0 and features like Gutenberg are trying to compete with products like Medium, Squarespace / Wix or all of them.

        Report


      2. Yes, nobody is forcing this on anyone, for now. They will force it down our throats when V5.0 gets released, they made that pretty clear.

        Report


    3. Hear hear, about going the way of Microsoft (whoever is in charge, that is). Making decisions for users, aiming at the clueless masses and at steering them in a direction desired by some higher ups, leaving the rest behind, eventually with a more or less angry quip about the “vocal minority”.

      I’m staying at 4.5, and hope it’ll keep getting security updates for a good long time (though the fact that you’re not notified of minor updates available for your specific version (auto is off, obviously!) and only of the latest version released is always a bit of a bother).

      About the issue presented in the post regarding background images though, isn’t that how a background image is supposed to behave, being as large as the area it’s a background of?

      Report


  3. The UI change in the preview, i think, ends up causing more confusion and questions then it helps on focusing on what Gutenberg might bring to the basic content editing experance.

    I end up wondering how this plays with custom meta and various tools that share the post edit screen. It doesn’t make clear how all this would be delineated. I understand that the preview is just focusing on the main content editor but by removing all familiar UI I think it separates it a little too much.

    In terms of the editor itself I was relatively happy. I think some clients who have a tendency to poorly format content will appreciate the restrain the editor brings in. Both in how it visualizes content blocks and limits the number of options.

    I assume, i hope, that their will be control over removing or adding content block types (at least as a way of removing the new additions or adding in short code options). The new additions that seem short code inspired (forgot to check the output to see if thats what it is doing) should go. Especially the button and cover element. It’s not clear what purpose it serves. It’s really something that should be left to theme and plugin developers to choose. If they are just a preview to what could be added as a custom element then i apologize, and like the idea.

    I would also love to see the content blocks more easily rearrangeable, replacing the up and down arrows with a simpler drag and drop. It should also be easier to add a new content block underneath and existing block anywhere in the stack.

    Report


  4. After playing with it some more, it does handle pasting in larger documents (simply formatted, with paragraphs, maybe a heading and some bold text), poorly. The plain text editor within Gutenberg actually handles it better.

    When i pasted in a large text document into the first content block it remove all paragraph spacing. I am left with a giant undistinguished block of text. Even if you pasted in plain text, it switches back to a giant lump in the visual editor. While i’ve disagreed with people that composing content outside of wordpress is the workflow that represents the most prevent way to working with content, this is not helping that case. If line breaks and paragraphs can’t be discerned then content editing became even more or a mess. It limits you far too much to working one way or the other.

    Its use of tabs is also all screwed up. If your in a content editor you expect a tab to address spacing and not jumping between focusable items.

    Nor am i sure why the sidebar is disappearing to be overwritten by block settings (most of which are empty). That just causes more confusion.

    Seems like when it comes to wrangling blocks and content creation, more focus should be given to the content creation aspect over the block wrangling. Otherwise your just shifting focus to other elements or tasks that aren’t the main focus of writing content.

    Report


  5. One last thought. Using Github as the place to collect comments is bad. I understand it from a developer perspective, but it represents such a roadblock to people actually leaving feedback that it seems actively disinterested in hearing from the majority of users who will be affected by this change.

    Report


  6. Had my first play with Gutenberg today and I think its a very important step in the right direction.

    A lot of people are hating on it but just bear in mind its only version 0.2 – if you notice an issue – get involved on github.

    Report


  7. Unless Automattic comes up with a response to WIX and SquareSpace and the dozen “builders” that is standardized- it’s just going to get worse.
    We now use Divi for almost everything- and it’s still not easy or sexy.
    This shouldn’t be so difficult.

    Report


  8. I don’t get all the angst. It’s WordPress content contained to components. The web is moving to a more component-based nature. There’s a reason why we’ve moved away from animated GIF’s and table-based layouts; the web evolves and technologies adapt.

    Report


  9. Looks promising to me, how ever being non coder looks difficult to understand it while creating custom blocks. it will take almost year to get in routine and custom development.
    I let my customers handle their websites, so this looks good move to me.
    writing shortcodes for each and everything is panic but if after writing some blocks it may help, if it allows custom fields, forms and supports custom post type in future then it will be awesome feature.

    I like UI, its neat while using fullscreen, modern and I am sure it will evolve much better in future !

    Report

Comments are closed.