Webmentions work log 20200117

I hadn’t taken a close look at the IndieWeb comments documentation when I marked up the latest version of comments for this site last week. Today I’m going to follow some of the advice Chris had and stare closer at some prior art.

My first objective is to remove all of the unnecessary classes added to comments by WordPress through comment_class(). To aid in helpful front-end styling, things like odd, even, bypostauthor, and a handful of others are automatically added. I’m doing anything fancy, so I removed pretty much everything and went with a default of class="u-comment h-cite".

Much of the markup around this has things like u-like and u-url and h-cite and I knew there had to be some reasoning, but hadn’t bothered to actually dig in to what it all means. Today I found the documentation for microformat prefixes and everything makes a lot more sense. Go figure.

This list is mostly a reproduction of the one on that page.

  • h- for root class names like h-entry or h-cite
  • u- for URL class names like u-url. This makes the least immediate sense to me because I’m putting things like u-like and u-mention at the <article> level rather the URLs it wraps, though that might be the intention—this container has URLs.
  • dt- for datetime properties, which I use on the <time> element.
  • p- for plain text.
  • e- for element tree properties, or basically: contains HTML.

I’m happy I spent some time actually staring at this. I’ve been “familiar” in the sense that I’ve used the markup for years, but I haven’t paid close enough attention to things like p- and e- prefixes.

My initial version of comments had the comment text wrapped in a .comment-content container. I first switched that with .p-content today before reading the prefix spec. Because I made the decision to add paragraph markup to webmention content and allow things like URLs, I decided .e-content would be the most accurate fit and switched things again.

I then noticed a comment by Tantek on the IndieWeb comments page saying that .h-entry is probably better for comments written on the actual site while .h-cite is best for comments that have a canonical location elsewhere. I went ahead and added a detection for “standard” comments and injected .h-entry for those.

WordPress’s comment type detection is um, yeah.

The comment_type column can be empty, “pingback”, or “trackback” by default. I think this column alone is probably the most annoying thing about even starting with comment types. I left a comment on the associated ticket along those lines.

For now I assume comments that have no comment_type and have a meta key of protocol with the value webmention as added by the webmention plugin are in fact webmentions. Those use .h-cite and other comments with an empty comment_type use .h-entry.

Things are looking a bit cleaner in the source now, or at least making a bit more sense. I’m going to ship that and head over to watch some basketball and stew on why college athletics don’t have URLs to individual events. 🙄

I’ll plan on creating a post type this weekend that I can use for dedicated replies and likes. Sounds like a party. 🎉

Webmentions work log 20200115

Tonight is Pullman’s first Homebrew Website Club and I’m going to use the allocated hacking time to figure out what might be misfiring in the Webmention plugin’s always approve feature.

Side note: It feels weird typing “Webmention” rather than “webmention”. I think I’m going to use the lowercase version from now on unless I feel like being official about something.

The first hurdle I’ve run into is making two local sites communicate with each other in WordPress. I haven’t had to do this in a while, so my config is a little out of whack.

The most obvious issue is SSL verification. WordPress by default verifies SSL certificates when using things like wp_remote_get(). I have jeremyfelt.test and letsmakeplugins.test setup locally through Valet and both have self-signed certificates that WordPress doesn’t handle.

add_filter( 'https_ssl_verify', '__return_false' );

I added a filter in an mu-plugin to ignore SSL verification on the local sites.

The next hurdle is that WordPress uses gethostbyname() in wp_http_validate_url() to find the IP address of the domain and make sure it isn’t, which in this case… it is!

add_filter( 'http_request_host_is_external', '__return_true' );

I added another filter in an mu-plugin to ignore this validation so that I can do all kinds of non-secure things in my local environment. Exciting!

To make sure things were operating as expected, I followed Aaron’s guide to sending manual webmentions. Sometimes using curl is a lot nicer than working through PHP as a way to see what’s really happening. I started an Xdebug session in my editor and watched for incoming webmention requests.

When the webmention endpoint receives a new webmention, it applies a webmention_comment_data filter to process all of the comment data through a handful of things. One of these things is the endpoint’s auto_approve() method, which compares the comment data against the list of auto-allowed domains. Once all this is complete, it creates the new comment with wp_new_comment()—I’m not familiar enough with the reasoning or differences, but it’s possible that wp_insert_comment() could work here as an alternative. I’ll save that for later.

Anyhow. wp_new_comment() sanitizes things so that they look right before comment insertion. It also does the following:

