On my way to Manila, I stopped off in Portland, Oregon for the annual Indieweb Summit. It was actually the other way around. I was going to Portland, and it was suggested I should just keep going. This Summit was better than last years, which was a great event. Hosted by Mozilla Portland,

I got to attend the Leadership Summit, for community leaders(apparently I am one), where we agreed we needed to meet more often to organize our efforts…and got some Indieweb stickers. Despite my misgivings, we now have an Indieweb WordPress chat room as part of the Indieweb suite of chat rooms. So far, it has kept the WordPress stuff in one place.

My attachment to WordPress and involvement in the community seems to have made me an ‘authority’ on the current state of how Indieweb concepts apply to WordPress(which, by the way, runs this site). And we have accomplished a lot this month…with many Indieweb plugins seeing updates.

I always feel inspired to work on my Indieweb projects after meeting inspiring people, like the great Ryan Barrett, who maintains Bridgy, the software that translates likes and comments on Facebook and Twitter into comments on my site. It’s fortunate that I have nothing to do but eat, sleep, and work in Manila, because it has given me a chance to continue that inspiration.

Here’s hoping for more Indiewebcamps. Anyone interested in one in New York?

IndiewebPress: Users

This is the one of a series of brainstorming posts I am putting out about how major functional Core changes to WordPress could result in an improved experience for those interested in pursuing Indieweb philosophies in WordPress.

In the Indieweb world, your domain is your identity. This would suggest that most WordPress sites should only have one user…representing the identity of the site. Users, however, represent roles and responsibilities within the system, not necessarily content creators.

In an update to the ‘official’ Indieweb plugin, I, with some encouragement, added the idea of designating a specific user as the ‘identity’ of the site…assuming there was one.  But let’s expand that idea a bit. We have user metadata, we have the ability to define new roles and capabilities. So, what can we do with this but create new possibilities? We can better work what a role is, and add additional properties and behavior to improve the system.

There is a setting for an admin email, for which the suggestion to expand outward has been proposed for 8 years in this vein. This should be a property of any administrative account.

I have an idea I’ve long wanted to implement. It is based on a feature used by Postmatic. People who subscribed to the email service they provided would end up as users on your site. I’d like to see enhancements to the user profile. When trying to add other site profiles to user metadata, I discovered that this being left to the plugins has resulted in a complete lack of consistency.

There needs to be a consistent structure to add data to support URLs on specific other types of sites( for example, Twitter), or every plugin is going to have to retread this. This is the trouble we have with all metadata unfortunately.

That idea of using the user table for outside visitors has a lot of good potential. Commenters could create a profile on your site that could be imported from elsewhere…namely your own website. There is a certain level of trust there, because you would be displaying images and text about a person from another site…however, that is what gravatar does. Why not allow people to do it from their own site?

Gravatar itself is something that WordPress wouldn’t have put in today….a reliance on an outside service. The local avatar trac ticket is also a rather old request. It is time to look at avatars in general…to build a robust local system that is enhanced by gravatar…gravatar should not be that system. We can add in modern themeable profiles for users, as opposed to just archive pages. We can make a much better system for users.

The whole point of the ‘subscriber’ role in WordPress is for people not part of the blog to have an account they can do something with…follow the site, get updates, participate in comments…but this part of WordPress is woefully underused.

IndiewebPress: Connecting Your Site and Mine

This is the one of a series of brainstorming posts I am putting out about how major functional Core changes to WordPress could result in an improved experience for those interested in pursuing Indieweb philosophies in WordPress. This builds on a previous article about improving comments.

In the previous article, I discussed my thoughts on the subject of comments as a structure and what comments could be capable of if that structure was improved. But, when I showed that to several people, the comment was, quite legitimately, that I didn’t explain what could be built on top of that. I had another topic in mind before covering this, but that made me want to document this as well.

Let’s start with webmentions. Webmentions builds on the idea of the two protocols that are built into WordPress: Pingbacks and Trackbacks. Trackbacks have to be discarded from WordPress. There is no verification of them…it is basically letting anyone post something on your site…moderated or not. The other site tells you they’ve linked to you(even if they haven’t) and what to make it look like on your site. And because of this…while I’ve tried to think of ways to save it, I think it needs to, over time, go on the chopping block.

Pingbacks, despite actually verifying that a URL links to where it says it does, currently don’t do anything else interesting in WordPress. The appearance and usage has stagnated. It could be improved on the display side, and I’ve tried to get interest in that…but I’m wondering as we move forward…considering the legacy design issues, the bad feelings, what I would like to see happen with comments, etc…if we should just let Pingbacks stay where they are with only some performance and other minor refinements, and develop Webmentions.

