X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/92b48bab99e04e7c041434e106179822bd2b1e88..81b87d41fb2efb5d5e1b365fcde7d5e2a2f7ce91:/doc/todo/comments.mdwn diff --git a/doc/todo/comments.mdwn b/doc/todo/comments.mdwn index 50fd89682..e8698f721 100644 --- a/doc/todo/comments.mdwn +++ b/doc/todo/comments.mdwn @@ -1,4 +1,33 @@ -Known issues with the [[plugins/comments]] plugin: +# Known issues with the [[plugins/comments]] plugin + +## Unimplemented + +* Instead of just a link to add a comment, it could have a form to enter + the title, similar to the form for adding a new blog post. + + > I'm not sure this is so useful? On Livejournal titles are allowed on + > comments, but very rarely used (and indeed usually not very useful); + > it's hard enough to get some people to title their blog posts :-) + > --[[smcv]] + +## Patches pending merge + +* If a spammer posts a comment, it is either impossible or hard to clean + up via the web. Would be nice to have some kind of link on the comment + that allows trusted users to remove it (using the remove plugin of + course). + + > Won't the remove plugin refuse to remove internal pages? This would be + > a good feature to have, though. --[[smcv]] + + > Here, FWIW, is the first ikiwiki comment spam I've seen: + > + > So that took about 10 days... + > --[[Joey]] + + >> Implemented in my 'comments' branch, please review. It turns out + >> [[plugins/remove]] is happy to remove internal pages, so it was quite + >> easy to do. --[[smcv]] * There is some common code cargo-culted from other plugins (notably inline and editpage) which should probably be shared @@ -7,16 +36,33 @@ Known issues with the [[plugins/comments]] plugin: > things that were shared have become unshareable as they became more > complex. --[[smcv]] -* Previews always say "unknown IP address" + > There's still goto. You have a branch for that. --[[Joey]] -* Add `COMMENTOPENID`: the authenticated/verified user name, if and only if it was an OpenID +## Won't fix - > Done in my comments git branch --[[smcv]] +* It would be useful to have a pagespec that always matches all comments on + pages matching a glob. Something like `comment(blog/*)`. + Perhaps postcomment could also be folded into this? Then the pagespec + would match both existing comments, as well as new comments that are + being posted. - > Not seeing it there, which branch? --[[Joey]] + > Please see [[plugins/comments/discussion]]. If I've convinced you that + > internal pages are the way forward, then sure, we can do that, because + > people who can comment still won't be able to edit others' comments + > (one of my goals is that commenters can't put words into each other's + > mouths :-) ) + > + > On the other hand, if you still want me to switch this plugin to "real" + > pages, or if internal pages might become editable in future, then + > configuring lockedit/anonok so a user X can add comments to blog pages + > would also let X edit/delete comments on blog pages (including those + > written by others) in arbitrary ways, which doesn't seem good. --[[smcv]] - >> Bah, git push --all is not the default... 'comments' branch now (I've also rebased it). - >> Sorry, I'm on mobile Internet at the moment... --[[smcv]] + > I had a look at implementing comment() and fell afoul of + > some optimisations that assume only internal() will be used to match + > internal pages. So probably this isn't worth doing. --[[Joey]] + +## Done * The default template should have a (?) icon next to unauthenticated users (with the IP address as title) and an OpenID icon next to OpenIDs @@ -28,6 +74,57 @@ Known issues with the [[plugins/comments]] plugin: >> I've improved this to use independent icons from the wikiicons >> directory (untested!) --[[smcv]] + >>> The new code produces links like /wikiisons/openid.png, which + >>> fail if ikiwiki is not at the root of the web server. --[[Joey]] + + >>>> Sorry, I should have spotted that (the assumption failed on my demo + >>>> site, but the push to that site was when I was on the way out, so I + >>>> didn't have time to investigate). As a note for other ikiwiki hackers, + >>>> I should have used + >>>> ``. --[[smcv]] + + >>> I got to wondering if the icons are needed. On my comments branch + >>> (not master), I've dropped the icons and info can be seen by hovering + >>> over the author's name. Idea being that you probably don't care how + >>> they authenticated unless something is weird, and in that case you + >>> can hover to check. Does that make sense, should I merge it? + >>> --[[Joey]] + + >>>> Yeah, go ahead. I preferred my layout with the author before the + >>>> comment - perhaps that's Livejournal's influence :-) - but I can always + >>>> edit the templates for my own site. As long as the default is something + >>>> reasonable and both layouts are possible, I don't really mind. + >>>> Minimizing the number of "resource" files in the basewiki also seems + >>>> a good goal. --[[smcv]] + +* Previews always say "unknown IP address" + + > Fixed in my comments branch by commits bc66a00b and 95b3bbbf --[[smcv]] + +* The Comments link in the "toolbar" is to `index.html#comments`, not the + desired `./#comments` + + > Fixed in my comments branch by commit 0844bd0b; commits 5b1cf21a + > and c42f174e fix another `beautify_urlpath` bug and add a regression test + > --[[smcv]] + +* Now that inline has some comments-specific functionality anyway, it would + be good to output `` in Atom and the equivalent in RSS. + + > Fixed in my comments branch by d0d598e4, 3feebe31, 9e5f504e --[[smcv]] + + +* Add `COMMENTOPENID`: the authenticated/verified user name, if and only if it was an OpenID + + > Done in my comments git branch --[[smcv]] + + > Not seeing it there, which branch? --[[Joey]] + + >> Bah, git push --all is not the default... 'comments' branch now (I've also rebased it). + >> Sorry, I'm on mobile Internet at the moment... --[[smcv]] + + >>> merged by [[Joey]] in commit 0f03af38 --[[smcv]] + * Should the comments be visually set off more from the page above? Rather than just a horizontal rule, I'm thinking put the comments in a box like is used for inlined pages. @@ -35,21 +132,7 @@ Known issues with the [[plugins/comments]] plugin: > I did put them in a box in the CSS... I agree the default template > could do with visual improvement though. --[[smcv]] -* Instead of just a link to add a comment, it could have a form to enter - the title, similar to the form for adding a new blog post. - - > I'm not sure this is so useful? On Livejournal titles are allowed on - > comments, but very rarely used (and indeed usually not very useful); - > it's hard enough to get some people to title their blog posts :-) - > --[[smcv]] - -* If a spammer posts a comment, it is either impossible or hard to clean - up via the web. Would be nice to have some kind of link on the comment - that allows trusted users to remove it (using the remove plugin of - course). - - > Won't the remove plugin refuse to remove internal pages? This would be - > a good feature to have, though. --[[smcv]] + >> I'll consider this solved by [[Joey]]'s changes. --[[smcv]] * One can use inline to set up a feed of all comments posted to any page. Using template=comment they are displayed right. Only problem @@ -59,37 +142,12 @@ Known issues with the [[plugins/comments]] plugin: (BTW, the rss feed in this situation seems ok; there the link element points back to the parent page. - > done --[[Joey]] - -* It would be useful to have a pagespec that always matches all comments on - pages matching a glob. Something like `comment(blog/*)`. - Perhaps postcomment could also be folded into this? Then the pagespec - would match both existing comments, as well as new comments that are - being posted. - - > Please see [[plugins/comments/discussion]]. If I've convinced you that - > internal pages are the way forward, then sure, we can do that, because - > people who can comment still won't be able to edit others' comments - > (one of my goals is that commenters can't put words into each other's - > mouths :-) ) - > - > On the other hand, if you still want me to switch this plugin to "real" - > pages, or if internal pages might become editable in future, then - > configuring lockedit/anonok so a user X can add comments to blog pages - > would also let X edit/delete comments on blog pages (including those - > written by others) in arbitrary ways, which doesn't seem good. --[[smcv]] - - > I had a look at implementing comment() and fell afoul of - > some optimisations that assume only internal() will be used to match - > internal pages. So probably this isn't worth doing. --[[Joey]] + > done --[[Joey]] * One of Joey's commit messages says "Not ideal, it would be nicer to jump to the actual comment posted, but no anchor is available". In fact there is - an anchor - the `\[[_comment]]` preprocessing wraps the comment in a
+ an anchor - the `\[[_comment]]` preprocessing wraps the comment in a `
` with id="comment_123" or something. I'll fix this, unless Joey gets there first. --[[smcv]] - > done --[[Joey]] - -* Now that inline has some comments-specific functionality anyway, it would - be good to output '' in Atom and the equivalent in RSS. + > done --[[Joey]]