Simple Comments: A Basic Perl-Based Comment System for Static Web Pages

dingesmeukzooi

Thu, 05 Feb 2009 09:45:14 GMT

thanks dudes, it works perfect on my webste!!

Dan Ragle

Fri, 19 Dec 2008 14:09:37 GMT

Hi Dale,

For now, this is free software, to use as is (no specific software license). We retain the copyright and ownership. I cannot promise that it will always be free; but it is so now (as of v.962, on 12/19/2008).

License? - (Dale)

Thu, 18 Dec 2008 23:28:29 GMT

What licnse this script is offerd under?

Dan Ragle

Mon, 01 Dec 2008 14:20:46 GMT

Good info, Jonathan. Thanks for the feedback!

Jonathan

Fri, 28 Nov 2008 03:37:29 GMT

Yes, the Akismet API is free to use. I'd personally prefer a locally-installed boolean filter, but since it would take time to learn, using an already-running system such as Akismet is better, I think.

You've a good point about spamming the system with someone else's email address. That's a good idea placing it within the registration form.

And the idea that a forced Review blocks spam came from Textpattern. That system requires a preview before submission, and spam on Textpattern blogs is usually considerably less than on, say, WordPress.

People whose blogs I've read who use the Akismet plugin on both systems have noticed spam volumes coming through the Akismet plugin sometimes many hundreds of times higher on the WordPress system than on the Textpattern system. And the only difference in the comment form is the forced preview. May be fuzzy logic, though.

Dan Ragle

Thu, 20 Nov 2008 18:22:51 GMT

Hi Jonathan,

Feature requests are welcome, though admittedly slow going these days as I haven't had an abundance of time to work on this project. Akismet has been mentioned before (as has mollum.com) and probably deserves another look. Do you know if Akismet offers any free-level of service for their product? As I recall that was the main reason I shyed away from them initially, I don't remember seeing any free service levels. I think E-mails have also been suggested in the past; but one of the potential problems there is spam-abuse (i.e., a person could submit using their "buddy's" E-mail and then subscribe them to all posts from the article). So, I would probably have to tie the E-mail subscription into the user-registration features (at least that way the user has to confirm their E-mail address before they can subscribe). Worth looking into, but again, I don't foresee any quick implementations.

As far as forcing a preview, I'm not sure what you're getting at there. You could theoretically just remove the "Add" button from the submission form, and then alter the Review template to include a copy of the submission form WITH the "Add" button. But ultimately, that won't stop bots; which are smart enough to figure those types of things out, anyway. Or perhaps I've mis-understood your request?

Cheers!

Feature Request - (Jonathan)

Thu, 20 Nov 2008 17:40:00 GMT

Any way to integrate a couple features?