Webmentions have advantages. They support update and delete functionality if the source changes in the future. They have a standard recommended by the W3C(which the previously implemented protocols do not), as well as a dedicated community who has implemented them on their sites.

What was never realized in potential by previous protocols, but Indieweb community members are implementing is the magic. Someone links to your site with a post on their site. They use webmention to tell you that they linked to you. But what your site does at that point is controlled by you. You can parse their post and display it as a comment, or based on how their page is marked up, derive other meaning and relationships from it. You can just use it in a simple counter or stat display to note how many people linked to you. There have been some fun discussions of using it to share bibliographic data.

If you had to pick one thing, webmention is the key building block on which the Indieweb is built. By itself, it requires no trust on the part of the receiver. There is a developing extension called Vouch which allows the sender to provide proof that someone the receiver knows trusts them. And, moderation aside, presentation of this is wholly left to the receiving site. Back to the comment point in the previous article on this, one of the functional WordPress problems is that there is no way for a plugin to declare a custom comment type and tell the theme how to display it or whether to display it at all. You effectively have to hijack the comment template to do this, instead of working with it.

To the point of something like annotations, the idea of fragmentions which allow a specific part of a post to be referenced more effectively…WordPress doesn’t support inline comments of any type or marginalia. There is a trac ticket to implement the W3C’s work on annotations, but WordPress has nothing to allow for displaying this sort of work.

There is a current Webmentions plugin for WordPress that is under continual development. It was created by Matthias Pfefferle, and I have been a regular contributor to it. It handles the functional plumbing of webmentions, but not the improved display aspect. That has been delegated by its creator to a second plugin, Semantic Linkbacks, which attempts to offer the parsing of external sites and deriving information like author(name and photo), etc.

It is worth trying the combination of these. But there is more that can be done here as well. Cover more types, improve the ability to store commenter’s data, etc.

 

IndiewebPress: Improving Comments

This is the one of a series of brainstorming posts I am putting out about how major functional Core changes to WordPress could result in an improved experience for those interested in pursuing Indieweb philosophies in WordPress.

Comments in WordPress were originally thought of as a way for visitors to a site to have discussions on the site. I’m going to refer to the traditional comment idea as ‘local comments‘. This is where someone fills out a comment form on a post, which adds a comment to the page, either with or without moderation.

Also built-in to WordPress are pingbacks and trackbacks. These are where another site notifies of a link to the page and this is displayed as a comment on the page. Pingbacks and trackbacks have their issues, and admittedly, WordPress, except for some minor tweaks, has left the presentation and features of these mostly unchanged, save for some security efforts. Therefore, it has become common to disable them. Webmentions are a replacement for the older pingback and trackback protocols.

There are also custom comment types used for things like logs, receipts(See mention in Trac Ticket which notes that popular plugin Easy Digital Downloads does this), etc. which are not part of the general vision of what a comment is. Of course, custom post types aren’t all traditional posts either.

Meanwhile, other areas of WordPress are getting functions to register functionality. 1n December of 2015, a ticket was opened for Custom Comment Types. This would, in theory, mirror the functionality of Custom Post Types, where a registration function would declare the functionality and behavior of a comment type.

But there are issues here beyond what is identified in the ticket. How will a theme know how to display the new comment type? There needs to be a way for this to be specified by the registration and overridden by themes that know what that comment type is. There is a possibility there may be some breaking changes in that design.

Meanwhile, comments cannot be referenced uniquely and distinctly. There is another ticket equally old, proposing comment permalinks. Whether this is just to find the comment on whatever page it is on, or allowing a comment template that emphasizes the comment by itself, it is an aspect of the comment system that needs replacing.

That addresses the structure, but not what could be done with it. Not only would this allow for webmentions as a medium to create comments(webmentions being the successor to pingbacks), but support for responses that are popularly used today such as like, emoji, annotation, etc. The Semantic Linkbacks plugin tries to create these relationships in comment meta, but it is not as robust as a supported implementation would be.

Annotations and marginalia recently have been of interest in allowing people not to just comment on a post as a whole, but on specific areas of it. This could also be a promising piece of a comment overhaul…supporting this. In my contributions to the Webmentions plugin, I started this by supporting URL fragments(see fragmentions), which would allow for a specific part of the post to be highlighted.

 

My 2017-01-01 Commitment – Location Support Returns

