doc/plugins/comments/discussion.mdwn

   1 ## Moderating comments from the CLI
   2
   3 How do you do this, without using the UI in the Preferences?
   4
   5 Please put this info on the page. Many thanks --[[Kai Hendry]]
   6
   7 ## Why internal pages? (unresolved)
   8
   9 Comments are saved as internal pages, so they can never be edited through the CGI,
  10 only by direct committers.
  11
  12 > So, why do it this way, instead of using regular wiki pages in a
  13 > namespace, such as `$page/comments/*`? Then you could use [[plugins/lockedit]] to
  14 > limit editing of comments in more powerful ways. --[[Joey]]
  15
  16 >> Er... I suppose so. I'd assumed that these pages ought to only exist as inlines
  17 >> rather than as individual pages (same reasoning as aggregated posts), though.
  18 >>
  19 >> lockedit is actually somewhat insufficient, since `check_canedit()`
  20 >> doesn't distinguish between creation and editing; I'd have to continue to use
  21 >> some sort of odd hack to allow creation but not editing.
  22 >>
  23 >> I also can't think of any circumstance where you'd want a user other than
  24 >> admins (~= git committers) and possibly the commenter (who we can't check for
  25 >> at the moment anyway, I don't think?) to be able to edit comments - I think
  26 >> user expectations for something that looks like ordinary blog comments are
  27 >> likely to include "others can't put words into my mouth".
  28 >>
  29 >> My other objection to using a namespace is that I'm not particularly happy about
  30 >> plugins consuming arbitrary pieces of the wiki namespace - /discussion is bad
  31 >> enough already. Indeed, this very page would accidentally get matched by rules
  32 >> aiming to control comment-posting... :-) --[[smcv]]
  33
  34 >>> Thinking about it, perhaps one way to address this would be to have the suffix
  35 >>> (e.g. whether commenting on Sandbox creates sandbox/comment1 or sandbox/c1 or
  36 >>> what) be configurable by the wiki admin, in the same way that recentchanges has
  37 >>> recentchangespage => 'recentchanges'? I'd like to see fewer hard-coded page
  38 >>> names in general, really - it seems odd to me that shortcuts and smileys
  39 >>> hard-code the name of the page to look at. Perhaps I could add
  40 >>> discussionpage => 'discussion' too? --[[smcv]]
  41
  42 >>> (I've now implemented this in my branch. --[[smcv]])
  43
  44 >> The best reason to keep the pages internal seems to me to be that you
  45 >> don't want the overhead of every comment spawning its own wiki page. --[[Joey]]
  46
  47 ## Formats (resolved)
  48
  49 The plugin now allows multiple comment formats while still using internal
  50 pages; each comment is saved as a page containing one `\[[!comment]]` directive,
  51 which has a superset of the functionality of [[ikiwiki/directives/format]].
  52
  53 ## Access control (unresolved?)
  54
  55 By the way, I think that who can post comments should be controllable by
  56 the existing plugins opendiscussion, anonok, signinedit, and lockedit. Allowing
  57 posting comments w/o any login, while a nice capability, can lead to
  58 spam problems. So, use `check_canedit` as at least a first-level check?
  59 --[[Joey]]
  60
  61 > This plugin already uses `check_canedit`, but that function doesn't have a concept
  62 > of different actions. The hack I use is that when a user comments on, say, sandbox,
  63 > I call `check_canedit` for the pseudo-page "sandbox[postcomment]". The
  64 > special `postcomment(glob)` [[ikiwiki/pagespec]] returns true if the page ends with
  65 > "[postcomment]" and the part before (e.g. sandbox) matches the glob. So, you can
  66 > have postcomment(blog/*) or something. (Perhaps instead of taking a glob, postcomment
  67 > should take a pagespec, so you can have postcomment(link(tags/commentable))?)
  68 >
  69 > This is why `anonok_pagespec => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'`
  70 > are necessary to allow anonymous and logged-in editing (respectively).
  71 >
  72 >> I changed that to move the flag out of the page name, and into a variable that the `match_postcomment`
  73 >> function checks for. Other ugliness still applies. :-) --[[Joey]]
  74 >
  75 > This is ugly - one alternative would be to add `check_permission()` that takes a
  76 > page and a verb (create, edit, rename, remove and maybe comment are the ones I
  77 > can think of so far), use that, and port the plugins you mentioned to use that
  78 > API too. This plugin could either call `check_can("$page/comment1", 'create')` or
  79 > call `check_can($page, 'comment')`.
  80 >
  81 > One odd effect of the code structure I've used is that we check for the ability to
  82 > create the page before we actually know what page name we're going to use - when
  83 > posting the comment I just increment a number until I reach an unused one - so
  84 > either the code needs restructuring, or the permission check for 'create' would
  85 > always be for 'comment1' and never 'comment123'. --[[smcv]]
  86
  87 >> Now resolved, in fact --[[smcv]]
  88
  89 > Another possibility is to just check for permission to edit (e.g.) `sandbox/comment1`.
  90 > However, this makes the "comments can only be created, not edited" feature completely
  91 > reliant on the fact that internal pages can't be edited. Perhaps there should be a
  92 > `editable_pages` pagespec, defaulting to `'*'`? --[[smcv]]
  93
  94 ## comments directive vs global setting (resolved?)
  95
  96 When comments have been enabled generally, you still need to mark which pages
  97 can have comments, by including the `\[[!comments]]` directive in them. By default,
  98 this directive expands to a "post a comment" link plus an `\[[!inline]]` with
  99 the comments. [This requirement has now been removed --[[smcv]]]
 100
 101 > I don't like this, because it's hard to explain to someone why they have
 102 > to insert this into every post to their blog. Seems that the model used
 103 > for discussion pages could work -- if comments are enabled, automatically
 104 > add the comment posting form and comments to the end of each page.
 105 > --[[Joey]]
 106
 107 >> I don't think I'd want comments on *every* page (particularly, not the
 108 >> front page). Perhaps a pagespec in the setup file, where the default is "*"?
 109 >> Then control freaks like me could use "link(tags/comments)" and tag pages
 110 >> as allowing comments.
 111 >>
 112 >>> Yes, I think a pagespec is the way to go. --[[Joey]]
 113
 114 >>>> Implemented --[[smcv]]
 115
 116 >>
 117 >> The model used for discussion pages does require patching the existing
 118 >> page template, which I was trying to avoid - I'm not convinced that having
 119 >> every possible feature hard-coded there really scales (and obviously it's
 120 >> rather annoying while this plugin is on a branch). --[[smcv]]
 121
 122 >>> Using the template would allow customising the html around the comments
 123 >>> which seems like a good thing? --[[Joey]]
 124
 125 >>>> The \[[!comments]] directive is already template-friendly - it expands to
 126 >>>> the contents of the template `comments_embed.tmpl`, possibly with the
 127 >>>> result of an \[[!inline]] appended. I should change `comments_embed.tmpl`
 128 >>>> so it uses a template variable `INLINE` for the inline result rather than
 129 >>>> having the perl code concatenate it, which would allow a bit more
 130 >>>> customization (whether the "post" link was before or after the inline).
 131 >>>> Even if you want comments in page.tmpl, keeping the separate comments_embed.tmpl
 132 >>>> and having a `COMMENTS` variable in page.tmpl might be the way forward,
 133 >>>> since the smaller each templates is, the easier it will be for users
 134 >>>> to maintain a patched set of templates. (I think so, anyway, based on what happens
 135 >>>> with dpkg prompts in Debian packages with monolithic vs split
 136 >>>> conffiles.) --[[smcv]]
 137
 138 >>>>> I've switched my branch to use page.tmpl instead; see what you think? --[[smcv]]
 139
 140 ## Raw HTML (resolved?)
 141
 142 Raw HTML was not initially allowed by default (this was configurable).
 143
 144 > I'm not sure that raw html should be a problem, as long as the
 145 > htmlsanitizer and htmlbalanced plugins are enabled. I can see filtering
 146 > out directives, as a special case. --[[Joey]]
 147
 148 >> Right, if I sanitize each post individually, with htmlscrubber and either htmltidy
 149 >> or htmlbalance turned on, then there should be no way the user can forge a comment;
 150 >> I was initially wary of allowing meta directives, but I think those are OK, as long
 151 >> as the comment template puts the \[[!meta author]] at the *end*. Disallowing
 152 >> directives is more a way to avoid commenters causing expensive processing than
 153 >> anything else, at this point.
 154 >>
 155 >> I've rebased the plugin on master, made it sanitize individual posts' content
 156 >> and removed the option to disallow raw HTML. Sanitizing individual posts before
 157 >> they've been htmlized required me to preserve whitespace in the htmlbalance
 158 >> plugin, so I did that. Alternatively, we could htmlize immediately and always
 159 >> save out raw HTML? --[[smcv]]
 160
 161 >>> There might be some use cases for other directives, such as img, in
 162 >>> comments.
 163 >>>
 164 >>> I don't know if meta is "safe" (ie, guaranteed to be inexpensive and not
 165 >>> allow users to do annoying things) or if it will continue to be in the
 166 >>> future. Hard to predict really, all that can be said with certainty is
 167 >>> all directives will contine to be inexpensive and safe enough that it's
 168 >>> sensible to allow users to (ab)use them on open wikis.
 169 >>> --[[Joey]]
 170
 171 ----
 172
 173 I have a test ikiwiki setup somewhere to investigate adopting the comments
 174 plugin. It is setup with no auth enabled and I got hammered with a spam attack
 175 over the last weekend (predictably).  What surprised me was the scale of the
 176 attack: ikiwiki eventually triggered OOM and brought the box down. When I got
 177 it back up, I checked out a copy of the underlying git repository, and it
 178 measured 280M in size after being packed. Of that, about 300K was data prior
 179 to the spam attack, so the rest was entirely spam text, compressed via git's
 180 efficient delta compression.
 181
 182 I had two thoughts about possible improvements to the comments plugin in the
 183 wake of this:
 184
 185  * comment pagination - there is a hard-to-define upper limit on the number
 186    of comments that can be appended to a wiki page whilst the page remains
 187    legible.  It would be useful if comments could be paginated into sub-pages.
 188
 189  * crude flood control - asides from spam attacks (and I am aware of
 190    [[plugins/blogspam]]), people can crap flood or just aggressively flame
 191    repeatedly. An interesting prevention measure might be to not let an IP
 192    post more than 3 sequential comments to a page, or to the site, without
 193    at least one other comment being interleaved. I say 3 rather than 2 since
 194    correction follow-ups are common.
 195
 196 -- [[Jon]]