X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/2884d20950681fac16390f61da11afe44508f2cd..bfc13b9070981ba3cd73b901af9c29a50ca0114d:/doc/todo/comments.mdwn?ds=sidebyside diff --git a/doc/todo/comments.mdwn b/doc/todo/comments.mdwn index 33d688ab3..7a113bee3 100644 --- a/doc/todo/comments.mdwn +++ b/doc/todo/comments.mdwn @@ -2,8 +2,6 @@ ## Unimplemented -* Previews always say "unknown IP address" - * 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. @@ -12,18 +10,56 @@ > 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 fix - > Won't the remove plugin refuse to remove internal pages? This would be - > a good feature to have, though. --[[smcv]] +* Because IkiWiki generates static HTML, we can't have a form inlined in + page.tmpl where the user fills in an entire comment and can submit it in + a single button-press, without being vulnerable to cross-site request forgery. + So I'll put this in as wontfix. --[[smcv]] -* Now that inline has some comments-specific functionality anyway, it would - be good to output `` in Atom and the equivalent in RSS. + > Surely there's a way around that? + > A web 2.0 way comes to mind: The user clicks on a link + > to open the comment post form. While the nasty web 2.0 javascript :) + > is manipulating the page to add the form to it, it looks at the cookie + > and uses that to insert a sid field. + > + > Or, it could have a mandatory preview page and do the CSRF check then. + > --[[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 + +* There is some common code cargo-culted from other plugins (notably inline and editpage) which + should probably be shared + + > Actually, there's less of this now than there used to be - a lot of simple + > things that were shared have become unshareable as they became more + > complex. --[[smcv]] + + > There's still goto. You have a branch for that. --[[Joey]] -## Patches pending merge + >> Now merged --[[smcv]] * The default template should have a (?) icon next to unauthenticated users (with the IP address as title) and an OpenID icon next to OpenIDs @@ -58,38 +94,23 @@ >>>> Minimizing the number of "resource" files in the basewiki also seems >>>> a good goal. --[[smcv]] -## Won't fix +* Previews always say "unknown IP address" -* There is some common code cargo-culted from other plugins (notably inline and editpage) which - should probably be shared + > Fixed in my comments branch by commits bc66a00b and 95b3bbbf --[[smcv]] - > Actually, there's less of this now than there used to be - a lot of simple - > things that were shared have become unshareable as they became more - > complex. --[[smcv]] +* The Comments link in the "toolbar" is to `index.html#comments`, not the + desired `./#comments` -* 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. + > Fixed in my comments branch by commit 0844bd0b; commits 5b1cf21a + > and c42f174e fix another `beautify_urlpath` bug and add a regression test + > --[[smcv]] - > 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]] +* 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]] -## Done * Add `COMMENTOPENID`: the authenticated/verified user name, if and only if it was an OpenID @@ -123,8 +144,27 @@ * 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