1 [[!template id=plugin name=comments author="[[Simon_McVittie|smcv]]"]]
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.
8 Comments are saved as internal pages, so they can never be edited through the CGI,
9 only by direct committers. Currently, comments are always in [[ikiwiki/markdown]].
11 > So, why do it this way, instead of using regular wiki pages in a
12 > namespace, such as `$page/comments/*`? Then you could use [[plugins/lockedit]] to
13 > limit editing of comments in more powerful ways. --[[Joey]]
15 >> Er... I suppose so. I'd assumed that these pages ought to only exist as inlines
16 >> rather than as individual pages (same reasoning as aggregated posts), though.
18 >> lockedit is actually somewhat insufficient, since `check_canedit()`
19 >> doesn't distinguish between creation and editing; I'd have to continue to use
20 >> some sort of odd hack to allow creation but not editing.
22 >> I also can't think of any circumstance where you'd want a user other than
23 >> admins (~= git committers) and possibly the commenter (who we can't check for
24 >> at the moment anyway, I don't think?) to be able to edit comments - I think
25 >> user expectations for something that looks like ordinary blog comments are
26 >> likely to include "others can't put words into my mouth".
28 >> My other objection to using a namespace is that I'm not particularly happy about
29 >> plugins consuming arbitrary pieces of the wiki namespace - /discussion is bad
30 >> enough already. Indeed, this very page would accidentally get matched by rules
31 >> aiming to control comment-posting... :-) --[[smcv]]
33 >> The best reason to keep the pages internal seems to me to be that you
34 >> don't want the overhead of every comment spawning its own wiki page.
35 >> The worst problem with it though is that you have to assume the pages
36 >> are mdwn (or `default_pageext`) and not support other formats.
38 >> By the way, I think that who can post comments should be controllable by
39 >> the existing plugins opendiscussion, anonok, signinedit, and lockedit. Allowing
40 >> posting comments w/o any login, while a nice capability, can lead to
41 >> spam problems. So, use `check_canedit` as at least a first-level check?
44 When using this plugin, you should also enable [[htmlscrubber]] and either [[htmltidy]]
45 or [[htmlbalance]]. Directives are filtered out by default, to avoid commenters slowing
46 down the wiki by causing time-consuming processing. As long as the recommended plugins
47 are enabled, comment authorship should hopefully be unforgeable by CGI users.
49 > I'm not sure that raw html should be a problem, as long as the
50 > htmlsanitizer and htmlbalanced plugins are enabled. I can see filtering
51 > out directives, as a special case. --[[Joey]]
53 >> Right, if I sanitize each post individually, with htmlscrubber and either htmltidy
54 >> or htmlbalance turned on, then there should be no way the user can forge a comment;
55 >> I was initially wary of allowing meta directives, but I think those are OK, as long
56 >> as the comment template puts the \[[!meta author]] at the *end*. Disallowing
57 >> directives is more a way to avoid commenters causing expensive processing than
58 >> anything else, at this point.
60 >> I've rebased the plugin on master, made it sanitize individual posts' content
61 >> and removed the option to disallow raw HTML. --[[smcv]]
63 >> There might be some use cases for other directives, such as img, in
66 >> I don't know if meta is "safe" (ie, guaranteed to be inexpensive and not
67 >> allow users to do annoying things) or if it will continue to be in the
68 >> future. Hard to predict really, all that can be said with certainty is
69 >> all directives will contine to be inexpensive and safe enough that it's
70 >> sensible to allow users to (ab)use them on open wikis.
73 When comments have been enabled generally, you still need to mark which pages
74 can have comments, by including the `\[[!comments]]` directive in them. By default,
75 this directive expands to a "post a comment" link plus an `\[[!inline]]` with
78 > I don't like this, because it's hard to explain to someone why they have
79 > to insert this into every post to their blog. Seems that the model used
80 > for discussion pages could work -- if comments are enabled, automatically
81 > add the comment posting form and comments to the end of each page.
84 >> I don't think I'd want comments on *every* page (particularly, not the
85 >> front page). Perhaps a pagespec in the setup file, where the default is "*"?
86 >> Then control freaks like me could use "link(tags/comments)" and tag pages
87 >> as allowing comments.
89 >>> Yes, I think a pagespec is the way to go. --[[Joey]]
91 >> The model used for discussion pages does require patching the existing
92 >> page template, which I was trying to avoid - I'm not convinced that having
93 >> every possible feature hard-coded there really scales (and obviously it's
94 >> rather annoying while this plugin is on a branch). --[[smcv]]
96 >>> Using the template would allow customising the html around the comments
97 >>> which seems like a good thing?
99 The plugin adds a new [[ikiwiki/PageSpec]] match type, `postcomment`, for use
100 with `anonok_pagespec` from the [[plugins/anonok]] plugin or `locked_pages` from
101 the [[plugins/lockedit]] plugin. Typical usage would be something like:
103 locked_pages => "!postcomment(*)"
105 to allow non-admin users to comment on pages, but not edit anything. You can also do
107 anonok_pages => "postcomment(*)"
109 to allow anonymous comments (the IP address will be used as the "author").
111 > This is still called postcomment, although I've renamed the rest of the plugin
112 > to comments as suggested on #ikiwiki --[[smcv]]
114 Optional parameters to the comments directive:
116 * `commit=no`: by default, comments are committed to version control. Use this to
118 * `allowdirectives=yes`: by default, IkiWiki directives are filtered out. Use this
119 to allow directives (avoid enabling any [[plugins/type/slow]] directives if you
121 * `closed=yes`: use this to prevent new comments while still displaying existing ones.
122 * `atom`, `rss`, `feeds`, `feedshow`, `timeformat`, `feedonly`: the same as for [[plugins/inline]]
124 This plugin aims to close the [[todo]] item "[[todo/supporting_comments_via_disussion_pages]]",
125 and is currently available from [[smcv]]'s git repository on git.pseudorandom.co.uk (it's the
126 `postcomment` branch). A demo wiki with the plugin enabled is running at
127 <http://www.pseudorandom.co.uk/2008/ikiwiki/demo/>.
132 * The access control via postcomment() is rather strange
133 * There is some common code cargo-culted from other plugins (notably inline and editpage) which
134 should probably be shared
135 * If the comments directive is removed from a page, comments can still be made on that page,
136 and will be committed but not displayed; to disable comments properly you have to set the
137 closed="yes" directive parameter (and refresh the wiki), *then* remove the directive if
140 > I haven't done a detailed code review, but I will say I'm pleased you
141 > avoided re-implementing inline! --[[Joey]]