aboutsummaryrefslogtreecommitdiff
path: root/doc/plugins/contrib/comments.mdwn
blob: 891d3dee563513f0bc191a871dbc46888433fe54 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
[[!template id=plugin name=comments author="[[Simon_McVittie|smcv]]"]]
[[!tag type/useful]]

This plugin adds "blog-style" comments. The intention is that on a non-wiki site
(like a blog) you can lock all pages for admin-only access, then allow otherwise
unprivileged (or perhaps even anonymous) users to comment on posts.

When using this plugin, you should also enable [[htmlscrubber]] and either [[htmltidy]]
or [[htmlbalance]]. Directives are filtered out by default, to avoid commenters slowing
down the wiki by causing time-consuming processing. As long as the recommended plugins
are enabled, comment authorship should hopefully be unforgeable by CGI users.

> I'm not sure that raw html should be a problem, as long as the
> htmlsanitizer and htmlbalanced plugins are enabled. I can see filtering
> out directives, as a special case. --[[Joey]]

>> Right, if I sanitize each post individually, with htmlscrubber and either htmltidy
>> or htmlbalance turned on, then there should be no way the user can forge a comment;
>> I was initially wary of allowing meta directives, but I think those are OK, as long
>> as the comment template puts the \[[!meta author]] at the *end*. Disallowing
>> directives is more a way to avoid commenters causing expensive processing than
>> anything else, at this point.
>>
>> I've rebased the plugin on master, made it sanitize individual posts' content
>> and removed the option to disallow raw HTML. Sanitizing individual posts before
>> they've been htmlized required me to preserve whitespace in the htmlbalance
>> plugin, so I did that. Alternatively, we could htmlize immediately and always
>> save out raw HTML? --[[smcv]]

>> There might be some use cases for other directives, such as img, in
>> comments.
>> 
>> I don't know if meta is "safe" (ie, guaranteed to be inexpensive and not
>> allow users to do annoying things) or if it will continue to be in the
>> future. Hard to predict really, all that can be said with certainty is
>> all directives will contine to be inexpensive and safe enough that it's
>> sensible to allow users to (ab)use them on open wikis.
>> --[[Joey]]

The plugin adds a new [[ikiwiki/PageSpec]] match type, `postcomment`, for use
with `anonok_pagespec` from the [[plugins/anonok]] plugin or `locked_pages` from
the [[plugins/lockedit]] plugin. Typical usage would be something like:

    locked_pages => "!postcomment(*)"

to allow non-admin users to comment on pages, but not edit anything. You can also do

    anonok_pages => "postcomment(*)"

to allow anonymous comments (the IP address will be used as the "author").

There are some global options for the setup file:

* `comments_shown_pagespec`: pages where comments will be displayed inline, e.g. `blog/*`
  or `*/discussion`.
* `comments_open_pagespec`: pages where new comments can be posted, e.g.
  `blog/* and created_after(close_old_comments)` or `*/discussion`
* `comments_pagename`: if this is e.g. `comment_` (the default), then comments on the
  [[sandbox]] will be called something like `sandbox/comment_12`
* `comments_allowdirectives`: if true (default false), comments may contain IkiWiki
  directives
* `comments_commit`: if true (default true), comments will be committed to the version
  control system

This plugin aims to close the [[todo]] item "[[todo/supporting_comments_via_disussion_pages]]",
and is currently available from [[smcv]]'s git repository on git.pseudorandom.co.uk (it's the
`postcomment` branch). A demo wiki with the plugin enabled is running at
<http://www.pseudorandom.co.uk/2008/ikiwiki/demo/>.

Known issues:

* Needs code review
* The access control via postcomment() is rather strange
* There is some common code cargo-culted from other plugins (notably inline and editpage) which
  should probably be shared

> I haven't done a detailed code review, but I will say I'm pleased you
> avoided re-implementing inline! --[[Joey]]

Wishlist:

* tbm would like anonymous people to be able to enter their name and possibly email
  address
* smcv would like an indication of who you're posting as / the ability to log in
  as someone else (even if anonymous comments are allowed, it'd be nice to be
  able to choose to log in with a username or OpenID, like in Livejournal);
  perhaps editpage needs this too