Jeremy Felt

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. 🎉

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 127.0.0.1, 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. 🎉

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. 😂