Indieblocks’ Implicit Post Types

One line that has stuck with me (emphasis mine):

Post Type Discovery specifies algorithms for determining the type of a post by what properties it has and potentially what value(s) they have, which helps avoid the need for explicit post types that are being abandoned by modern post creation UIs.
Post Type Discovery

As you may know, Indieblocks comes with note and like custom post types—because keeping short-form post types apart from regular “articles” keeps WordPress’ admin interface neat and tidy. There are, however, no (explicit) reply, bookmark, etc. post types.

Instead, we trust third-party software, like feed readers or Webmention servers, to correctly parse posts’ microformats in order to decide how to interpret and display them. And this works just fine!

On our own site, however, we may want to treat, e.g., bookmarks a bit differently from “regular” notes.

A note—a short, titleless status—for instance, may get an autogenerated “title,” so we can tell them apart in WordPress’ admin interface. On the front end (and in RSS feeds), this title is hidden. (We typically display statuses in full, even on archive pages.) We also don’t apply a p-name class to it.

A bookmark, however, could benefit from being named after the bookmarked page. Maybe we’ll want to show a thumbnail or something, in the future, rather than the complete post. But … this requires we somehow, somewhere, keep track of posts’ “IndieWeb post type.” A post type implied from markup rather than set explicitly.

(Well, that’s what taxonomies are for! Or WordPress’ built-in post formats! I hear you say. And you’re not wrong. I’ll be looking into automatically assigning these next.)

For now, I’m merely parsing post content on every “save,” much like the above-mentioned third-party clients do, and, if there’s a u-like-of or u-bookmark-of link, I grab its text content and set the post’s title to that. If this text content happens to be a URL, I fetch the page and look for a “better” title.

In fact, if the post was composed in WordPress’ block editor and contains, e.g., a Like block, that block will likely have already fetched the page’s metadata. (Which can easily be overwritten, because some pages are weird.) So the plugin, when the post is being saved, will act on that.

For Micropub-created likes (and bookmarks), you can either send a title along, or rely on the plugin to grab the page in question (and hope the remote server doesn’t apply aggressive “bot” blocking techniques).