I decided as part of my annual end-of-year Indieweb commitment, to complete an update to the location services on my site. I originally announced location support on this site in April of 2015(See Link). I’ve been working on a rewrite on and off for nearly a year now, and wanted to finally release it.

This post, for example, is set as if it was made at the Empire State Building.

Coming in the future is venue support. A venue is sort of the location equivalent of a bookmark. There are other names for it. It would allow more information about the location, and you would be able to view all posts associated with that location. This leads to what has become common on social media sites…the check-in. I used to store more information about the location in the post, and won’t be doing this anymore.

More to come on location and more, but I’m glad I got a version of this out. Thanks to Chris Aldrich for testing this out.

 

 

Why Microformats

I’ve spent some time on this site commenting on the use of various Indieweb concepts, but I haven’t really touched on Microformats. Microformats just turned 11 years old.

Microformats are human-readable markup that are easily human readable as well as machine readable. They appear as classes attached to HTML elements in webpages. The most popular alternatives to Microformat markup are things like schema.org, RDFa, etc.

The mistake people make is that it is overly technical. The vocabulary of the current iteration of the standard is simple. The below is a simple example. For example, h-card is the vocabulary for marking up people, organizations, and places. The below is a minimal h-card identifying name and associated URL.

<div class="h-card">
<h3 class="p-name">David Shanske</h3>
<a class="u-url" href="https://david.shanske.com">Website></a>
</div>

Then there is h-entry, which is used for individual posts on this site, or any episodic content. It is a equally easy, though like h-card, you can add more elements.

<div class="h-entry">
<time class="dt-published" datetime="2016-06-22T02:34:16-0400">June 22, 2016</time> <p class="e-content">This is my content</p> </div>

And so on. Not only does it identify…what is the content, what is the publish date, etc. in a way a human could realistically read enough to mark it up, it can be parsed and read by a computer. It is easy, if you understand HTML enough to read it, how to mark up the elements.

And then come the advantages. If parsers can read the elements of your site, they can interpret your intent. The community has developed vocabulary to indicate many relevant things, and put out programs, sites, and in my case, WordPress plugins that take this data and turns it into things like: ‘likes’, meaningful comments, event RSVPs, etc.

I’ve been posting articles on adding Microformats to a WordPress site. Once added, the site can be properly parsed, and can be used to do these things. How do I know? My site already does them.

 

 

Why Webmentions in WordPress

I had originally wrote this on January 27th, as part aof an email exchange between myself and the WP Tavern. However, after being told by Jeff Chandler, contributing writer for the site, that he was away and would discuss the matter further in March, I received no further word. After the site posted a somewhat inaccurate article on webmentions on March 18th, I commented to them again that I was disappointed that the article was not checked for accuracy. Again, no response. So I am posting my January 27th article and withdrawing from WP Tavern’s request for exclusivity on any such article due lack of response on their part. The dialogue on Webmentions in WordPress continues.

 

Over the last few years, as the smartphone has become more popular, we’ve moved from being excited about notifications to being worried about notification overload. Companies are hoping to get more data on us so they can tailor their interactions with us. We install analytics on our websites to determine how many visitors we get and what they did on our sites. At its simplest level, a linkback is a way of having a site(the sender) notify another site(the receiver) when it links to it. It sounds like something we would want to know and would have many potential uses.

WordPress has two built in linkback protocols: Trackback and Pingback. To many users, they seem like the appendix of WordPress. People don’t care about them until they are exploited by bad actors. There is a newer protocol, the first linkback protocol to be accepted as a draft specification from the W3C, the main standards organization for the Internet, called Webmention.

Webmention improves upon the previous protocols. It uses an HTTP POST request to send two parameters…the source and target URL. By comparison, trackback, which also uses HTTP, only sends the source URL and does nothing in its WordPress form to verify the trackback is legitimate. Pingback, like webmention, sends both source and target, but it uses XML-RPC as opposed to a POST request. XML-RPC has had some controversy around it as well. There are also several practices that are recommended by the Webmention specification that would make an implementation more robust than the implementations of Trackback and Pingback.

WordPress has a longstanding reputation of commitment to backward compatibility and isn’t going to flick the switch and remove pingback and trackback code from WordPress Core so easily, with or without a replacement.  It makes sense to make improvements to the older protocols concurrently with adopting webmentions, although it would also be a good idea to consider gradually deprecate the older protocols in favor of webmentions. Trackbacks have no source validation built into WordPress as it was not part of the original specification. The pingback code could use some love. However, with some refactoring, new webmention code could be used to update the older pingback/trackback code as well. This would create a better linkback system overall.