$commentdata['comment_approved'] = wp_allow_comment( $commentdata, $avoid_die );

So whether the comment is already marked as approved (it was) or not, it is run through an extra handful of checks via wp_allow_comment(), including: check_comment().

In check_comment(), WordPress looks at the current comment_moderation option value and if it is set to 1 to enable comment moderation, then false is immediately returned whether or not the comment data was already marked as approved.

There’s another opportunity to filter this value, and I think it’s probably safe to do so.

$approved = apply_filters( 'pre_comment_approved', $approved, $commentdata );

By hooking into the pre_comment_approved filter, we can check to see if the comment type is a webmention and if it was originally set with an approved status. If so, then we can tell wp_allow_comment() to return true and everything works as intended.

add_filter( 'pre_comment_approved', 'jf_check_comment', 10, 2 ); function jf_check_comment( $approved, $commentdata ) { if ( 'webmention' !== $commentdata['comment_type'] ) { return $approved; } if ( 1 === $commentdata['comment_approved'] ) { return 1; } return $approved; }

Aside: I noticed that the documentation for the $approved parameter does not mention that trash is one of the possible values. I opened up a new trac ticket and assigned as a good first bug.

I tested this out as an mu-plugin and tried with my local domains both on and off the allowed domain list and things seem to be working as I expect. I turned this into a pull request to see if everyone else expects the same. 🙂

I’m feeling good about this. It’s at least closer to a solution than I was the other day. I also have a working local development environment for playing with webmentions, which will make future progress even smoother.

I’ll toss the filter into my custom plugin so that I can use it right away. This also clears out one of my to-dos from the last work log. I’ll probably work on a replies post type next because that seems like the next most fun. 🎉

Webmentions work log 20200113

Why not, right?

I shipped a great bug yesterday. A big thanks to Chris Aldrich for catching that and sending me a DM today to let me know.

With all my cleverness around separating comment types for display below posts, I forgot to check for cases where there was some kind of Webmention, but no regular or reply comments. That resulted in an empty array being passed to the comment__in argument for get_comments(), which then resulted in every single comment! A conversation, indeed.

In the process of fixing that, I also decided to only show each section—Likes, Mentions, etc…—if that section had at least one action. This makes more sense to me than empty headings. I also added “bookmark” as an accepted type.

There are a handful of other types left via the Semantic Linkbacks plugin and I should probably decide how to manage them.

I kind of like the idea of “read” being something I see in the WordPress dashboard, but not on the front-end. I made that the case for now along with all of the RSVP, invited, watch, follow, listen, tag, and repost actions. I’ll revisit those in the future if I think of something fun to do with them. For now, I’ll still get them in my dashboard.

The idea of “favorite” has become synonymous with “like” for me when I think about it in the context of social networks. I’m going to mirror those for now and continue to think about differences. I could almost see doing the same thing with “bookmark”, but I’ll keep them separate for the time being.

Now that I’ve adjusted what reactions show up, the get_comments_number() count is not to be trusted. Instead of displaying the number of reactions, I decided to remove the count entirely. For now, I’ll leave the “16 comments” thing alone on archive views just to confuse everyone.

At some point during the day, I was hoping for custom comment statuses in WordPress as a way to separate public and private comments in some kind of workflow. There’s an open trac ticket that’s had some traction in the past and I left some feedback. I was also happy to see a bit of recent traffic on the custom comment types ticket. I’m not sure how I want to chime in yet, but I think they would be very useful.

There is a part of me that things comments need to be approached entirely different. The first thing I would consider doing is creating a wp_comment_author table that tracks unique authors in some way. I’ve only thought through the good parts of that and not the bad, so it may be a ridiculous idea. But I would like to do things like “mark author as spam” and have that combination of name/email/website never appear again. To do that in the current data structure, you’d have to store data in strange ways to try and match things when a new comment comes in.

I’ve been working on a ridiculous plugin, the Self Sustaining Spam Stopper, to see if every day spam blocking is possible without the use of a centralized service and without having to spend a lot of time. It’s already catching most spam, though some tooling around marking words, phrases, and paragraphs as “always spam” from the WordPress admin will be much more interesting.

