-> 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. --[[smcv]]
-
-When comments have been enabled generally, you still need to mark which pages
-can have comments, by including the `\[[!comments]]` directive in them. By default,
-this directive expands to a "post a comment" link plus an `\[[!inline]]` with
-the comments.
-
-> I don't like this, because it's hard to explain to someone why they have
-> to insert this into every post to their blog. Seems that the model used
-> for discussion pages could work -- if comments are enabled, automatically
-> add the comment posting form and comments to the end of each page.
-> --[[Joey]]
-
->> I don't think I'd want comments on *every* page (particularly, not the
->> front page). Perhaps a pagespec in the setup file, where the default is "*"?
->> Then control freaks like me could use "link(tags/comments)" and tag pages
->> as allowing comments.
->>
->> The model used for discussion pages does require patching the existing
->> page template, which I was trying to avoid - I'm not convinced that having
->> every possible feature hard-coded there really scales (and obviously it's
->> rather annoying while this plugin is on a branch). --[[smcv]]
-