The IndieWeb movement had become somewhat a big deal for me in 2019. Potentially the biggest life change for the calendar year. You can read more about that over at Hello #indieweb on my IndieWeb-focused site. I’m posting here, because this domain is my web development blog.
In case it was somehow never obvious, I am a WordPress user. This isn’t going to stop in the foreseeable future. Thankfully there’s a healthy number of plugins available that enable various IndieWeb technologies and standards, helping your site turn into a content self-owning powerhouse.
It feels like, at times, the plugin descriptions and explanations are heavy on terminology and concepts that are already known to those already participating in the IndieWeb community. This risks causing confusion for newcomers who just heard this term “IndieWeb” at a WordCamp or meetup. Thus, my purpose here is to attempt dispelling some of that confusion and provide clarity of when you may need or want each. Even I’ve struggled comprehending some of these details and I hope I’ve come around enough that I can describe in more accessible ways.
IndieWeb Plugins to discuss
These are listed in no particular order, other than IndieWeb core plugin going first. While not required to have a website participating in the IndieWeb, it does a good job pulling the rest together. This is also not a comprehensive list, as there may be others available.
IndieWeb Core
Out of the box, the core plugin does not do a lot on the surface. It does provide a new admin menu section with some pages about getting started, an easy installer page, and an options page to save some initial settings regarding site identity.
Under the surface, it also adds user profile fields that allow providing extra external links where people can find you. You may recall that for a long time WordPress offered some basic social profile fields. IndieWeb core adds their own for popular social sites they use.
That may not sound all that impressive but wait, there’s more. The plugin uses that information to create a microformats based h-card for you and the links it generates include rel="me" attributes to help establish those profiles as…you. Hopefully those sites include the ability to add, or already have, rel="me" attributes for their website fields in your profile areas. That way, if you link your website on those sites, a two-way relationship is established.
Lastly it also ships with a basic widget that will output the h-card for you, wherever widgets are displayable.
Webmentions
The root of webmentions is comments and commenting. However, probably not quite how you’re thinking.
If you’re familiar at all with “pingbacks”, Webmentions are similar, but in my humble opinion, better. The first thing to know is that Webmentions actually have a Web Standards Editor’s Draft in place. Much like a pingback, webmentions are a way to notify any URL when you mention or link to it on your own site.
Unlike pingbacks, Webmentions can act and be displayed like actual, normal comments. This is especially true when paired up with Semantic Linkbacks. Why this distinction is important is because people do not need to visit your site, locate the comment form if it exists, and use your site’s interface to post a comment if they don’t want to.
They can create a post on their own site with the content acting as a comment, and let your site know about it. You will be notified and receive a copy added to your comments list, and you can display it in the comments for your post. Meanwhile, their site also retains a copy.
Semantic Linkbacks
Speaking of Semantic Linkbacks, let’s dive in. If you have ever created a theme, you’ve probably dealt with customizing comments display if you didn’t disable comments completely.
Semantic Linkbacks hook into the comment form code to override and customize beyond WordPress defaults. It will add microformats rich markup for various comment type display, including webmentions. If the originating website provides them, the webmentions may even display h-card details as part of the comment, without extra configuration. You will have rich and full discussion areas.
Microformats 2
The Microformats 2 plugin is potentially the simplest and hands-off to use. At the heart of it all, the plugin simply filters in various microformats classes from the its standards. These places include the body tag, wrapping markup on posts, author information, and comments.
To help ensure your theme is doing its part for this plugin, make sure it uses functions like body_class(), post_class(), and comment_class(). Also use WordPress core functions for authorship/avatar display instead of your own. The plugin should take care of itself from there.
You should be able to utilize these alongside Schema.org semantic markup, but if I’m wrong and they cause conflicts, someone let me know.
IndieWeb Post Kinds
The most appropriate way to think of post kinds are what post formats may have been. In reality, they’re a mix of post type and post format, powered by a custom taxonomy.
They’re like post types because they are technically types of content. For example, a reply to someone else via webmention, or a “favorite”, a “bookmark”, a “check-in”, etc. This is in contrast to WordPress storing some meta that states its “format” which is meant to conditionally adjust post markup. There are also many more post kinds available than WordPress offers.
Along with that, each kind has their own rich markup output to help make the most out of the content when shared or syndicated elsewhere.
That’s not all though, you specify the “kind” for each post with taxonomy terms. In this case “Kind” is a custom taxonomy, and each “kind” is a term. This means that each “kind” has its own archive along with out-of-box, already configured, RSS feed. Displaying them, via familiar WordPress core functionality, becomes extremely easy.
One of the biggest factors here that may prevent usage of Post Kinds on your site, is that right now, it does not have Gutenberg support. You will need Classic Editor for it to work at all. I know that the contributors to the Post Kinds plugin would love help with Gutenberg support.
Syndication Links
When it comes to Syndication Links, it’s all about the broadcasting, the sharing, the posting to social sites. If you’re big on social sharing, you’ll appreciate this plugin.
With Syndication Links, you can display the created permalinks on XYZ social site once it’s been broadcasted. The links will also be wrapped in semantic markup indicating that those sources are syndication sources.
Say I write up an awesome post and start sharing it. I go to Twitter, write up a quick tweet and provide a link to the post and hit submit, or I go fetch the link since I auto-post to Twitter already via a different plugin. I could copy/paste that new individual tweet URL into the Syndication Link metabox for the post and save it.
That tweet permalink will now be displayed alongside my original post. Now say I do the same on Facebook, LinkedIn, or whatever other popular social sites you know of. Pretty soon I have a nice long list of syndication links that people can click on to go right to the social posts.
Admittedly, there could be a fair amount of manual work for this. If you’re a frequent poster, it may become tedious. There are some plugins that can automatically append the new permalink that get cross-posted, but there aren’t many. If you’re adventurous and want to help develop for the IndieWeb community, this could be a good place to explore.
Nonetheless, your original post can turn into the definitive source to find all the syndicated copies out in the world wide web.
Micropub Server and Micropub
A Micropub Server, and more specifically Micropub as a whole, may be one of the more difficult ones to wrap your head around for uses, but I will do my best.
Micropub itself is another technology used by the IndieWeb that is actually a W3C spec, and one that’s at the recommendation stage. This community loves its standards technology, and for good reason, like long term interoperability.
There are two sides to this, a Micropub client, and a Micropub server. Here’s the thing though, you and your website are not the client, you’re actually the server. Before getting worried, that is actually the easier side to be on. All really needing done is installation and activation of the plugin. Majority of the rest of the plugin is self-maintaining internally.
That leaves the client and as I already mentioned, that’s the workhorse. A Micropub client needs to do the heavy lifting of preparing content for a Micropub server. A client is also not a part that you will typically install in WordPress itself. Before I get too far off the rails, I feel need to explain roles between client and server.
Reel it in a moment.
A client is a UI, a browser add-on, a website, a smartphone app, that collects information to be posted somewhere. It collects that input from a user and upon submission, the client formats the data in a very specific way for an HTTP POST request. It sends that request to a provided server endpoint.
A server is an endpoint that can receive and listens for HTTP POST requests, and upon receiving one, accepts the content, and does something with the data. In our case, the Micropub Server plugin will parse the data and create a new post for you.
First familiarity
These may sound familiar in a couple ways. If you recall, there’s a “Quick Draft” widget available in your admin dashboard. It’s a vastly reduced UI, so much that it fits in a widget, and you can quickly save a draft post with a title. This is similar to what a Micropub client could look like, except it’s not found in your dashboard, and it doesn’t just save to draft.
Second familiarity
The HTTP POST request part may also feel familiar if you have ever dealt with web hooks. This is the opposite of making HTTP GET requests on a cron schedule asking “hey, you got anything for me? No? Okay I’ll check back in an hour”. Instead, your site simply waits for the POST request to show up, and only then does it do anything.
At this point, I can hear you going “why would I need a Micropub client, when I could just visit my dashboard, and create a post normally?”. Really, you just stated one reason someone may want to use a client. Someone may not want to deal with the full post editor or admin area in general. These spots can definitely be quite messy and overwhelming at times. There’s reason UI like Twitter’s became popular, it’s simple and quick, especially if one isn’t aiming to post long form.
Another reason is choice. You could use the WordPress app, by all means, but what if there were cleaner, more lightweight alternatives that allow you to get the job done and get back to living life?
I wouldn’t write this post here using Micropub, it’s way too long and breaks the “Micro” in “Micropub”. However, if I just wanted to post a quick status update, why bother with the admin area?
In conclusion
I know that I did not cover every plugin listed in the IndieWeb Core Extensions page, but I want to stay honest too. I covered the ones I have looked at most and have the greatest personal domain knowledge over. After all, that’s why I wanted to write this post in the first place. To explain these in ways I hope are easier to comprehend for those who are already familiar with WordPress.
To be “complete” though concise, Simple Location deals with geographic and weather information, like the description says. IndieAuth is more around authenticating yourself and using your own domain to sign into services. WebSub/PubSubHubbub, the mouthful of a name, I believe, is more around “subscription” via to notifications. If I had to peg one plugin as possibly turning your site into a Micropub client, it’d be that one.
In conclusion for real
I hope that I dispelled confusion about these plugins and made their purposes clearer. With the information, you can now choose which are for you and your online presence goals.
Comments are open and I’m ready for any further questions you may have. If I don’t know for sure, I’ll do what I can to find out for you or find more resources.
Nice Article, it put the IndieWeb on my Radar.
Thank you for explaining all the plugins so well 🙂 I have most of these installed on my blog and now have a better understanding of which ones work together.
One thing that I am still quite confused about is how Post Kinds and Micropub (and eventually Gutenberg) works together. When submitting a post over Micropub, does it run Post Type Discovery to get the correct Post Kind? Or is that explicitly passed by the Micropub client? Also, what happens if a blog has Micropub but not Post Kinds?
Also, I got really confused about the post kinds, post types and post formats part. I am not really sure that I fully understand the distinction 🙁
Again, thank you so much for writing such a thorough post 🙂