## 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.
> 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 `<link rel="comments">` 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
>>>> 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 `<link rel="comments">` 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
* 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 <div>
+ an anchor - the `\[[_comment]]` preprocessing wraps the comment in a `<div>`
with id="comment_123" or something. I'll fix this, unless Joey gets there
first. --[[smcv]]
> done --[[Joey]]
+
+* 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:
+ > <http://waldeneffect.org/blog/Snake_bite_information/#blog/Snake_bite_information/comment_1>
+ > 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]]
+
+ >>> done --[[Joey]]