X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/9d5075ab521a24d718a2b663e11856c8cc80eb03..dc635c70d4e06619a844eb824807dba961d6c95e:/doc/plugins/comments/discussion.mdwn?ds=inline
diff --git a/doc/plugins/comments/discussion.mdwn b/doc/plugins/comments/discussion.mdwn
index 59740ec37..227890bdd 100644
--- a/doc/plugins/comments/discussion.mdwn
+++ b/doc/plugins/comments/discussion.mdwn
@@ -1,3 +1,18 @@
+## Syndication autodiscovery for comment feeds
+
+A standard `\[[!inline]]` directive adds links to the autogenerated syndication feeds using link tags in the header:
+
+
+
+
+These links aren't added to my pages that include comments even though comments generate syndication feeds. How can I configure the comments plugin to add these links to the header? (These links are required for user-agent autodiscovery of syndication feeds.) --[[anderbubble]]
+
+## Moderating comments from the CLI
+
+How do you do this, without using the UI in the Preferences?
+
+Please put this info on the page. Many thanks --[[Kai Hendry]]
+
## Why internal pages? (unresolved)
Comments are saved as internal pages, so they can never be edited through the CGI,
@@ -60,9 +75,12 @@ spam problems. So, use `check_canedit` as at least a first-level check?
> have postcomment(blog/*) or something. (Perhaps instead of taking a glob, postcomment
> should take a pagespec, so you can have postcomment(link(tags/commentable))?)
>
-> This is why `anonok_pages => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'`
+> This is why `anonok_pagespec => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'`
> are necessary to allow anonymous and logged-in editing (respectively).
>
+>> I changed that to move the flag out of the page name, and into a variable that the `match_postcomment`
+>> function checks for. Other ugliness still applies. :-) --[[Joey]]
+>
> This is ugly - one alternative would be to add `check_permission()` that takes a
> page and a verb (create, edit, rename, remove and maybe comment are the ones I
> can think of so far), use that, and port the plugins you mentioned to use that
@@ -158,3 +176,43 @@ Raw HTML was not initially allowed by default (this was configurable).
>>> 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]]
+
+----
+
+I have a test ikiwiki setup somewhere to investigate adopting the comments
+plugin. It is setup with no auth enabled and I got hammered with a spam attack
+over the last weekend (predictably). What surprised me was the scale of the
+attack: ikiwiki eventually triggered OOM and brought the box down. When I got
+it back up, I checked out a copy of the underlying git repository, and it
+measured 280M in size after being packed. Of that, about 300K was data prior
+to the spam attack, so the rest was entirely spam text, compressed via git's
+efficient delta compression.
+
+I had two thoughts about possible improvements to the comments plugin in the
+wake of this:
+
+ * comment pagination - there is a hard-to-define upper limit on the number
+ of comments that can be appended to a wiki page whilst the page remains
+ legible. It would be useful if comments could be paginated into sub-pages.
+
+ * crude flood control - asides from spam attacks (and I am aware of
+ [[plugins/blogspam]]), people can crap flood or just aggressively flame
+ repeatedly. An interesting prevention measure might be to not let an IP
+ post more than 3 sequential comments to a page, or to the site, without
+ at least one other comment being interleaved. I say 3 rather than 2 since
+ correction follow-ups are common.
+
+-- [[Jon]]
+
+
+---
+
+## Comment threads
+
+Any thoughts about implementing some simple threading in the comments?
+
+Or at least a reply functionality that quotes the subject/contents?
+
+-- [[iustin]]
+
+---