I’m definitely not the first to dabble in Gutenberg blocks “for the IndieWeb,” but, bear with me. (I swear there was at least one other blog post on the subject, but I just can’t find it anymore.)
In the old days, you would add microformats to WordPress posts either as hand-typed HTML or by using the (taxonomies and meta boxes-based) Post Kinds plugin.
I myself have always liked the flexibility of the former, where a post type (or kind) is implied solely by its markup. Still, it’s easy to screw up.
I also often post quick notes from my phone’s Micropub app, and I’m not going to use my phone to add all sorts of HTML by hand. Rather, I have a hook in place that automatically adds the same, nicely microformatted, introductory paragraph to posts of a certain type.
Anyhow, in hopes of seeing more people adapt microformats (and Webmention, and so on), I’ve been thinking a bit. What would a Gutenberg approach look like?
Surely, we could manually add HTML classes and the like to blocks, too—that’s what “Edit as HTML” is for, isn’t it? Except Gutenberg actually makes this harder; it sometimes even strips away certain attributes. The only block that (almost) always works is the Custom HTML block. Not so user-friendly.
We could use PHP to define a shortcode, and tell folks, “Just use the Shortcode block with these and these parameters.” Kind of old-fashioned, and not very user-friendly either.
One or more custom blocks, then? (Also, there’s block templates, block variations, and block patterns—I know! But, again, merely using these in combination with core blocks is going to lead to trouble.)
Blocks, after all, are meant to do just that: have a user create a building block for a post or page, without having to worry about code at all.
We could leverage a plugin like Genesis Custom Blocks to “write” no-code blocks (and I have, in the past). That would work for one site, but doesn’t scale very well.
Either way, I found it “relatively easy” to create a block that takes some inputs and renders microformatted HTML.
There’s a million ways this can be improved, still.
Right now, in the editor, I stick with a so-called
Placeholder component; the actual output is only shown on the front end. We could probably do something about that.
Also—although I’ve always done it this way, and actually find it works well—the “block” won’t go and create a fancy, e.g., “reply context” (for which it would have to download and parse the page we’re replying to). I.e., no title or author information (yet). That can be fixed using server-side rendering and whatnot, later.
I also looked into something called
InnerBlocks, which would allow our block to not just spit out some introductory HTML, but contain, e.g., one or more “core” blocks, too (and conveniently wrap them in something like
<div class="e-content"></div>. Unfortunately, this approach would often give me “block validation” errors when hopping into the “Edit as HTML” view and back …
e-content. You could either automatically add this class to every single post, but I often want to have these introductory paragraphs (or “reply context,” etc.), or certain images, and so on, sit outside of
e-content. (Because doing so can positively affect how posts are rendered inside Microsub readers, or simply because it makes sense, semantically.)
So, for that, I’ve resorted to a block template. All of my (short-form) notes start off with a context block followed by a group block (with that
e-content class already set), to which I can then add Paragraph, Image, or whatever other blocks.
Also, I’m using a bit of a trick to hide note titles inside the editor. In combination with Twenty Twenty, for instance, these are huge! All while notes should not have titles …