doc/todo/comments.mdwn

   1 Known issues with the [[plugins/comments]] plugin:
   2
   3 * There is some common code cargo-culted from other plugins (notably inline and editpage) which
   4   should probably be shared
   5
   6   > Actually, there's less of this now than there used to be - a lot of simple
   7   > things that were shared have become unshareable as they became more
   8   > complex. --[[smcv]]
   9
  10 * Previews always say "unknown IP address"
  11
  12 * Add `COMMENTOPENID`: the authenticated/verified user name, if and only if it was an OpenID
  13
  14   > Done in my comments git branch --[[smcv]]
  15
  16   > Not seeing it there, which branch? --[[Joey]]
  17
  18   >> Bah, git push --all is not the default... 'comments' branch now (I've also rebased it).
  19   >> Sorry, I'm on mobile Internet at the moment... --[[smcv]]
  20
  21 * The default template should have a (?) icon next to unauthenticated users (with the IP address
  22   as title) and an OpenID icon next to OpenIDs
  23
  24   > Done in my comments git branch, at least as a mockup (using the (?),
  25   > {x} and {*} smileys for anonymous, OpenID and login respectively).
  26   > --[[smcv]]
  27
  28   >> I've improved this to use independent icons from the wikiicons
  29   >> directory (untested!) --[[smcv]]
  30
  31   >>> The new code produces links like /wikiisons/openid.png, which
  32   >>> fail if ikiwiki is not at the root of the web server. --[[Joey]]
  33
  34 * Should the comments be visually set off more from the page above?
  35   Rather than just a horizontal rule, I'm thinking put the comments
  36   in a box like is used for inlined pages.
  37
  38   > I did put them in a box in the CSS... I agree the default template
  39   > could do with visual improvement though. --[[smcv]]
  40
  41 * Instead of just a link to add a comment, it could have a form to enter
  42   the title, similar to the form for adding a new blog post.
  43
  44   > I'm not sure this is so useful? On Livejournal titles are allowed on
  45   > comments, but very rarely used (and indeed usually not very useful);
  46   > it's hard enough to get some people to title their blog posts :-)
  47   > --[[smcv]]
  48
  49 * If a spammer posts a comment, it is either impossible or hard to clean
  50   up via the web. Would be nice to have some kind of link on the comment
  51   that allows trusted users to remove it (using the remove plugin of
  52   course).
  53
  54   > Won't the remove plugin refuse to remove internal pages? This would be
  55   > a good feature to have, though. --[[smcv]]
  56
  57 * One can use inline to set up a feed of all comments posted to any page.
  58   Using template=comment they are displayed right. Only problem
  59   is there is no indication in that template of what page each comment in the
  60   feed is a comment on. So, if a comment is inlined into a different page,
  61   I think it should show a link back to the page commented on.
  62   (BTW, the rss feed in this situation seems ok; there the link element
  63   points back to the parent page.
  64
  65   > done --[[Joey]]
  66
  67 * It would be useful to have a pagespec that always matches all comments on
  68   pages matching a glob. Something like `comment(blog/*)`.
  69   Perhaps postcomment could also be folded into this? Then the pagespec
  70   would match both existing comments, as well as new comments that are
  71   being posted.
  72
  73   > Please see [[plugins/comments/discussion]]. If I've convinced you that
  74   > internal pages are the way forward, then sure, we can do that, because
  75   > people who can comment still won't be able to edit others' comments
  76   > (one of my goals is that commenters can't put words into each other's
  77   > mouths :-) )
  78   >
  79   > On the other hand, if you still want me to switch this plugin to "real"
  80   > pages, or if internal pages might become editable in future, then
  81   > configuring lockedit/anonok so a user X can add comments to blog pages
  82   > would also let X edit/delete comments on blog pages (including those
  83   > written by others) in arbitrary ways, which doesn't seem good. --[[smcv]]
  84
  85   > I had a look at implementing comment() and fell afoul of
  86   > some optimisations that assume only internal() will be used to match
  87   > internal pages. So probably this isn't worth doing. --[[Joey]]
  88
  89 * One of Joey's commit messages says "Not ideal, it would be nicer to jump to
  90   the actual comment posted, but no anchor is available". In fact there is
  91   an anchor - the `\[[_comment]]` preprocessing wraps the comment in a <div>
  92   with id="comment_123" or something. I'll fix this, unless Joey gets there
  93   first. --[[smcv]]
  94
  95   > done --[[Joey]]
  96
  97 * Now that inline has some comments-specific functionality anyway, it would
  98   be good to output '<link rel="comments">' in Atom and the equivalent in RSS.