Gutenberg

Updates and deep dives into WordPress’s block editor innovations and improvements.

  • WordPress Explorations: Application Menu

    This is part of my WordPress Explorations series, where I’m exploring new, far-out ideas about WordPress.

  • WordPress Explorations: Pages & Layers

    This is part of my WordPress Explorations series where I’m exploring new, far out, ideas about WordPress.

  • Composing with patterns

    It’s no secret that I’m a fan of WordPress patterns.

    The ability to design a part of a site with a bunch of blocks and have it persist—whether synced or not—across my site, or shared across most others, is quite a powerful idea.

    While they’re great, I feel there’s more potential to unlock with patterns, especially if we consider them as sections to compose pages with, not just groups of blocks.

    Think of a site’s hierarchy: A site is made up of pages, which are composed of patterns, which consist of blocks—essentially, data objects. If patterns and blocks represent differing levels of hierarchy, why are they currently treated the same in the WordPress editing experience?

    So let’s explore.

    One idea is to treat patterns as a higher-order experience, where invoking a site’s pattern library zooms out the canvas to provide a bird’s-eye view, enabling you to compose with patterns, like this:

  • A new block: Cards

    I recently built a fun new WordPress block to add collection of “cards” to my blog, as seen on my home page.

    This block is technically two blocks: a “Cards” block and a singular “Card” block, which is repeated—reminiscent of the WordPress Buttons block. Even now, I find it incredibly helpful to look at the source code for official WordPress blocks, which has all the tried-and-true methods for just about any type of block you’re looking to build next. Don’t reinvent, iterate.

    The block is dynamic, which means the block content is not stored statically in the post content, but rather rendered server-side. I could’ve done it static as well, but dynamic blocks are simple and fun to build—especially using the render file, which I don’t think many folks know about yet.

    Now there is some opinionated styling—color variables in particular may not map to your theme—but you can change colors with the typical block style controls.

    You can download the block from Github. I’ll consider uploading it to the official Block Directory after I tidy it up a bit.

  • Let’s build more blocks

    I like this idea shared by Matias Ventura, centered on making it easier to introduce standalone blocks to WordPress via the Block Directory. Leveraging the existing Gutenberg infrastructure and contributor base, allows for significantly more collaboration, which would lead to a more diverse collection of high-quality, endorsed blocks for everyone.

    Scrolling text, link cards, icons, dark mode toggles—the list goes on of interesting blocks that would be great if served at the quality threshold of core blocks.

    The blocks in WordPress core are best-in-class. I’m looking forward to discovering others in the Block Directory that share the same DNA as these.

    What do you think?

  • Evolving the command palette

    My friend and colleague Anne McCarthy recently published a guide on what’s landing in this next iteration of the command palette. This next iteration of the WordPress Command Palette is looking so nice. New commands, a polished interface, and more accessible — what more can you ask for?

    And if you’re a plugin developer, lean into Riad Benguella’s WordPress Command Palette API post to add your own commands, and peruse the core commands, straight from the source. Some days it feels like WordPress 6.3 just landed, but 6.4 is shaping up quite nicely. Onward!

  • Content-only block editing

    As WordPress blocks—and therefore patterns—continue to expand in scope, the need for a simplified editing experience is more present than ever. Sure, the new tooling is nice — like fluid typography, new spacing controls, element hover color support, padding, layout, etc — but it’s also quite a lot to take in.

    Cue the new template locking mechanism for making only content blocks (text and images) editable within a pattern, landing in the upcoming WordPress 6.1 release.

  • A new era of WordPress themes

    We all knew the landscape of WordPress themes was shifting with the introduction of Gutenberg. What we didn’t know, was by how much.

    With the arrival of the anticipated Full Site Editing experience into WordPress 5.9, themes are starting to look very different.

    This new class of block-based WordPress themes arguably introduces the biggest change to themes, since well… themes existed. These themes are built entirely with blocks. That is, the headers, footers, blogroll, and page templates — literally every aspect of the theme. If it’s on the page, it’s a block.

  • All my blocks

    It’s long overdue, but I’ve recently set up a richtabor/blocks repository on Github that links to the source code for the WordPress blocks that I currently have published — including a few that are yet to be available on WordPress.org.

    Every single block I’ve added, I built out of a need of my own. I wanted to be able to add a simple publishing checklist to posts, so I created the Todo List block. And I like to leave editor notes throughout my posts with the Markdown comment block, so I don’t forget things.

  • The pattern block

    I’ve long been a huge fan of block patterns. So much that I see patterns becoming the primary method most of us lay out pages within the block editor. And with the recent release of Gutenberg, and upcoming release of WordPress 5.9, patterns are getting a lot of attention. There are a number of Pattern API improvements on the way, but one I am most interested in, is the addition of the Pattern block.

  • Publishing checklists with the todo block

    Do you publish online? If so, this one is for you.

    I’ll show you how I created a publishing checklist that is automatically added to the top of every post I draft, to ensure I follow my publishing workflow. This way, before I hit that ominous blue publish button, I know if each publishing task is properly accounted for.

  • Standardizing theme.json color slugs

    This is part one, of three, in a series on standardizing how we build this next generation of WordPress block themes to accompany the Full Site Editing effort. If you like this, read on about standardizing font sizes, and standardizing site spacing. Each of these are what I would consider design foundations of a website, of which should be functionally standardized.

  • Standardizing theme.json font sizes

    This is part two, of three, in a series on standardizing how we build this next generation of WordPress block themes to accompany the Full Site Editing effort.

    If you like this article on font sizes, read on about standardizing color slugs, and standardizing site spacing. Each of these are what I would consider core design tenets of a website, of which should be functionally standardized. By standardizing a few entries within a WordPress theme’s theme.json file, we can finally create a class of themes that truly are interchangeable. Interchangeable in function, while remaining distinct in style.

    Here’s a take on why this is important, and how weget there.

  • Standardizing theme.json spacing sizes

    This is part three, of three, in a series on standardizing how we build this next generation of WordPress block themes to accompany the Full Site Editing effort.

  • I made a todo list block

    I’m currently full on in the process of building a full site editing Block Theme to replace my blog’s current theme, Tabor. While diving into this project I’ve explored a few areas where I can improve my personal publishing flow.

    The first was bringing editor comments into Gutenberg with my Markdown Comment block, and today I am releasing a second in that same vein: the Todo List block