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 >> Thinking about it, perhaps one way to address this would be to have the suffix
34 >> (e.g. whether commenting on Sandbox creates sandbox/comment1 or sandbox/c1 or
35 >> what) be configurable by the wiki admin, in the same way that recentchanges has
36 >> recentchangespage => 'recentchanges'? I'd like to see fewer hard-coded page
37 >> names in general, really - it seems odd to me that shortcuts and smileys
38 >> hard-code the name of the page to look at. Perhaps I could add
39 >> discussionpage => 'discussion' too? --[[smcv]]
41 >> The best reason to keep the pages internal seems to me to be that you
42 >> don't want the overhead of every comment spawning its own wiki page.
43 >> The worst problem with it though is that you have to assume the pages
44 >> are mdwn (or `default_pageext`) and not support other formats. --[[Joey]]
46 >> Well, you could always have `comment1._mdwn`, `comment2._creole` etc. and
47 >> alter the htmlize logic so that the `mdwn` hook is called for both `mdwn`
48 >> and `_mdwn` (assuming this is not already the case). I'm not convinced
49 >> that multi-format comments are a killer feature, though - part of the point
50 >> of this plugin, in my mind, is that it's less flexible than the full power
51 >> of ikiwiki and gives users fewer options. This could be construed
52 >> to be a feature, for people who don't care how flexible the technology is
53 >> and just want a simple way to leave a comment. The FormattingHelp page
54 >> assumes you're writing 100% Markdown in any case...
56 >> Internal pages do too many things, perhaps: they suppress generation of
57 >> HTML pages, they disable editing over the web, and they have a different
58 >> namespace of htmlize hooks. I think the first two of those are useful
59 >> for this plugin, and the last is harmless; you seem to think the first
60 >> is useful, and the other two are harmful. --[[smcv]]
62 >> By the way, I think that who can post comments should be controllable by
63 >> the existing plugins opendiscussion, anonok, signinedit, and lockedit. Allowing
64 >> posting comments w/o any login, while a nice capability, can lead to
65 >> spam problems. So, use `check_canedit` as at least a first-level check?
68 >> This plugin already uses `check_canedit`, but that function doesn't have a concept
69 >> of different actions. The hack I use is that when a user comments on, say, sandbox,
70 >> I call `check_canedit` for the pseudo-page "sandbox[postcomment]". The
71 >> special `postcomment(glob)` [[ikiwiki/pagespec]] returns true if the page ends with
72 >> "[postcomment]" and the part before (e.g. sandbox) matches the glob. So, you can
73 >> have postcomment(blog/*) or something. (Perhaps instead of taking a glob, postcomment
74 >> should take a pagespec, so you can have postcomment(link(tags/commentable))?)
76 >> This is why `anonok_pages => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'`
77 >> are necessary to allow anonymous and logged-in editing (respectively).
79 >> This is ugly - one alternative would be to add `check_permission()` that takes a
80 >> page and a verb (create, edit, rename, remove and maybe comment are the ones I
81 >> can think of so far), use that, and port the plugins you mentioned to use that
82 >> API too. This plugin could either call `check_can("$page/comment1", 'create')` or
83 >> call `check_can($page, 'comment')`.
85 >> One odd effect of the code structure I've used is that we check for the ability to
86 >> create the page before we actually know what page name we're going to use - when
87 >> posting the comment I just increment a number until I reach an unused one - so
88 >> either the code needs restructuring, or the permission check for 'create' would
89 >> always be for 'comment1' and never 'comment123'. --[[smcv]]
91 When using this plugin, you should also enable [[htmlscrubber]] and either [[htmltidy]]
92 or [[htmlbalance]]. Directives are filtered out by default, to avoid commenters slowing
93 down the wiki by causing time-consuming processing. As long as the recommended plugins
94 are enabled, comment authorship should hopefully be unforgeable by CGI users.
96 > I'm not sure that raw html should be a problem, as long as the
97 > htmlsanitizer and htmlbalanced plugins are enabled. I can see filtering
98 > out directives, as a special case. --[[Joey]]
100 >> Right, if I sanitize each post individually, with htmlscrubber and either htmltidy
101 >> or htmlbalance turned on, then there should be no way the user can forge a comment;
102 >> I was initially wary of allowing meta directives, but I think those are OK, as long
103 >> as the comment template puts the \[[!meta author]] at the *end*. Disallowing
104 >> directives is more a way to avoid commenters causing expensive processing than
105 >> anything else, at this point.
107 >> I've rebased the plugin on master, made it sanitize individual posts' content
108 >> and removed the option to disallow raw HTML. Sanitizing individual posts before
109 >> they've been htmlized required me to preserve whitespace in the htmlbalance
110 >> plugin, so I did that. Alternatively, we could htmlize immediately and always
111 >> save out raw HTML? --[[smcv]]
113 >> There might be some use cases for other directives, such as img, in
116 >> I don't know if meta is "safe" (ie, guaranteed to be inexpensive and not
117 >> allow users to do annoying things) or if it will continue to be in the
118 >> future. Hard to predict really, all that can be said with certainty is
119 >> all directives will contine to be inexpensive and safe enough that it's
120 >> sensible to allow users to (ab)use them on open wikis.
123 When comments have been enabled generally, you still need to mark which pages
124 can have comments, by including the `\[[!comments]]` directive in them. By default,
125 this directive expands to a "post a comment" link plus an `\[[!inline]]` with
128 > I don't like this, because it's hard to explain to someone why they have
129 > to insert this into every post to their blog. Seems that the model used
130 > for discussion pages could work -- if comments are enabled, automatically
131 > add the comment posting form and comments to the end of each page.
134 >> I don't think I'd want comments on *every* page (particularly, not the
135 >> front page). Perhaps a pagespec in the setup file, where the default is "*"?
136 >> Then control freaks like me could use "link(tags/comments)" and tag pages
137 >> as allowing comments.
139 >>> Yes, I think a pagespec is the way to go. --[[Joey]]
141 >> The model used for discussion pages does require patching the existing
142 >> page template, which I was trying to avoid - I'm not convinced that having
143 >> every possible feature hard-coded there really scales (and obviously it's
144 >> rather annoying while this plugin is on a branch). --[[smcv]]
146 >>> Using the template would allow customising the html around the comments
147 >>> which seems like a good thing? --[[Joey]]
149 >>> The \[[!comments]] directive is already template-friendly - it expands to
150 >>> the contents of the template `comments_embed.tmpl`, possibly with the
151 >>> result of an \[[!inline]] appended. I should change `comments_embed.tmpl`
152 >>> so it uses a template variable `INLINE` for the inline result rather than
153 >>> having the perl code concatenate it, which would allow a bit more
154 >>> customization (whether the "post" link was before or after the inline).
155 >>> Even if you want comments in page.tmpl, keeping the separate comments_embed.tmpl
156 >>> and having a `COMMENTS` variable in page.tmpl might be the way forward,
157 >>> since the smaller each templates is, the easier it will be for users
158 >>> to maintain a patched set of templates. (I think so, anyway, based on what happens
159 >>> with dpkg prompts in Debian packages with monolithic vs split
160 >>> conffiles.) --[[smcv]]
162 The plugin adds a new [[ikiwiki/PageSpec]] match type, `postcomment`, for use
163 with `anonok_pagespec` from the [[plugins/anonok]] plugin or `locked_pages` from
164 the [[plugins/lockedit]] plugin. Typical usage would be something like:
166 locked_pages => "!postcomment(*)"
168 to allow non-admin users to comment on pages, but not edit anything. You can also do
170 anonok_pages => "postcomment(*)"
172 to allow anonymous comments (the IP address will be used as the "author").
174 > This is still called postcomment, although I've renamed the rest of the plugin
175 > to comments as suggested on #ikiwiki --[[smcv]]
177 Optional parameters to the comments directive:
179 * `commit=no`: by default, comments are committed to version control. Use this to
181 * `allowdirectives=yes`: by default, IkiWiki directives are filtered out. Use this
182 to allow directives (avoid enabling any [[plugins/type/slow]] directives if you
184 * `closed=yes`: use this to prevent new comments while still displaying existing ones.
185 * `atom`, `rss`, `feeds`, `feedshow`, `timeformat`, `feedonly`: the same as for [[plugins/inline]]
187 >> I don't think feedonly actually makes sense here, so I'll remove it. --[[smcv]]
189 This plugin aims to close the [[todo]] item "[[todo/supporting_comments_via_disussion_pages]]",
190 and is currently available from [[smcv]]'s git repository on git.pseudorandom.co.uk (it's the
191 `postcomment` branch). A demo wiki with the plugin enabled is running at
192 <http://www.pseudorandom.co.uk/2008/ikiwiki/demo/>.
197 * The access control via postcomment() is rather strange
198 * There is some common code cargo-culted from other plugins (notably inline and editpage) which
199 should probably be shared
200 * If the comments directive is removed from a page, comments can still be made on that page,
201 and will be committed but not displayed; to disable comments properly you have to set the
202 closed="yes" directive parameter (and refresh the wiki), *then* remove the directive if
205 > I haven't done a detailed code review, but I will say I'm pleased you
206 > avoided re-implementing inline! --[[Joey]]
210 * tbm would like anonymous people to be able to enter their name and possibly email
212 * smcv would like an indication of who you're posting as / the ability to log in
213 as someone else (even if anonymous comments are allowed, it'd be nice to be
214 able to choose to log in with a username or OpenID, like in Livejournal);
215 perhaps editpage needs this too