doc/todo/comments.mdwn

   1 # Known issues with the [[plugins/comments]] plugin
   2
   3 ## Unimplemented
   4
   5 * Instead of just a link to add a comment, it could have a form to enter
   6   the title, similar to the form for adding a new blog post.
   7
   8   > I'm not sure this is so useful? On Livejournal titles are allowed on
   9   > comments, but very rarely used (and indeed usually not very useful);
  10   > it's hard enough to get some people to title their blog posts :-)
  11   > --[[smcv]]
  12
  13 ## Won't fix
  14
  15 * Because IkiWiki generates static HTML, we can't have a form inlined in
  16   page.tmpl where the user fills in an entire comment and can submit it in
  17   a single button-press, without being vulnerable to cross-site request forgery.
  18   So I'll put this in as wontfix. --[[smcv]]
  19
  20 * It would be useful to have a pagespec that always matches all comments on
  21   pages matching a glob. Something like `comment(blog/*)`.
  22   Perhaps postcomment could also be folded into this? Then the pagespec
  23   would match both existing comments, as well as new comments that are
  24   being posted.
  25
  26   > Please see [[plugins/comments/discussion]]. If I've convinced you that
  27   > internal pages are the way forward, then sure, we can do that, because
  28   > people who can comment still won't be able to edit others' comments
  29   > (one of my goals is that commenters can't put words into each other's
  30   > mouths :-) )
  31   >
  32   > On the other hand, if you still want me to switch this plugin to "real"
  33   > pages, or if internal pages might become editable in future, then
  34   > configuring lockedit/anonok so a user X can add comments to blog pages
  35   > would also let X edit/delete comments on blog pages (including those
  36   > written by others) in arbitrary ways, which doesn't seem good. --[[smcv]]
  37
  38   > I had a look at implementing comment() and fell afoul of
  39   > some optimisations that assume only internal() will be used to match
  40   > internal pages. So probably this isn't worth doing. --[[Joey]]
  41
  42 ## Done
  43
  44 * There is some common code cargo-culted from other plugins (notably inline and editpage) which
  45   should probably be shared
  46
  47   > Actually, there's less of this now than there used to be - a lot of simple
  48   > things that were shared have become unshareable as they became more
  49   > complex. --[[smcv]]
  50
  51   > There's still goto. You have a branch for that. --[[Joey]]
  52
  53   >> Now merged --[[smcv]]
  54
  55 * The default template should have a (?) icon next to unauthenticated users (with the IP address
  56   as title) and an OpenID icon next to OpenIDs
  57
  58   > Done in my comments git branch, at least as a mockup (using the (?),
  59   > {x} and {*} smileys for anonymous, OpenID and login respectively).
  60   > --[[smcv]]
  61
  62   >> I've improved this to use independent icons from the wikiicons
  63   >> directory (untested!) --[[smcv]]
  64
  65   >>> The new code produces links like /wikiisons/openid.png, which
  66   >>> fail if ikiwiki is not at the root of the web server. --[[Joey]]
  67
  68   >>>> Sorry, I should have spotted that (the assumption failed on my demo
  69   >>>> site, but the push to that site was when I was on the way out, so I
  70   >>>> didn't have time to investigate). As a note for other ikiwiki hackers,
  71   >>>> I should have used
  72   >>>> `<img src="<TMPL_VAR NAME=BASEURL>wikiicons/openid.png" />`. --[[smcv]]
  73
  74   >>> I got to wondering if the icons are needed. On my comments branch
  75   >>> (not master), I've dropped the icons and info can be seen by hovering
  76   >>> over the author's name. Idea being that you probably don't care how
  77   >>> they authenticated unless something is weird, and in that case you
  78   >>> can hover to check. Does that make sense, should I merge it?
  79   >>> --[[Joey]]
  80
  81   >>>> Yeah, go ahead. I preferred my layout with the author before the
  82   >>>> comment - perhaps that's Livejournal's influence :-) - but I can always
  83   >>>> edit the templates for my own site. As long as the default is something
  84   >>>> reasonable and both layouts are possible, I don't really mind.
  85   >>>> Minimizing the number of "resource" files in the basewiki also seems
  86   >>>> a good goal. --[[smcv]]
  87
  88 * Previews always say "unknown IP address"
  89
  90   > Fixed in my comments branch by commits bc66a00b and 95b3bbbf --[[smcv]]
  91
  92 * The Comments link in the "toolbar" is to `index.html#comments`, not the
  93   desired `./#comments`
  94
  95   > Fixed in my comments branch by commit 0844bd0b; commits 5b1cf21a
  96   > and c42f174e fix another `beautify_urlpath` bug and add a regression test
  97   > --[[smcv]]
  98
  99
 100 * Now that inline has some comments-specific functionality anyway, it would
 101   be good to output `<link rel="comments">` in Atom and the equivalent in RSS.
 102
 103   > Fixed in my comments branch by d0d598e4, 3feebe31, 9e5f504e --[[smcv]]
 104
 105
 106 * Add `COMMENTOPENID`: the authenticated/verified user name, if and only if it was an OpenID
 107
 108   > Done in my comments git branch --[[smcv]]
 109
 110   > Not seeing it there, which branch? --[[Joey]]
 111
 112   >> Bah, git push --all is not the default... 'comments' branch now (I've also rebased it).
 113   >> Sorry, I'm on mobile Internet at the moment... --[[smcv]]
 114
 115   >>> merged by [[Joey]] in commit 0f03af38 --[[smcv]]
 116
 117 * Should the comments be visually set off more from the page above?
 118   Rather than just a horizontal rule, I'm thinking put the comments
 119   in a box like is used for inlined pages.
 120
 121   > I did put them in a box in the CSS... I agree the default template
 122   > could do with visual improvement though. --[[smcv]]
 123
 124   >> I'll consider this solved by [[Joey]]'s changes. --[[smcv]]
 125
 126 * One can use inline to set up a feed of all comments posted to any page.
 127   Using template=comment they are displayed right. Only problem
 128   is there is no indication in that template of what page each comment in the
 129   feed is a comment on. So, if a comment is inlined into a different page,
 130   I think it should show a link back to the page commented on.
 131   (BTW, the rss feed in this situation seems ok; there the link element
 132   points back to the parent page.
 133
 134   > done --[[Joey]]
 135
 136 * One of Joey's commit messages says "Not ideal, it would be nicer to jump to
 137   the actual comment posted, but no anchor is available". In fact there is
 138   an anchor - the `\[[_comment]]` preprocessing wraps the comment in a `<div>`
 139   with id="comment_123" or something. I'll fix this, unless Joey gets there
 140   first. --[[smcv]]
 141
 142   > done --[[Joey]]
 143
 144 * If a spammer posts a comment, it is either impossible or hard to clean
 145   up via the web. Would be nice to have some kind of link on the comment
 146   that allows trusted users to remove it (using the remove plugin of
 147   course).
 148
 149   > Won't the remove plugin refuse to remove internal pages? This would be
 150   > a good feature to have, though. --[[smcv]]
 151
 152   > Here, FWIW, is the first ikiwiki comment spam I've seen:
 153   > <http://waldeneffect.org/blog/Snake_bite_information/#blog/Snake_bite_information/comment_1>
 154   > So that took about 10 days...
 155   > --[[Joey]]
 156
 157   >> Implemented in my 'comments' branch, please review. It turns out
 158   >> [[plugins/remove]] is happy to remove internal pages, so it was quite
 159   >> easy to do. --[[smcv]]
 160
 161   >>> done --[[Joey]]