Things to dig into next:

  • All of these actions are great in the Semantic Linkbacks plugin, but I’ve completely lost track of where they’re standardized. I thought I remembered reading the Webmention spec the other day and not seeing them there. I need to investigate a little bit more and see how they’re created and if there are more specific intentions.
  • I’m not completely sure yet, but I don’t think the “approve & whitelist” option via the Webmention plugin is working for me. I’m still finding myself approving things received from the allowed list of domains. I need to verify / troubleshoot this.
  • Propose that “approve & whitelist” be changed to something like “approve & allowlist” or “always allow”.
  • I think I’d like a “replies” post type I can use to reply to comments on other peoples’ sites. I want to keep my main feed as standard posts without generating a kind of firehose.
  • I may extend on that to my own “likes” so that I can notify people when I like their posts.
  • And I want to make sure I have a clever way of RSVPing to things. I’m headed to the IndieWeb Summit in June and sending an RSVP from this site will be fun. I’m not even linking to it yet just in case it accidentally handles the RSVP for me. 😂

Working through displaying Webmentions

Now that this site supports Webmentions, I’ve been having some fun digging into how I’d like them to be presented.

The theme I’m using is very bare-bones. I created it using Underscores a couple years ago when I decided I had lost touch with the code I was using and for some reason wanted to get back in touch? I don’t know, but I like it.

I created a plugin specifically for my adjustments to the IndieWeb, Webmention, and Semantic Linkbacks plugins. There are a couple scripts and styles I decided I didn’t need as well as a custom comment walker I decided to remove.

At the same time, I created another plugin specifically for adjustments to WordPress. I removed all default emoji handling to see if things would display better in feed readers and adjusted some of the markup output by default—sorry, Windows Live Writer.

Back to comments.

Before I started, the theme’s comment template output everything stored in the comments table as if it was a comment. This makes sense because WordPress doesn’t have a complete idea of “custom comment types”, so it treats them all the same.

The first thing I did was break the query for all comments into comment types so that I could display them in separate sections. WordPress has a function that should do this, separate_comments(), but it is hard coded to support only comment, trackback, pingback, and pings. I have my eye on proposing a filter there, but I’m guessing there are wider concerns with comment types that need to be addressed at the same time.

I’ll revisit that code in the near future. I was just winging it today and never actually went back to review some of those decisions. 🙂

I’m starting with a section for “Likes”, a section for “Mentions”, and a section for “Replies”. Once I get more familiar with other actions and how I see them being used, I’ll likely mix things up a little more.

For Likes and Mentions, I decided to keep things simple and display the avatar, name, action, and date. This displays a bit more than a facepile, but less than a full comment.

It’s been interesting seeing what data actually comes along with a Like or a Mention—sometimes it’s the full post—and it’d be fun to figure out the right way to display that in the future. I could see manually editing some mentions and displaying them differently so that the context is displayed. I envision something like the first 100 characters before and after the actual mention itself.

I removed support for comment navigation, as it’s something I don’t want to deal with right now and I have the option to paginate comments turned off in WordPress.

I was low-key annoyed that wp_list_comments() only supported a style of ol or li, but then went further to the comment walker and saw div was also a supported option. I created a new trac ticket for that and tagged it as a good first bug for anyone who may want to contribute.

My next annoyance is that comment author names are wrapped with <b> and so here I am deciding that of course I should add a custom walker. Exciting!

Of course now I’ve screwed this all up somehow and the reply links aren’t working.

Ahhh, I see! I tried to shrink the amount of markup used around each comment, but the default reply script used in WordPress expects a bit more structure. Added that back for now.

I’ve temporarily adjusted the “Reply” text below each comment to “Reply to {comment author name}”. I think I’d like to adjust this even more so that on nested comments, it includes everyone’s name. Something like “Reply to Jeremy Felt, Alice, and Bob” on a thread in which all have participated would be cool. Part of me wants to shorten that to first names only, though that starts to make assumptions.

One quirk now that I have this all in place is that I’ve replied to “mentions” in the past, which are now displayed in their own area of the page. These replies are now displayed outside of that context. I’m guessing this won’t be an issue in the future, though if I ever do want to reply to a mention, it’d be cool if there was a way to convert the mention into a reply for purposes of display. I’ll think some more on that.

Almost there. Time for another bad decision.

It looks like some multi-paragraph Webmentions are coming in or being stored without paragraph tags. Rather than dive into really testing that, I took the lazy way out and replaced single line breaks with double line breaks so that wpautop() can add paragraphs as intended. This seems to have worked, but I’m sure I’ll run into an edge case at some point.

Okay! Theme deployed. Deployments setup for the new plugins. All is right.

Version 0.0.2 of a new vibe for Webmentions is live on the site. 🕺🏻