IndieWeb Blocks

Note: This post has been sitting in my “RSS-only” category for a little while. I decided to “list” it on my home and archive pages after all, as it may shed some light on how the IndieBlocks plugin for WordPress came to be.

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 (taxonomy-and-meta-box-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 “in-content” markup.

Still, it’s easy to screw up.

I also often post quick notes from my phone’s Micropub app, and I’m surely 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 done a bit of thinking: 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 removes certain attributes. The only core 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? Blocks, after all, are meant to do just that: have a user add a smallish building “block” to 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.

So, I decided to take a look at block development. Now, I’d consider myself reasonably versed in vanilla JavaScript, but I know absolutely nothing about React or JSX. That’s okay, though; I managed to get by using “just” ES5.

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.)

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 …

Speaking of 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 myself am using a bit of a trick to hide note titles inside the editor. In combination with Twenty Twenty, for instance, these are huge! And notes should not have (or rather, not display) titles …