• View
• Edit
• History
• Attach
• Print
• Backlinks

CommentDb

Goal

Add the possibility for the users to comment on the pages. The existing solution lacks two important features:

• Comments are not paginated, so once there are 500 comments on a page, it takes a while to load.
• An RSS-feed for the comments is a desired feature that lacks there.

Also any "standard" forum-based solution a-la PhpBB has an UI that is too-complex to be elegant (to my taste at least).

Solution

A remake of the comment-box-styled script, that uses a MySQL database to store comments. For this price it provides comment pagination (only N comments are displayed at once on a page) and a convenient RSS-feed for the comments. Visually, the resulting comment thread looks just like the one produced by the CommentBox script.

Files

• commentdb.phpΔ
• commentdb.mysql.txtΔ

Usage

1. You need to set up a MySQL database. (someone could set up a clearer explanation perhaps)
   • Create a new database:
     • $ mysql -p -u root
     • > create database mydatabase;
     • > grant all privileges on mydatabase.* to myuser@localhost identified by 'mypassword';
     • > \q
   • In the database, create a table given in commentdb.mysql.txt:Δ
     • $ mysql -p -u myuser mydatabase < commentdb.mysql
   • Check that table's encoding is the one you need (the script currently assumes utf8).
2. Put commentdb.phpΔ in the cookbook/ directory.
3. Edit your local/config.php, add lines similar to the following:
   include_once("cookbook/commentdb.php");
   $CdbCommentsPerPage = 15;
   $CdbMySQLHost = "localhost";
   $CdbMySQLDb = "mydatabase";
   $CdbMySQLUser = "myuser";
   $CdbMySQLPass = "mypassword";
4. On a page where you want the comments to be shown (the last line is a good choice), put the (:commentdb:) directive.
5. You might also put it in a GroupFooter to add comment functionality to all pages in a group simultaneously.
6. If your site does not use UTF8 as the encoding, you'll have to take a look into commentdb.php, and try changing the encoding. I can't promise it'll work out-of-the-box as I haven't tested it..
7. The comments RSS-feed is provided by action=comment-rss.

Known Issues

1. GroupHeader/GroupFooter support not tested, but should work.
2. Currently only supports UTF-8 encoding. There's a lame attempt at making it configurable but its not tested at all.
   • If you see encoding errors, these might be caused by the "set names 'utf8'" query being done. On some machines this is needed for the code to work with UTF8 nicely, on others it just produces encoding mess. It's not clear to me why's that so. Anyway, you might try deleting the corresponding line from the code if needed.
3. The thing was used in a small friendly community, so it's not guaranteed to be secure and durable for use in the wild.
   • In particular, it does not respect page protection (anyone can post comments even to a password-protected page, of course, posting comments does not modify the page in any way)
   • Although read-protected pages will still be read-protected, the last page of comments is still readable via RSS.
   • Linkspam protection missing.
4. The CSS styling was only tested in a single context, so it most probably requires further tuning for general use.
5. In general PmWiki markup seems to be supported within the comments. At least one exception is with line breaks. Somewhy they don't produce paragraphs.
6. Some lame attempts at making it internationalizable/localizable, but these are not tested.
7. If your MySQL server breaks you most probably won't get very informative error messages. At least it wasn't tested.
8. Comments can only be deleted via database, no nice interface for that (should not at all be hard to make, anyone?)
9. The whole thing was created and tested with CleanUrls enabled.
10. RSS does not completely validate for two reasons: a) the "author" in RSS is not a valid email. b) The xml encoding is given as "utf8" while it should be "utf-8". Thunderbird can read the RSS anyway.. (and a trivial modification would solve these of course).
11. RSS will be invalid if some comments contain the < character (easily fixable by a str_replace in line 6 of format_rss2)
12. [Not verified] It seems that although the comments are substituted during the fulltext stage, some html codes may appear unescaped on the page, which presents the possibility of an XSS. I think the person knowleadgeble enough to fix issue 5 might figure out this one too.
13. The code fails to recognize the daylight-savings period [at least on my machine]. It is fixable by adding a timezone specification such as putenv('TZ=EST'). Maybe, however, the problem arised due to misconfiguration of the specific machine where this was observed, I don't know. Can anyone explain?

• Surely there's more...

Releases

• Initial version "1.0beta" released on Jan. 26, 2006.

Comments

• I currently have a series of spam injections, And the disturbing part is that for some reason it sometimes actually works. See an example in this file http://oor.snaaijer.nl/download/spoofed.zip(approve links) it contains the source of a generated page on my site and the contents of the database. Ivar Snaaijer 2006-11-05 11:37
  • The CommentDb script is independent of most PmWiki machinery when accepting new comments. That is, the posted comment gets immediately saved to the database, without being checked for linkspam, approved urls or whatever else. When the comment is displayed it gets through PmWiki filters which adds the "approve urls" links, which might leave a wrong impression as if the UrlApprove machinery would actually be respected by CommentDb. It is not. (Why? As I've noted above, I've just been too lazy to implement it because I don't really know the insides of PmWiki well enough and I didn't need linkspam protection in my case).
    There are at least two solutions to the problem:
    • If you are well acquainted with PmWiki details, you could filter the posted comments through the UrlApprove procedure (or a slight modification of it). This should count the "unapproved" links and prevent the post if there are too many.
    • Otherwise you might hack up your own similar solution. Ideas like preventing comments containing more than 5 links, preventing more than 3 posts from a single IP in a minute, preventing posts with blacklisted words in a link or simply blocking certain IP-s might be easy to implement as well as good enough for your site.
      In fact, as long as CommentDb is not at all used widely, it's reasonable to assume that there won't be linkspam bots smart enough to know about it. So simply preventing comments containg "a href" html could be the best and the simplest option.-KT, 2006-11-06
  • I solved it by changing the script to check the author field for http (it gets ignored if this happens) also I clear the comment of the characters "<" ">" "/" and ":" this will render any injection totally useless but still allow for internal linking. Ivar Snaaijer, 2006-11-06
• I have created a new version that uses a simple bayasian filter to detect spam. commentdb_1_1b.phpΔ
  • information about an extra table is in the file, there is also an extra column called `score` smallint(6) in the comments table
  • $CdbSpamScoreDiscard (default 10) Score needed to make entry disapear completely (/dev/null !).
  • $CdbSpamScoreHold (default 3) Score needed to put the entry on hold (only visible from Site.AllRecentComments)
  • $CdbSpamScoreTable (default 1) Set this value to 1 to use the 'nasties' table, set to 0 to turn it off
    • this is not a dropin replacement even with this value set to 0. When the vaule is 0 the script will only count url's.
  • scoring in the 'nasties' table can be set to a negative value to allow white-listing.

Ivar Snaaijer, 2008-02-03

See Also

• CommentBox

Contributors

• KT

* (+) Optional positive comment. Name, date
* (-) Optional negative comment. Name, date