What IndieBlocks Does, and Why
I recently created a WordPress plugin that pretty much does the following.
Say your (not-overly-customized) blog lives at
https://example.org, and your homepage holds just your posts, and your posts’ URLs each look like
If you then were to install IndieBlocks and blindly enable all settings, you’d get:
- A “microblog,” at
- Microblog feeds at
- Your main feed, at
https://example.org/feed/to include both your posts, and these new “notes” (and “likes,” which I’ll skip for now but discuss below)
- A new, “post-only” feed at
https://example.org/archives/feed/(looks an awful lot like your posts’ permalinks, doesn’t it?)
- A so-called “Context” block, which you can use to easily add “microformats” to your notes
- On the condition you use a “block theme,” microformats parsed “into” your theme
Microformats, both the in-post kind (like those added by the “Context” block, but you could just as well use custom HTML) and the “theme microformats,” are important if you want Webmention services to be able to more accurately “read” your posts (and notes, and likes).
(There’s no such thing as “in-post” or “theme” microformats, but in WordPress, this separation does exist, so we’re going to roll with it.)
For maximum compatibility with microformats parsers, you’ll likely want to show post date and author blocks below (or above) each and every post (and note, and like), and a title (which you could visually hide for notes), and so on. This may require hopping into WordPress’ “Full Site Editor” in order to add the necessary templates and blocks.
If you’re running a “classic” theme that has baked-in microformats2 support (the “2” is sort of important, but we’ll keep that for later), all of this should already be covered in the theme’s PHP templates. Modifications would have to be made through a child theme.
I want my microformats “baked into” my posts, so that if I were to ever disable this plugin, all of my existing content stays untouched. Current microformats plugins rely on PHP “front-end” hooks and such, which I wanted to avoid.
“Baked-in” microformats pretty much means either custom HTML, or a block-based solution, so the choice was easy. (In fact, it’s still perfectly possible to “augment” your posts using a Custom HTML block. Heck, it’s possible to use IndieBlocks with the classic editor, too. You’d still get the Custom Post Types, the feed changes, and everything, but would have to handle microformats some other way.)
How the “Theme Microformats” Came to Be
In parallel, I attempted to create a “microformats version” of WordPress’ default Twenty Twenty-Two theme, and I quickly realized that it’s near impossible to customize the blocks that are at the basis of “block themes.” There’s no PHP templates to modify! However, each and every block theme relies on the same “core” blocks, which can be overridden (in a sort of awkward, almost backwards fashion, but still).
Which means it suddenly makes a lot of sense to put these modifications in a plugin instead of the usual child theme. I mean, they don’t depend on the actual (block) theme at all! So that’s what I did.
On Custom Post Types
A last aspect is I really wanted to use Custom Post Types for my “microblog,” because of the way they’re handled in WordPress’ admin interface, and the fact they get their own RSS feeds, and so on. (There are drawbacks, too: permalinks options are sort of limited, and it requires code to have them included in your overall feed, etc. Had I used a custom taxonomy instead, “notes” would just behave like “regular” posts. Because they would have been regular posts.)
Other benefits: many WordPress developers have worked with CPTs extensively; they could easily—in a few lines of code—change the “notes” slug into something else, for instance.
Almost forgot. Likes. They’re just like notes; a bit more limited, perhaps. They idea is that you don’t necessarily want to have all of your likes appear on your homepage or in your main RSS feed (or in your site’s “microblog” section).
I personally use “notes” for simple status updates, bookmarks, and even “reposts” of other people’s notes, but I exclusively use “likes” for, well, likes.
Remember: the WordPress post type—post, note, or like—does not determine how microformats parsers see a post; they look only at microformats to decide how a post should be displayed. (I’m sorry if this is all confusing as heck.)
Anyhow, if you think likes are dumb, just leave them disabled. If you want to have them in your “main” microblog, just leave them disabled and pick the “note” post type for everything, including likes. (Random fact: Even a “normal” post could be like; it’s the microformats, stupid!)
I’m working on integrating Webmention right into this plugin; meanwhile, it should be possible to set the existing Webmention plugin up to work with Custom Post Types.
Because nearly everything in IndieBlocks is configurable, it will be possible to keep using (most) other IndieWeb plugins beside it. Simply disable the bits you don’t need!
Ryan Barrett on
… liked this!
Via snarfed.org, in reply to .
… bookmarked this!
Via www.zylstra.org, in reply to .
Aaron Davis on
Jan, this looks interesting. I am intrigued in an alternative to Post Kinds. I fear that I am going to hit a wall at some point if or when the classic plugin is no longer supported. I like what it does, but agree with your concern about it being outside of the post. One of the things that I am coming to realise though is that unless I were to roll out my own solution (which seems well beyond me) that I am always at the whim of somebody else’s design principles.
Via collect.readwriterespond.com, in reply to .
Jason Tucker on
I’ve been working on building up my skills in our post Twitter life by trying to figure out the Indieweb. Many years back I met […]
Via www.jasontucker.blog, in reply to .
I am taking a leap of faith here and try Indieblocks and WordPress’s new theme, Twenty Twenty-Three on this brand new (micro?) blog.