Gutenberg 1.4 Adds HTML Mode for Blocks

Gutenberg 1.4 was released today with a new feature that allows users to edit HTML on a per-block basis. HTML mode can be triggered by toggling the ellipsis menu and selecting the HTML icon. This will switch the block between visual and text mode, without having to switch the entire document into text mode.

Contributors debated on whether or not to place the HTML button in the quick toolbar or to add the button to the side of the block. Eventually, they landed on putting the trash icon, the cog settings, and this new HTML mode under an ellipsis.

Gutenberg testers will also notice that version 1.4 redesigns the editor’s header, grouping content actions to the left and post actions to the right.

This release adds the initial REST API infrastructure for reusable global blocks, an idea Matias Ventura proposed several months ago. The pull request was created by new Gutenberg contributor Robert Anderson, a web and mobile developer at Tumblr. It is based on the technical details that Weston Ruter outlined for creating dynamic reusable blocks. Anderson highlighted a few examples of what this infrastructure will eventually enable for users:

  • Convert a block into a reusable block, and give it a name
  • Convert a reusable block back into a regular block
  • Edit a reusable block within a post and have the changes appear across all posts
  • Insert an existing reusable block into a post
  • Delete an existing reusable block

Anderson said the next step is adding a core/reusable-block block to the editor that can be rendered and edited, followed by a UI for adding, deleting, attaching, and detaching reusable blocks.

Gutenberg 1.4 will now show a users’ most frequently used blocks when hovering over the inserter. If the editor doesn’t have enough usage data, it will display the paragraph and image blocks by default.

Version 1.3 of the plugin introduced a new feedback option for testers with a link in the Gutenberg sidebar menu. Ventura reported that the team has received 12 responses so far, which included four bugs and two proposed enhancements. Check out the full changelog for 1.4 for more details on what’s new in the latest beta release.

9 Comments


  1. Even at this stage, I still want to see this Edit Page Replacement scaled down in scope to a just an Editor replacement and for Posts only. That’s the only place it belongs for now IMO. Tackle Pages, CPTs and replacing the entire edit page later. The plan seems to still be, slap a Editor label on it anyway even if that’s disingenuous to the WP community.

    The blog post area really needs what Gutenberg provides and it’s also a great place to start the transition to the future of WP. If the project scope changed to this, Gutenberg might finally be perceived (at least by me) as a welcome improvement rather than an unwanted menace. With a little less ambition and more pragmatism the project could be successful instead a disaster.

    Report

    Reply

    1. Yes, getting just the Editor right to start would be a good way to create achievable goals and to ensure continuity in the WordPress user/publisher experience. When the Editor is mastered, additional goals will present themselves. Well said.

      Report

      Reply

    1. @Johnny – Really? (shudder) – If Gutenberg ever becomes something like Oxygen, I may weep openly. I like Gutenberg how it is currently.

      The current early UI / UX of Gutenberg and the WP Customizer while limited are better. Before you ask – Yes, I have (unfortunately) actually used Oxygen itself and recently too. It still sucks the air out of the room IMO. While none of these tools are fully baked yet, Oxygen has the furthest to go being WP User Community friendly.

      It’s like the design for Oxygen was inspired by some old Adobe Photoshop version and implemented worse. Adobe’s UI designs are often terrible to begin with (a sentiment shared by many better at design than myself) so using it as model for anything is likely ill advised from the start.

      Report

      Reply

  2. Anyone here use Beaver Builder or other visual builders? How do you think this will affect those when this becomes part of mainstream WordPress?

    Report

    Reply

    1. I imagine that the page builders will extend upon gutenberg to make their systems even better and faster – that would be the eventual goal

      Report

      Reply

  3. oh great… they’re still touting raw, editable html as if it’s “structured data”.

    so, when the html needs to be updated to meet evolving standards or different design choices in a redesign, it means modifying every post everywhere, and because these blocks can be modified as raw HTML, any automation created to do so is likely to get hung up on “modded” blocks.

    Data Structure and HTML output should never be combined. The result is a mess that fails to understand that the finer points of output syntax will vary based on context.

    Imagine trying to render an HTML email template from a Gutenberg post, and you’ll understand the nightmare this storage method leads to. On Github, they’re are arguments as to whether column blocks should be based in flex or in row/column markup. If you want to make a compatible email, the answer is still html tables. Maybe they should use that for columns in every context, to be compatible?

    but, despite all logical criticism, the ship of feceus sails on into the maelstrom.

    Report

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *