Repository navigation
Textpattern's comments system needs rethinking #308
Description
Activity
For (possible) inclusion in later discussions -- Webmentions as an alternative to traditional comments:
https://indieweb.org/Webmention
https://www.w3.org/TR/webmention/
https://github.com/w3c/webmentionI heard about this over the weekend:
Also, this is directly what Drew used as a base for his demo: https://github.com/indieweb/mention-client-php
I’d like to see how this matures first though. The whole thing seemed a bit clunky as a direct comments replacement - having to jump to a social media platform to comment on an article seems a bit counterintuitive. Also listing every like seems valueless.
Reacted by Pete CooperSide note, see makss' work with Modules for the link tags and link admin interface.
It ties the link tags and the admin interface to a single pref: "Links on/off/hidden". Turn it off, no Content->Links panel, no taghandlers for
link*tags. Hide it, no admin panel but link tags still work on the site. Same could be done for Files. Maybe even Images, not sure.No reason this can't be expanded to Comments and tied to our existing "accept comments" pref. So that shuts comments off completely, including tag processing. Hello faster parser.
The trick, however, might be to fire a callback so plugins can still react to an "on" state but replace the core comments system in its entirety so the UI and tags supported are different. Hello webmentions, twitter feed reactions, whatever.
Further bonus trick points: callbacks that allow you to add arbitrary Modules and register associated Tags, with a set of defined storage requirements. Hello custom content types.
Tagging for consideration/completeness before a) it gets lost and b) I close it: #211 - comments panel could/should include preview bloc (for changes to comment).
For more completeness, a forum thread about commenting: https://forum.textpattern.io/viewtopic.php?id=33029.
Note to consider #1341 before I close it.
From Phil a while back:
I’d like to see how this matures first though. The whole thing seemed a bit clunky as a direct comments replacement - having to jump to a social media platform to comment on an article seems a bit counterintuitive. Also listing every like seems valueless.
I'm only now looking at Webmentions out of curiosity, but it seems it has progressed a bit? You can now 'comment' back and forth with someone directly from your own site?
https://aaronparecki.com/2018/06/30/11/your-first-webmention
Not sure how it all works just yet, but if this has become a better way to avoid spam and trolls, by not leaving a web form open to the greater world, that's a strong argument for supplanting 'Web 1.0 comments' with '(Indie)Web 3.0 mentions'?
OK, so I think I get it: say I have the following hCard HTML structure...
<!DOCTYPE html> <meta charset="utf-8"> <title>Webmention HTML</title> <body> <div class="h-entry"> <div class="u-author h-card"> <img class="u-photo" src="https://philwareham.co.uk/me.jpg" width="48" height="48"> <a class="u-url p-name" href="https://philwareham.co.uk/">Phil Wareham</a> </div> <p>in reply to: <a class="u-in-reply-to" href="https://aaronparecki.com/2018/06/30/11/your-first-webmention">@aaronpk</a></p> <div class="e-content"> <p>Trying out this guide to sending webmentions.</p> </div> <p> <a href="https://philwareham.co.uk/reply" class="u-url"> <time class="dt-published" datetime="2019-06-06T13:57:00Z">June 06, 2019</time> </a> </p> <div class="p-category">tag-name</div> </div> </body>
...and I ping that to
https://aaronparecki.com/2018/06/30/11/your-first-webmentionusing (for example) the indieweb PHP library it finds therel="webmention"server endpoint at that page (in this case an external servicehttps://webmention.io/but you could have it built into your web app like Drew demonstrated in Perch) and finally injects my message into a comments section of his page.Is that the basic idea?
Also, this ALA article might help us if we are serious about an implementation: https://alistapart.com/article/webmentions-enabling-better-communication-on-the-internet/
I guess that's it.
Not having a web form limits the communication to only those playing along with the standard, but that's good in my opinion. We live in different times. One look at comments on any news site makes it clear why it's time to progress.
One thing I'm having trouble visualizing, as discussed in the ALA article... If the conversation is going back and forth, do you have to start a new blog post for each reply in that conversation? Each reply is a new 'card' on the same blog article?
Tagging https://forum.textpattern.com/viewtopic.php?id=50927 for completeness.
Quick note while I think about it for streamlining comments. Hardly a new idea, but how about this:
- From the Edit Comment step (and possibly as an action in the Comments list table), add a 'Reply' link.
- This link takes you to the article on the front-end. Bonus points if we can locate the comment form and jump to it. Even more bonus points if we can pre-fill in the name and email address of the logged-in user's account.
- Then, either:
a) Add a single-use token (txp_token table) to the link from the admin-side request so that, on submission of the comment, it automatically bypasses any moderation, injecting the comment directly after preview. OR;
b) (easier) When the comment is submitted, we could check the supplied email address against the txp_users table. If it matches and/or the user is logged in this session, auto-accept the comment if moderation is on. Doing email matching assumes that the person replying uses the same email address in comments as they do to log into Txp. A stretch?
Doing something like this means we get comment replies "for free" without the need to add an admin-side reply mechanism (like the jnm_comments_reply plugin does).
Advantages of a:
- More robust.
- Doesn't rely on the public and Txp email addresses being the same (unless we relax this and allow any comment from any email address to bypass the moderation IF the person commenting is logged in to Txp).
- Works if the comment form doesn't have an email field (does anyone do this?)
Advantages of b:
- Works without hopping to the admin side first. Simply replying with the same email address as your Txp login and/or being logged in is enough to trigger auto-insertion.
- Simpler than (a) as there are no tokens involved that need passing forward through the comment preview step.
Worth considering/refining?
Actually, auto-accepting comments if you're logged in is trivial. See 0eb34de.
This doesn't introduce the 'reply' system (yet). But at least the ride is smoother if moderation is on and you add a public comment while logged in.
Please test.
@bloatware @petecooper Tangential:
is_logged_in()upon which this and other public 'security' features are built, relies on the cookietxp_login_publicwhich is, from a cryptographic viewpoint, utter tits. We should look into hardening this in 4.9.0.In the meantime, can the cookie be forged to fake 'is logged in' and thus bypass comment moderation, or is our reliance on http cookies and the weak md5 user nonce 'good enough' for now?
Doing email matching assumes that the person replying uses the same email address in comments as they do to log into Txp.
I'm probably one of the fringe cases that would frustrate this. It's probably over-obsessive behavior coming out, but I tend to use an account specific email alias for any website that is not my own. However, depending on the site and how the commenting system was set up/secured I might use a different email for people to reply to if using comments. I generally would only want email coming to the account specific website if they are coming from the owners of the website. For example, emails from their support team, invoice, etc. Not potential notifications about chit-chat comments over one some article on the website.
Again - I realize I probably pretty fringe on this though. Just thought I'd chime in to confirm that if there can be a fringe use scenario this will be one. :P
@tecumsehmaverick Yeah, I've avoided this. Thought about it more after I posted, and concluded that matching email address is fraught with assumptions I don't like.
So the current implementation (in 4.8.2) is that if you're logged into Txp's admin side and add a comment on the public side, it automatically gets accepted (moderated) regardless of the credentials you use in the boxes.
Notification still happens (so if you wrote the article, you get a notification email of what you wrote in the comment) but it doesn't hit the moderation queue and skips straight to being visible on the site because you're assumed to be trusted by virtue of having a Txp login and being logged in.
From stefdawson on October 31, 2012 10:25:58
Comments are only half-baked. They should either be stripped out and modularised/pluginised or, at the very least, when the "Accept comments" pref is "no", the Comments panel and all vestiges of comment-related paraphernalia should be hidden from the Admin UI. Consider "Accept comments" off by default: has implications for Donald Swain.
Making it easier for plugins to integrate social media comment systems is a desirable bonus.
Encompasses Issue 25 .
Original issue: http://code.google.com/p/textpattern/issues/detail?id=304