doc/plugins/contrib/comments.mdwn

   1 [[!template id=plugin name=comments author="[[Simon_McVittie|smcv]]"]]
   2 [[!tag type/useful]]
   3
   4 This plugin adds "blog-style" comments. The intention is that on a non-wiki site
   5 (like a blog) you can lock all pages for admin-only access, then allow otherwise
   6 unprivileged (or perhaps even anonymous) users to comment on posts.
   7
   8 When using this plugin, you should also enable [[htmlscrubber]] and either [[htmltidy]]
   9 or [[htmlbalance]]. Directives are filtered out by default, to avoid commenters slowing
  10 down the wiki by causing time-consuming processing. As long as the recommended plugins
  11 are enabled, comment authorship should hopefully be unforgeable by CGI users.
  12
  13 > I'm not sure that raw html should be a problem, as long as the
  14 > htmlsanitizer and htmlbalanced plugins are enabled. I can see filtering
  15 > out directives, as a special case. --[[Joey]]
  16
  17 >> Right, if I sanitize each post individually, with htmlscrubber and either htmltidy
  18 >> or htmlbalance turned on, then there should be no way the user can forge a comment;
  19 >> I was initially wary of allowing meta directives, but I think those are OK, as long
  20 >> as the comment template puts the \[[!meta author]] at the *end*. Disallowing
  21 >> directives is more a way to avoid commenters causing expensive processing than
  22 >> anything else, at this point.
  23 >>
  24 >> I've rebased the plugin on master, made it sanitize individual posts' content
  25 >> and removed the option to disallow raw HTML. Sanitizing individual posts before
  26 >> they've been htmlized required me to preserve whitespace in the htmlbalance
  27 >> plugin, so I did that. Alternatively, we could htmlize immediately and always
  28 >> save out raw HTML? --[[smcv]]
  29
  30 >> There might be some use cases for other directives, such as img, in
  31 >> comments.
  32 >>
  33 >> I don't know if meta is "safe" (ie, guaranteed to be inexpensive and not
  34 >> allow users to do annoying things) or if it will continue to be in the
  35 >> future. Hard to predict really, all that can be said with certainty is
  36 >> all directives will contine to be inexpensive and safe enough that it's
  37 >> sensible to allow users to (ab)use them on open wikis.
  38 >> --[[Joey]]
  39
  40 The plugin adds a new [[ikiwiki/PageSpec]] match type, `postcomment`, for use
  41 with `anonok_pagespec` from the [[plugins/anonok]] plugin or `locked_pages` from
  42 the [[plugins/lockedit]] plugin. Typical usage would be something like:
  43
  44     locked_pages => "!postcomment(*)"
  45
  46 to allow non-admin users to comment on pages, but not edit anything. You can also do
  47
  48     anonok_pages => "postcomment(*)"
  49
  50 to allow anonymous comments (the IP address will be used as the "author").
  51
  52 There are some global options for the setup file:
  53
  54 * `comments_shown_pagespec`: pages where comments will be displayed inline, e.g. `blog/*`
  55   or `*/discussion`.
  56 * `comments_open_pagespec`: pages where new comments can be posted, e.g.
  57   `blog/* and created_after(close_old_comments)` or `*/discussion`
  58 * `comments_pagename`: if this is e.g. `comment_` (the default), then comments on the
  59   [[sandbox]] will be called something like `sandbox/comment_12`
  60 * `comments_allowdirectives`: if true (default false), comments may contain IkiWiki
  61   directives
  62 * `comments_commit`: if true (default true), comments will be committed to the version
  63   control system
  64
  65 This plugin aims to close the [[todo]] item "[[todo/supporting_comments_via_disussion_pages]]",
  66 and is currently available from [[smcv]]'s git repository on git.pseudorandom.co.uk (it's the
  67 `postcomment` branch). A demo wiki with the plugin enabled is running at
  68 <http://www.pseudorandom.co.uk/2008/ikiwiki/demo/>.
  69
  70 Known issues:
  71
  72 * Needs code review
  73 * The access control via postcomment() is rather strange
  74 * There is some common code cargo-culted from other plugins (notably inline and editpage) which
  75   should probably be shared
  76
  77 > I haven't done a detailed code review, but I will say I'm pleased you
  78 > avoided re-implementing inline! --[[Joey]]
  79
  80 Wishlist:
  81
  82 * tbm would like anonymous people to be able to enter their name and possibly email
  83   address
  84 * smcv would like an indication of who you're posting as / the ability to log in
  85   as someone else (even if anonymous comments are allowed, it'd be nice to be
  86   able to choose to log in with a username or OpenID, like in Livejournal);
  87   perhaps editpage needs this too