* Something like Akismet for spam protection (CAPTCHA's have been cracked recently)
* A check box to subscribe to comments via email (could use the system's sendmail)

Also, how would I code the form to require a comment preview before being submitted? That has a twofold benifit of reducing thoughtless comments, and reducing spam.

utf-8 support - (Dan Ragle)

Mon, 29 Sep 2008 14:34:31 GMT

Hi Vladas,

The script is admittedly lacking when it comes to utf-8 support. Part of that is the result of my own shortcomings in regards to utf-8 knowledge; the other is knowing that Perl 5.6--which I wanted to make sure I supported--was itself not completely solid in regards to utf-8 support. So, I have no doubt you will run into utf-8 related problems. I would like to go back through and add in more thorough support for utf-8 at some point in the future, but can't say for certain when that will be.

In the mean time, the problem you mention with the article names is most likely the result of some HTML entity encoding that in retrospect probably isn't necessary. At least the angle brackets need to be encoded, but other things probably do not. In Comments.pm, find the get_article_name function, and change this:

HTML::Entities::encode_entities($title,"\200-\377<>");

to this:

HTML::Entities::encode_entities($title,"<>");

If that doesn't work, and you're running perl 5.8 or later, you might also try forcing the HTML file found to be read in as utf-8; i.e.:

open (my $fh, '<:utf8', $config->{'webroot'} . $title)

This, of course, assumes that the file is originally encoded in utf-8; if not, you may need to force the encoding to be whatever the file actually is. If you're running Perl 5.8, then I believe Perl will internally translate the read-in input to utf-8; but it still needs to know for certain what the file was encoded in in the first place to know how to perform the translation.

Good luck!

Vladas Palubinskas

Fri, 26 Sep 2008 21:10:01 GMT

Yes, that helped! Now unicode applies to generated pages fine!

Only cites like <TMPL_VAR NAME="article_name"> remain garbaged by double-byte letters, e.g. Å¡ Å³ (Å¡ Å³). Perhaps I should switch off HTML entities somewhere? What is the reason not to set UTF-8 for the entire application?

Thank you very much for your help and for the nice architecture of the not so Simple Comments!

Dan Ragle

Fri, 26 Sep 2008 13:43:49 GMT

Hi Vladas,

That's probably coming from the CGI module; i.e., the CGI header function will default to ISO-8859-1 unless told otherwise.

If you're having this trouble with Simple Comments, you should be able to rectify it by finding the header calls and adding the optional charset parameter to them; i.e.,

$cgi->header(-charset => 'utf-8');

$cgi->header(-cookie => $cookie_data,
             -charset => 'utf-8');

etc. Unfortunately, there are many of them to change; since I had to add in multiple potential exit points in the OpenID logic. I'll look at making that a configuration option in a future version of the script.

Theoretically, you should also be able to add a META HTTP-EQUIV in your page output; but I think I would personally rather see it directly in the header, too.

And if you're having trouble in one of your own projects, I can only recommend finding the header() function for your CGI output and adjusting accordingly.

Best of luck!

HTTP overwrites UTF-8 - (Vladas Palubinskas)

Fri, 26 Sep 2008 10:07:47 GMT

Dear Dan, would you catch an origin, why and where ASCII (ISO 8859-1) overwrites Unicode (UTF-8) settings in page headers, even overwrites default Apache encoding. Even after replacing

$p3->parse(*FOO, ProtocolEncoding => 'ISO-8859-1');

to 'UTF-8' in XML/Parser.pm

Nothing aids -- Content-Type: "text/html; charset=ISO-8859-1" in HTTP response header :(

Dan Ragle

Mon, 22 Sep 2008 21:02:11 GMT

Hi david,

1.) Yes, display names can now be forced to be unique. See the new unique_display_names parameter in the config file. So you should no longer need the custom code.

Also note that when you upgrade, you'll need to create the initial xref file--there's an option to do that in the admin script.

See the "Support for Unique Display Names" section in the release notes.

2.) The catch-all hack you're using should still work, I can't think of any reason it wouldn't (but I never actually tried it myself, so....)

3.) Most if not all the templates changed; but many of the changes were the result of adding standard includes for the headers/footers of pages (actually three includes are used). Again, see the release notes for more.

The CHANGES.txt file lists all the files that changed, and it differentiates between those that were changed only to support the new header/footer construct vs. those that were changed to support new functionality. I know it's a pain, but you'd pretty much have to compare what's there to what you have to determine if a change is necessary to your templates.

And of course the CHANGES.txt also lists all the config parameter additions and new template additions as well.

Good luck!

upgrade issues - (david)

Sat, 20 Sep 2008 02:53:57 GMT

Hi Dan, I am probably going to upgrade my v95 to v96, basically to ensure that registered but not confirmed visitors cannot comment. Just a few questions:

1. I have implemented your "off the top of your head" solution to ensure that display names are not repeated. Has this been incorporated into v96? If not, will using your proposed code cause any problems?

2. I have also used your proposed code to create a catch-all comments page. My question is the same as above.

3. Most of the templates have been heavily customised. Is there any template I need to "update" to use v96?

david.

Dan Ragle

Mon, 15 Sep 2008 14:49:08 GMT

(http://mollom.com/download)

Looks interesting, hadn't seen it before but just gave it a quick glance. Looks similar to Akismet, yes? I see there's a free-level of the service (up to 100 legit message posts per day), and the spam filter/visitor reputation checks could be beneficial. Do you know if the CAPTCHAS can be selectively disabled per account? It may be more beneficial from a Simple Comments perspective to just get the score results (from content and visitor reputation analysis), and then decide if we need to present a captcha locally based on the score. But mostly I'm just thinking out loud here...

Quick FYI - (Phillip Smith)

Mon, 15 Sep 2008 14:27:43 GMT

Wonder if this might be a useful option for a future version? http://mollom.com/download