Even if webmention is a better delivery system for linkbacks than its predecessors, no one but a developer cares about protocols. People care about what it can do for you. All of the protocols converge in one place. Once you know a site has linked to you, what do you do with that information? That is where the exciting parts come in and where WordPress falls flat.

If one person would like to speak up in favor of the presentation of […]Useless Context. […], I’d love to hear it. The burden of presentation and use in a linkback relationship goes to the receiver and can be infinitely extensible. What WordPress lacks is a good base presentation for people to enhance and some innovative examples from the community of usage. If you can parse a page of HTML, you can come up with richer content and relationships by marking up the elements of a post with Microformats. WordPress already has some microformats embedded in most WordPress sites and supporting in many themes, and there are other efforts that can be made to better improve this side of things. But there are limitless possibilities, for example:

  • Want to reply to a post on WP Tavern on your own site? Send a webmention(or more archaic protocol) to WP Tavern with the URL of your reply. WP Tavern could parse your site and generates an actual comment from it.
  • Why only a reply? What about other types of relationships? Liking a post, for example?
  • Even just simple administrator stats can be interesting and useful.

So, why not do all of this with an API? We have a new one coming into WordPress…and that’s a great thing I’m fully in favor of. But reading content from a website using an API creates a burden on both sides of the relationship. I have to write an API and you have to learn how to use it if you want to interface with my site. Why shouldn’t your website be your API?

If you are interested in trying webmention support, there is a basic plugin for WordPress. There is even a second plugin that uses Microformats2 plus linkbacks to generate richer comments. Both of these can be used to develop the more robust implementation that would be required for WordPress Core. For more information on how people have been using webmentions, visit IndieWebCamp.

 

 

Post Kinds Improvements

For those who have been following my Indieweb activities, I have for a little over a year been developing a WordPress plugin called Post Kinds.  The plugin is based on the built-in Post Formats feature, but focuses on different types of specialized post types or kinds. I figured I would motivate myself by writing out some of the improvements under development.

Picking the right icons to represent the kinds has always been a challenge, because they were part of an icon font. Icon fonts are ‘fake’ fonts that are actually composed of symbols. The latest version of Post Kinds under development switches to SVG. SVG is a text format that defines a complex shape. As it is text, it can be embedded directly in the page. You can compare the two below.

 

newpostkinds
New Post Kind Icons
Old Post Kind Icon Font
Old Post Kind Icon Font

Version 2.3.0

  • Enable the Jam post type. A Jam is used to share a particularly meaningful song you are listening to. distinguished from the existing Listen type, which is a more passive type designed to store songs you have listened to.
  • Support for start and end date, which will be used to enhance activity kinds. This will prepare for support for events, travel, and exercise in a future version. I really want to build travel in soon, but I have a lot to put in before all the pieces come together.
  • Improvements in parsing to bring in better and more consistent data from URLs provided.
  • Help within the plugin. This will be the first version to add built-in help.

This version will not go out until the above, as well as improved presentation(which I’m currently building) are complete. I’ve been working on the presentation rewrite for over a week now, trying to make it a significant improvement over the previous incarnation.

Tim
Time

Trying to Explain the Indieweb

It’s been a while since I’ve updated on some of the work I’ve been doing. A lot of it has been behind the scenes. I’ve been working on improving some of the things I’ve built. Some of the work is rather subtle. For those of you not interested, feel free to skip this.

So, since 2014, I’ve been working toward getting certain building blocks available in WordPress, along with several other people.

  • A webmention is a way to notify another site that you’ve linked to their site. Once you have that notification, there are things you can do with it. Webmentions have been developed as a plugin for WordPress.
  • Linking itself has utility. But by marking up content, the receiving site can take action.
  • Microformats would be the markup you can use to have cross-site commenting and other forms of communication.
  • That would be the purpose of the Post Kinds plugin. It allows posts to be marked up as Likes, Bookmarks, etc. These things could be marked up manually, but some people would prefer a more automated solution.
  • Separately, there are two theme options now that mark up WordPress theme elements with microformats.
  • On the receiving end, the Semantic Linkbacks plugin takes incoming mentions and tries to interpret them….turning them into comments, likes, etc. This would be how you would derive value.
  • Finally, Micropub support. Micropub is a standard to create posts on a site from a third-party client. It means that be it WordPress on the backend, or something else, you can create with the same tools.

There is slow but regular improvements in both the Indieweb in general. Nothing is ever as fast as one would like it to be. But think of what can be done…