-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]]
+
+## Won't fix
+
+* 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]]
+
+ > 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
> things that were shared have become unshareable as they became more
> complex. --[[smcv]]
-* Previews always say "unknown IP address"
-
-* 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]]
+ > There's still goto. You have a branch for that. --[[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]]
+ >> 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
>>>> 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
+ >>>> I should have used
>>>> `<img src="<TMPL_VAR NAME=BASEURL>wikiicons/openid.png" />`. --[[smcv]]
>>> I got to wondering if the icons are needed. On my comments branch
>>>> 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 `<link rel="comments">` 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.
>> I'll consider this solved by [[Joey]]'s changes. --[[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]]
-
* 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
is there is no indication in that template of what page each comment in the
(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 <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]]
+ > done --[[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.
+* 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]]
sipb-www / ikiwiki.git / blobdiff