Webmention is one of the fundamental indieweb building blocks. It enables rich interactions between websites, like posting a comment or favorite on one site from another site. This post will walk you through the simplest way to get started sending webmentions to other sites so that you can use your ...
A stupendous article, I just wish I’d had it all those many years ago. Thanks Aaron!
One useful thing for beginners that I don’t think got mentioned (pun intended!) in the article is that for receiving websites which don’t have a built in webmention form you can use a service like http://mention-tech.appspot.com/ which will allow you to manually put in the sending site and the receiving site and it will act as a bridge to send the webmention for you.
Syndicated copies to:
Testing out a new (secret) micropub client for read posts. It’s got way more functionality than I though it would have to start and has a stunning and clean UI. There are some smart choices all around and it’s naturally got some fantastic semantic markup hiding behind the curtains.
Even without the micropub portion it makes a fantastic microblog for those who are into reading.
More details later as I try to get all the moving pieces working properly.
ReadCan we #IndieWeb Google Scholar? #HigherEd by Greg McVerry(jgregorymcverry.com)
So during my (ongoing) microformats crash course I have styled many citations. Writing an APA citation in html with proper markup take time. A lot of time when you write a lot of citations.
While I would consider a canonical link back to to a piece listed or displayed on an author’s website as leg...
Nothing warms my heart more than talk of furthering the idea of making academic samizdat easier and more prevalent. Some of the sketched ideas here are a necessary start.
I’ve been meaning to write regular updates to highlight some of the useful changes in the functionality of the IndieWeb suite of WordPress plugins, but never gotten around to it. There’s been a few really interesting ones lately, so I thought I’d start. Observant watchers who read through either the code or even the scant change logs before they update their code may catch some of these features, but sometimes interesting tidbits can slip by the most vigilant. Here are some interesting recent ones:
Display of Reads, Listens, and Watches in comments sections
David Shanske’s excellent Post Kinds Plugin allows one to post what they’re reading, listening to, or watching in simple IndieWeb fashion. (Examples of these on my site: read posts, listen posts, watch posts.) These posts types automatically include the appropriate microformats classes so the user doesn’t need to bother doing them manually. For a long time when replying to another’s site, bookmarking it, or even mentioning it when also using the Webmentions plugin would send the site a Webmention that would generally cause it to show up as a native comment, bookmark or mention. With an update late last year, from within the Discussion settings in WordPress, one could set toggles so that many of these webmentions could be displayed as facepiles. Other broadly unsupported post types would typically default to a simple mention.
Recently David Shanske and I started a podcast, and he thought it would be useful if his site could accept listen posts and show them visually within his comments section just like these replies, bookmarks, and mentions. Thus over the past month he’s added code to the Semantic Linkbacks Plugin to add the functionality for these types of posts to properly render showing facepiles for listens, reads, and watches.
This is what webmentions of listen posts look like on his site in his comments section:
Listen (or scrobble) posts can send webmentions (or notifications) to the original content potentially with the experimental listen-ofmicroformat. In the case of scrobbles of podcasts, these webmentions could be displayed as “Listens” which would provide the canonical copy of the podcast some indicator of its popularity and actual audience. It is tremendously difficult to obtain data on the actual number of listens within most of the podcast community and typically a fraction of the number of downloads must be used as an indicator of the actual reach. Being able to display listens could potentially be a boon to the podcasting market, particularly with respect to advertising as this type of open social web functionality spreads.
I haven’t yet seen one for watches in the wild yet, but maybe you’ll be either the first to send or receive one?
The microformats on these posts is generally considered to be experimental, but with the ~500+ users of this suite of tools as well as others who are already using them on other sites, they’ve now taken a dramatic step into the open internet and more widespread use and potential official adoption.
Editable Webmention Types and Avatars
Just yesterday, I spent a few minutes in the IndieWeb chat helping someone to laboriously delve into their mySQL databaset and find a particular snippet of data so they could manually change a received webmention from being a simple mention to being a reply so that it would display as a native comment on their website. I’ve often done this to take what sometimes seem like simple mentions and change them to replies to reveal the richer content they often contain for the broader conversation. Sadly the process is boring, laborious, and fraught with potential ways to mess things up.
As of this weekend, this process is no longer necessary. One can now go to the admin interface for their comments and webmentions (found at the path /wp-admin/edit-comments.php), click on edit for the particular comment they’re changing and then scroll down to reveal a droplist interface to be able to manually change the webmention type.
As another example of a use for this functionality, perhaps you’ve received a listen mention on one of your podcast episodes that has a lot of useful notes or commentary germane to your episode? Instead of hiding it as a simple listen, why not change the type to reply to allow a richer conversation around your content? After all, with a reasonable reply it will be implicit that the commenter actually listened to the episode, right?
Because there is currently no functionality in WordPress for saving or caching the avatars of commenters via webmention, when users change their profile images on siloed services like Facebook, Twitter, et al. the link to their old avatars quits working and they were displaying blank spaces. This is an unfortunate form of linkrot, but one that can become more visually apparent over time.
As one can see in the image for the commenting edit box above, the field for the Avatar is now editable. This means one can update out-of-date or blank avatars. One now also has the ability to moderate/edit or easily remove/switch avatars if users are sending inappropriate photos for one’s site’s audience.
We're two senior IndieWeb participants talking about owning your own content.
I can see why several folks in the IndieWeb community love this discussion. Jeena and Marjtin have a wide-ranging conversation that hits almost all of the high points and most of the discussion is very accessible. There are some places in the second half of the episode where those who aren’t developers may feel like they’re in some higher weeds particularly with some jargon, but much of it is well defined and discussed. In solid journalistic fashion, they start from the most basic (with lots of attention to definitions and detail) and ramp up to the more advanced and detailed. If you’re a blogger, journalist, librarian, educator, other who is relatively web savvy and wants to supplement your knowledge of what is going on in this area, this is a great place to help fill in some gaps before delving into additional help and documentation.
In particular, I love that they do an excellent job of helping to communicate the intentional work, craft, morality, ethics, and love which most of the community approaches the topic.
As I suspect that Jeena doesn’t receive many “listen” posts, I’ll webmention his post here with an experimental microformat class like-of. Perhaps he’ll join some of the podcasting community who supports this and make it a stronger standard.
I’ve seen a bunch of new folks coming into the IndieWeb community recently who are a bit overwhelmed with the somewhat steep learning curve of both new jargon as well as new ideas and philosophies of what it means to have one’s own domain and presence on the internet.
While parts of the IndieWeb’s overall idea are quite simple, where the actual rubber meets the road things can be a bit overwhelming, and more so if you’re a non-technical person. This doesn’t have to be the case. Generally I’d recommend to people to begin attending local Homebrew Website Clubs or, even better, to attend an IndieWebCamp in person to get a one day crash course followed by a day of building and help. Sadly, life can intervene making these not as quick and immediate a reality as one might otherwise like.
So toward the end of making the crash course to explain in relatively broad terms some of the basic terminology as well as some of the bigger individual pieces and what’s happening when using an IndieWeb site with most of the major new functionality built in, I’ve made a short pencast of what is going on. Naturally there’s still a tremendous amount to learn and do, and a million things which could always be better or improved, but if you’re setting up a site using WordPress this overview will hopefully get you a lot further a lot faster. (It may also be useful for those setting up Known or even something for micro.blog, though those will have different plugins and other small quirks that aren’t covered here.)
What is a Pencast?
Pencast?! What is that? It’s a technology that has been around for a while courtesy of Livescribe.com digital pens which not only record an audio file of what is being said, but also record penstroke by penstroke what is being written. Even better the audio and the penstrokes are crosslinked, so you can more easily jump around within a lecture or talk.
To do this you should download the version of the notes in Livescribe’s custom Pencast .pdf format. This seems like a standard .pdf file but it’s a bit larger in size because it has an embedded audio file in it that is playable with the free Adobe Reader X (or above) installed. With this version of the notes, you should be able to toggle the settings in the file (see below) to read and listen to the notes almost as if you were sitting with me in person and I was drawing it out in front of you as I spoke. You can also use your mouse to jump around within the pencast by touching/mousing to particular areas or by jumping forward and back by means of the audio bar. If you need to, also feel free to zoom in on the page to have a closer look.
Pencast PDF is a new format of notes and audio that can play in Adobe Reader X or above.
You can open a Pencast PDF as you would other PDF files in Adobe Reader X. The main difference is that a Pencast PDF can contain ink that has associated audio—called “active ink”. Click active ink to play its audio. This is just like playing a Pencast from Livescribe Online or in Livescribe Desktop. When you first view a notebook page, active ink appears in green type. When you click active ink, it turns gray and the audio starts playing. As audio playback continues, the gray ink turns green in synchronization with the audio. Non-active ink (ink without audio) is black and does not change appearance.
Audio Control Bar
Pencast PDFs have an audio control bar for playing, pausing, and stopping audio playback. The control bar also has jump controls, bookmarks (stars), and an audio timeline control.
Active Ink View Button
There is also an active ink view button. Click this button to toggle the “unwritten” color of active ink from gray to invisible. In the default (gray) setting, the gray words turn green as the audio plays. In the invisible setting, green words seem to write themselves on blank paper as the audio plays.
If you have comments or feedback, I’m thrilled to receive it. Feel free to comment below, or if you’ve already IndieWebified your site, write your comment there and send it to me via webmention, or add your permalink to the box below. Ideally this version of the pencast is a first draft and I’ll put something more polished together at a later date, but I wanted to get this out there to have a few people test-drive it to get some feedback.
After years of letting algorithms make up our minds for us, the time is right to go back to basics.
This article, which I’ve seen shared almost too widely on the internet since it came out, could almost have been written any time in the past decade really. They did do a somewhat better job of getting quotes from some of the big feed readers’ leaders to help to differentiate their philosophical differences, but there wasn’t much else here. Admittedly they did have a short snippet about Dave Winer’s new feedbase product, which I suspect, in combination with the recent spate of articles about Facebook’s Cambridge Analytica scandal, motivated the article. (By the way, I love OPML as much as anyone could, but feedbase doesn’t even accept the OPML feeds out of my core WordPress install though most feed readers do, which makes me wonder how successful feedbase might be in the long run without better legacy spec support.)
So what was missing from Wired’s coverage? More details on what has changed in the space in the past several years. There’s been a big movement afoot in the IndieWeb community which has been espousing a simpler and more DRY (don’t repeat yourself) version of feeds using simple semantic microformats markup like h-feed. There’s also been the emergence of JSON feed in the past year which many of the major feed readers already support.
On the front of people leaving Facebook (and their black box algorithmic monster that determines what you read rather than you making an implicit choice), they might have mentioned people who are looking for readers through which they can also use their own domains and websites where they own and maintain their own data for interaction. I’ve written about this in more depth last year: Feed reader revolution.
One of the more bleeding edge developments which I think is going to drastically change the landscape in the coming years for developers, feed readers, and the internet consumption space is the evolving Microsub spec which is being spearheaded by a group of projects known as the Aperture microsub server and the Together and Indigenous clients which already use it. Microsub is going to abstract away many of the technical hurdles that make it far more difficult to build a full-fledged feed reader. I have a feeling it’s going to level a lot of the playing field to allow a Cambrian explosion of readers and social related software to better leverage more easily reading content on the web without relying on third party black box services which people have been learning they cannot fully trust anymore. Aaron Parecki has done an excellent job of laying out some parts of it in Building an IndieWeb Reader as well as in recent episodes of his Percolator microcast. This lower hurdle is going to result in fewer people needing to rely solely on the biggest feed readers like Facebook, Twitter, and Instagram for both consuming content and posting their own content. The easier it becomes for people to use other readers to consume content from almost anywhere on the web, the less a monopoly the social networks will have on our lives.
This week, using the magic of open web standards, I was able to write an issue post on my own website, automatically syndicate a copy of it to GitHub, and later automatically receive a reply to the copy on GitHub back to my original post as a comment there. This gives my personal website a means of doing two way communication with GitHub.
This functionality is another in a long line of content types my website is able to support so that I’m able to own my own content, yet still be able to interact with people on other websites and social media services. Given the number of social sites I’ve seen disappear over the years (often taking my content with them), this functionality gives me a tremendously larger amount of control and ownership over my web presence and identity while still allowing me to easily communicate with others.
In this post I wanted to briefly sketch what I’ve done to enable this functionality, so others who are so inclined can follow along to do the same thing.
Setting up WordPress to syndicate to GitHub
I’ll presume as a first step that one has both a GitHub account and a self-hosted WordPress website, though the details will also broadly apply to just about any content management system out there that supports the web standards mentioned.
Register your GitHub account and your website with Bridgy
Ryan Barrett runs a fantastic free open sourced service called Bridgy. To use it you’ll need the microformat rel=“me” links on both your GitHub account and your website’s homepage that point at each other. GitHub will do most of the work on its side for you simply by adding the URL of your website to the URL field for your GitHub account at https://github.com/settings/profile. Next on your website’s homepage, you’ll want to add a corresponding rel=“me” link from your website to your GitHub account.
In my case, I have a simple widget on my homepage with roughly the following link: <a href="https://github.com/username">GitHub</a>
in which I’ve replaced ‘username’ with my own GitHub username. There are a variety of other ways to add a rel=“me” link to your webpage, some of which are documented on the IndieWeb wiki.
Now you can go to Brid.gy and under “Connect your accounts” click on the GitHub button. This will prompt you to sign into GitHub via oAuth if you’re not already logged into the site. If you are already signed in, Brid.gy will check that the rel=“me” links on both your site and your GitHub account reciprocally point at each other and allow you to begin using the service to pull replies to your posts on GitHub back to your website.
To allow Brid.gy to publish to GitHub on your behalf (via webmention, which we’ll set up shortly), click on the “Publish” button.
Install the Webmention Plugin
The underlying technology that allows the Bridgy service to both publish on one’s behalf as well as for the replies from GitHub to come back to one’s site is an open web standard known as Webmention. WordPress can quickly and easily support this standard with the simple Webmention plugin that can be downloaded and activated on one’s site without any additional configuration.
For replies coming back from GitHub to one’s site it’s also recommended that one also install and activate the Semantic Linkbacks Plugin which also doesn’t require any configuration. This plugin provides better integration and UI features in the comments section of one’s website.
Install Post Kinds Plugin
The Post Kinds Plugin is somewhat similar to WordPress’s Post Formats core functionality, it just goes the extra mile to support a broader array of post types with the appropriate meta data and semantic markup for interacting with Bridgy, other web parsers, and readers.
Download the plugin, activate it, and in the plugin’s settings page enable the “Issue” kind. For more details on using it, I’ve written about this plugin in relative detail in the past.
Install Bridgy Publish Plugin
One can just as easily install the Bridgy Publish Plugin for WordPress and activate it. This will add a meta box to one’s publishing dashboard that, after a quick configuration of which social media silos one wishes to support, will allow one to click a quick checkbox to automatically syndicate their posts.
Install the Syndication Links Plugin
The Syndication Links plugin is also a quick install and activate process. You can modify the settings to allow a variety of ways to display your syndication links (or not) on your website if you wish.
This plugin will provide the Bridgy Publish Plugin a place to indicate the permalink of where your syndicated content lives on GitHub. The Bridgy service will use this permalink to match up the original content on your website and the copy on GitHub so that when there are replies, it will know which post to send those replies to as comments which will then live on your own website.
You should now be ready to write your first issue on your website, cross post it to GitHub (a process known in IndieWeb parlance as POSSE), and receive any replies to your GitHub issue as comments back to your own website.
Create a new post.
In the “Kinds” meta box, choose the “Issue” option.
Type in a title for the issue in the “Title” field.
In the “Response Properties” meta box, put the permalink URL of the Github repopository for which you’re creating an issue. The plugin should automatically process the URL and import the repository name and details.
In the primary editor, type up any details for the issue as you would on GitHub in their comment box. You can include a relatively wide variety of custom symbols and raw html including
and with code samples which will cross-post and render properly.
In the GitHub meta box, select the GitHub option. You can optionally select other boxes if you’re also syndicating your content to other services as well. See the documentation for Bridgy and the plugin for how to do this.
Optionally set any additional metadata for your post (tags, categories, etc.) as necessary.
Publish your post.
On publication, your issue should be automatically filed to the issue queue of the appropriate GitHub repo and include a link back to your original (if selected). Your post should receive the syndicated permalink of the issue on GitHub and be displayed (depending on your settings) at the bottom of your post.
When Bridgy detects future interactions with the copy of your post on GitHub, it will copy them and send them to your original post as a webmention so that they can be displayed as comments there.
If you frequently create issues on GitHub like this you might want a slightly faster way of posting. Toward that end, I’ve previously sketched out how to create browser bookmarklets that will allow you one click post creation from a particular GitHub repo to speed things along. Be sure to change the base URL of your website and include the correct bookmarklet type of “issue” in the code.
The Post Kinds plugin will also conveniently provide you with an archive of all your past Issue posts at the URL http://example.com/kind/issue/, where you can replace example.com with your own website. Adding feed/ to the end of that URL provides an RSS feed link as well. Post Kinds will also let you choose the “Reply” option instead of “Issue” to create and own your own replies to GitHub issues while still syndicating them in a similar manner and receive replies back.
Given the general set up of the variety of IndieWeb-based tools, there are a multitude of other ways one can also accomplish this workflow (both on WordPress as well as with an infinity of other CMSes). The outline I’ve provided here is one of the quickest methods for beginners that will allow a relatively high level of automation and almost no manual work.
One doesn’t necessarily need to use the Post Kinds Plugin, but could manually insert all the requisite HTML into their post editor to accomplish the post side of things via webmention. (One also has the option to manually syndicate the content to GitHub by cutting and pasting it as well.) If doing things manually this way is desired, then one will need to also manually provide a link to the syndicated post on GitHub into their original so that Bridgy can match up the copy and the original to send the replies via webmention.
If you’ve followed many of these broad steps, you’ve given already given yourself an incredibly strong IndieWeb-based WordPress installation. With a minimal amount of small modifications you can also use it to dovetail your website with other social services like Twitter, Facebook, Flickr, Instagram, Google+ and many others. Why not take a quick look around on the IndieWeb wiki to see what other magic you can perform with your website!
I’ve documented many of my experiments, including this one, in a collection of posts for reference.
If you have questions or problems, feel free to comment below or via webmention using your own website. You can also find a broad array of help with these plugins, services, and many other pieces of IndieWeb technology in their online chat rooms.
I ran my domain through IndieWebify.me. Almost all of the rel=“me” links either don’t link back or couldn’t be fetched. The following work perfectly and can be used with the IndieAuth authentication plug-in.
That’s 4 out of 43.
Khürt , The majority of them don’t link back because the silos (like Keybase, Instagram, and Medium which you mention) aren’t putting the rel=”me” microformat on the URLs in your profile like Twitter, Github, and Flicker do. If you view the page source for those silos, you’ll see that they list your URL, but don’t have rel-me’s pointing back at you. Sadly, you can’t control these, though you could file issues with the sites that don’t to encourage them to.
The indiewebify.me site has a parser that is looking at the two sites to see that they not only point at each other, but it requires that the two links have the rel=”me” microformat on them. Most don’t, but this doesn’t mean too much in practice. Whether or not they both have rel=”me”, the only way both sites could point at each other indicates that you “own” or control them both. Kevin marks has proposed/built an interesting decentralized verification service based on them. His version is certainly much better distributed than Twitter’s broken verification set up.
Other than having a stronger two-way ownership indicator, what do you get out of them? As you mention, some have the ability to be used with IndieAuth. Those that can be used with IndieAuth are relying on the service (like Twitter or Github) having a OAuth implementation for signing into their services. This allows an indie site to piggyback on another services’ OAuth implementation without having to go through the trouble to build one themselves, which can be a lot of work to do, much less do correctly (securely). Most of the services you see not linking back not only don’t add the rel=”me” tag, but they also don’t support OAuth, so you wouldn’t get too much more out of having the correct reciprocal link anyway.
Incidentally, one of the benefits the rel=”me” links do have is that they allow you to use your website to log into the IndieWeb wiki to participate directly in that part of the community. (Give it a try!)
Some services like Brid.gy get around services like Instagram or Facebook not having a physical rel=”me” microformat because they’re relying on looking at the appropriate data (usually via API) on your profile page to see if it links back (either in your website field or typically in your bio).
Don’t be overly concerned that the vast majority of sites appear not to link back even if you’ve got links on both pointing back. (And if you think your batting average is bad with only 4 of 43, just imagine how many of my 200+ sites do?!)
If you want to see an interesting tech-forward application of rel=”me” and the XFN friends network, take a peek at Ryan Barrett’s Indie Map which he unveiled over the summer:
Some of these building blocks will likely add a lot more value later on as more and more sites explicitly indicate their relationship to and from each other.
I know that I have provided my perspective [already](https://readwriterespond.com/2017/10/indieweb-reflections/), but I have been doing a lot of thinking about it of late. There are so many elements that just feel so foreign. Take for example H-Cards.
Aaron, thanks for your continued thoughts on my post. These are some good observations. Interestingly, on November 9th of this month I had noticed that the h-card page on the wiki was one of the few around that had absolutely no section heading for IndieWeb Examples which is nearly ubiquitious on most other pages. (Examples of what others have done is not only a helpful guide, but helps to push the limits of what might be possible next.) I naturally added a section for them and added myself and made a call in the chat for others to do the same. One of the bits of feedback that resulted there was that the microformats.org wiki had a large number of examples and that was one of the reasons that the IndieWeb wiki had none. Naturally, for people in generation two and beyond this may be an issue as they’re potentially less likely to go looking for this information on another website. As of this afternoon, there’s now at least a link on that page that also points to the microformats wiki page for those other examples. I’ve also added a few other bits which may be helpful with regard to h-cards for the beginner.
As the IndieWeb continues onward, part of the underlying foundation is that “Each generation is expected to lower barriers for adoption successively for the next generation.” – from the Generations page on the IndieWeb Wiki.
To date, the majority of people in the movement are developers or programmers by trade, but increasingly there are people from generation 2, 3, and even many from generation 4 who are starting to take a look at what is now possible on the web that wasn’t just ten, twenty, or even thirty-six months ago. Many are not only just looking, but, like you, are spending the time, effort, and energy to implement what they’re able to and simultaneously spreading the word to larger circles.
As someone who personally identifies as being on the border of generations 1 and 2, I’m finding more and more people seeing what is happening and wanting the fruits and benefits of these tools for themselves. It’s the raw value they find in these methods and processes that spur them on even when they find themselves in deeper waters than they may have expected. Fortunately there are a large number of giving and helpful developers in the generation 1 crowd who are watching and listening to those coming after them. They’re taking up the mantle to not only improve things for just themselves, but to improve things for their fellow netizens.
All of this to say that there is currently a slow reworking and refining of material that’s on the wiki. It was only just earlier this week that a self-identifying fourth generation member asked about the word POSSE, which many would rightly consider jargon, and inquired about its relation to the more commonly known term of “cross-posting“. Surprisingly, cross-posting didn’t really exist on the wiki yet, but it was quickly added, and then later expanded to bring the ideas of POSSE, PESOS, PESETAS, and PASTA within it and then tied into the broader idea of syndication.
Your questions about h-card are very similar. Yes, the wiki page on the idea is certainly very generation 1 specific and perhaps a bit over-burdened by jargon. While I don’t think the concept of microformats is very difficult, I also realize that saying that is the result of having spent no less than ten hours reading about it, looking at examples, and implementing pieces of it by hand myself. So how can we make it simpler and easier for the next generation? The page needs a bit of overhaul and work for the next generations. Some of this is my goal in writing an IndieWeb book, though it’s geared toward an audience that is less likely to get their information from a wiki or contribute back to one in practice.
While h-card is a specific type of microformat, in practice most instances of it on the wiki are really referring to an object on a webpage that conveys identity. I’d suggest that it’s far easier to look at an h-card as an online version of a business card that contains some basic information about a person (or even a business or other entitiy) online. It has things like their name, their address, their email, their phone number, perhaps a photo, or even other very basic information about them. Each of these pieces of data has its own microformats to indicate to machines what they specifically represent. While some h-cards are human readable (like mine), some could be hidden in a web pages’ header and are meant to be machine readable.
While h-cards can convey data in other use cases, in most IndieWeb instances they’re conveying information about either the owner of a website (and thus found on the site’s homepage), or they’re found on individual posts as indicators of the authorship of the content on that page.
Depending on how they’re nested into a web page, they can have different meanings. As possibly the most common example on a traditional WordPress article post, the main h-card for the page would indicate information about the author of that post. However, these article posts will often contain comments sections at the bottom and each individual comment will have it’s own separate author and author information and thus its own h-card. Because these comments are properly nested, they only indicate the authorship of each particular sub-section of a page.
For most IndieWeb use, having an h-card on your homepage tells parsers (code run by other computers) who you are and some basic information about yourself. Generally this extends to your name, your avatar, and your homepage URL.
In your case Aaron, when you’ve generally been sending me webmentions from your primary website (readwriterespond.com), I’ve often been missing your avatar in your comments because you didn’t have an h-card available on them. (I typically remedy this on my own website by hand because I’ve been able to guess the email address/”key” you use for your Gravatar account which then automatically fills in that missing data for me on those comments.)
In the particular case here, for your reply you’ll notice in looking at the source for the page with your response that your ZenPress theme smartly and kindly includes an h-card for you automatically. Here’s what it looks like in code:
You’ll see that it includes (and I’ve highlighted them in red with the relevant microformats classes) your name, your website URL, and it also pulls in your Gravatar avatar using the WordPress back end, since you’ve provided your WordPress installation this data. This is the benefit of a smartly built and designed theme! Thus it would seem that for your “Collect” site, you needn’t worry about an h-card because your theme is already handling the details for you to a great extent. Ideally all themes would do this using standard data fields within a WordPress install. But until then…
Anticipating your next question, what about readwriterespond.com? There, your theme isn’t doing this work for you, so you’ll need to do it yourself. The easiest way to pull this off quickly is to use the IndieWeb Plugin for WordPress. The plugin adds a bunch of additional fields to the page under the “Users” menu located at /wp-admin/profile.php within your admin UI. By filling them in you’re providing the details you’d usually add to an h-card or for rel=”me” uses. The IndieWeb plugin then also makes an h-card widget available at /wp-admin/widgets.php. You can drag and drop it to any of the available pieces of your theme which often include sidebars, footers, and sometimes headers.
The widget does a relatively good job, but some will want more control over what and how things are presented and designed. For those, another option is to create your own HTML-based widget and put the code/data for your h-card into it. This is essentially what you’ve seen on my homepage at boffosocko.com. While mine is entirely handcoded, it may be easier for most to use the microformats website which has a fill-in-the-blanks h-card generator that will allow one to input all of the data they’d like to display and it will automatically mark all of it up properly so that one can cut and paste the semantic HTML directly into a web page or a widget.
There are a bevy of other options for dropping an h-card into your site which will work. You mentioned doing something via a child-theme and that’s an option as well as any one of dozens of plugins that will allow you to drop arbitrary code into your header and/or footer. (Incidentally a child-theme is an excellent way of doing small customizations of your theme without preventing future (security) updates of your theme from overwriting them. If you’re not using one, I recommend following one of the tutorials on the wiki to create one. I would hope it shouldn’t take you more than an hour to implement based on what I know of your skill level.)
As I think you’ve mentioned, there are a few simple validators that will accept a URL which they can parse to show the h-card data they find. These include:
pin13.net, an mf2 parser which outputs raw parsed JSON
People can use these to see if their h-cards are working as they generally expect them to.
Naturally, there are some additional subtleties in h-cards which are noted on both the IndieWeb wiki and the microformats wiki pages, but most of these aren’t of huge consequence to average users or are experimental features which aren’t widely distributed or supported. If it makes you feel better, I’ll also note that it’s not always the case that experienced theme builders or even WordPress core maintainers will properly use microformats as there are frequently cases where they’re wildly misused, abused, or mistreated in the extreme. We can only do our best I suppose…
Hopefully some of this helps put things into perspective. Now that you’re able to sign into the IndieWeb wiki, I invite you to add or modify parts you feel could be clearer or improved as you use and implement them yourself. Surely doing so will help make things easier for those that follow us both.
I wrote in the morning again with one or two small snippets later in the evening. I focused mostly on the topic of rel=”me” for profile equivalence and identity-consolidation with about 1,882 words.
I added a couple of new chapter ideas that will need to be fleshed out as well–I’m surprised I’m still coming up with outline pieces.
Today: 3,115 words
Total: 6,532 words
At the end of NaNoWriMo day 1, I’ve added 2,859 words, most of them written in the early morning. A chunk is in the introduction, but the biggest part includes a relatively solid 1,800 words on the topic of microformats.
The power company decided to turn the power off at the home office today, so I had to migrate over to the local Starbucks for an impromptu write-in.
It’s probably going to take me a few weeks of heaving editing when the whole thing is said and done, but overall it felt like a terrifically productive first day. I am managing to get a bit of light editing done as I go through, particularly to try and make sure I don’t miss anything too significant. I’m going to need to spend a few days on screen captures when this is all said and done.
The best part is that even with a short section of code, the whole file compiled on the second run! And this was without putting any real effort into it as I was writing.
Hopefully in the coming week, based on output versus the scope of the outline I’ve set, I’ll have a better idea about how much of the book I’ll be able to finish within the month. I’m presently a tad concerned that it’ll take a few additional weeks to properly cover all the introductory topics I want to touch upon.
I keep having to remind myself of the likely technical level of the audience, but I feel like I’m keeping it simple enough to be clear while hopefully encouraging people to want to learn more about eventually learning to write some code themselves when they’re done reading and working through the book.
I’m happy that it feels like it’s almost writing itself, but the couple of dozen sites I’ve built in the past few years and a relatively solid outline are helping a lot.
Today: 2,859 words
Total: 3,417 words
Syndicated copies to:
I’m not sure what’s changed recently but I went from a few spam comments on my website every week to hundreds a day.
Now that I have a larger and more diverse set of post types, it’s become more entertaining to read the incongruous spam posts about how brilliant and insightful I am when I’ve just posted a simple checkin.
Spammers are going to have to start using microformats parsers to know which post types to properly add their spam to in the future.
We tend to have a love/hate relationship with social networks. The ability to interact with friends, colleagues, and even celebrities is wonderful, but the lack of control over privacy or content algorithms is troubling. A better way lies ahead, where you aren't tied to large social networks and where you can own your own data.
Recorded at Atlanta Connect.Tech 2017 on 9/21/2017
A few weeks back Keith gave a great non-platform specific overview to some of the moving pieces of the IndieWeb at Connect.Tech 2017 in Atlanta. I wish I could have been there in person, but glad that it was archived on video for posterity.
Somehow I managed to get a mention in his talk as did our friend Jeremy Cherfas.