Simple Comments Release Notes: v.920 (1/2)

[next]

Simple Comments Release Notes: v.920

By Dan Ragle

[This is a release bulletin for the Simple Comments script. For general information pertaining to the script, including the latest release download, system requirements, etc., visit the Simple Comments main page.]

Welcome to a new release of Webref's Simple Comments, a Perl-based system that allows you to add a talkback facility to the static Web pages of your Apache-based site. This version of Simple Comments adds a single significant new feature as well as several smaller enhancements and adjustments.

Replies Supported

First, the significant new feature: With this release, Simple Comments now supports the ability to reply to a previously posted comment.

Of course, a person could always post their reply to a person's comment, but in past versions of Simple Comments the reply would not be tied in any way to the original comment. Since Simple Comments allows administrators to approve comments before they are displayed on the site (i.e., because there may be a time delay between the time you submit your comment and the time the comment actually appears on the site), other comments may sneak in between the original comment and the reply that you posted; creating a potentially confusing layout. For example, consider this collection of comments:

Without reply-tos, comments are posted sequentially

Clearly comment 3 is an answer not to comment 2, but instead to comment number 1 (and I don't know what comment 2 is related to). In previous versions of Simple Comments, all comments were always displayed seqentially. With version .920 users can reply to an existing comment; and that reply--provided the administrator has configured the system to allow it (more below)--will appear beneath the related comment. Here's what the same set of comments would look like in the new version:

With reply-tos, comments can be posted with the comments they pertain to

Note that an unlimited number of reply-to levels is supported, though the default display template will only differentiate (by indenting) 5 levels of replies. Of course, since you can modify all templates, you're free to support any level of comment indentation on replies (up to the limits of your CSS imagination). More on that below.

Multiple new parameters and template features work in combination to allow this new functionality:

• threaded_display: The threaded_display parameter, located in the configuration file, turns the specialized comment sorting for display on or off. i.e., if threaded_display is set to 1, then comments will automatically be sorted such that replies will be listed below the comments they pertain to, as in the second example above. Further, the thread_level indicators, described below, will be passed to the display templates for use in CSS styling of the comments.

  Comments can still be sorted in reverse order (via the recent_comments_first parameter in the configuration file) when threaded displays are active. With recent_comments_first activated, each individual level of comments is sorted with the most recent comment first. In other words, the top level of comments (i.e., the "thread starters") are listed with the most recently posted comment on top; with the most recent reply to it listed immediately beneath it, and so on.

• reply-to: The default display template now includes a reply-to button, allowing users to indicate that their reply is related to an existing comment. This is facilitated via the script's passing a "reply-to" parameter to the display template, along with the relevant form in the display template to facilitate the reply. This reply-to field is then passed as needed to the review template and the comment add template, both of which additionally pass the name, subject and date of the original comment (the one being replied to) to reinforce to the user what's happening:

  
  The submission form now has reply-to fields

  If you want, you can also use a simple link in the display template to facilitate replies; i.e., in that case the user would reply to a comment by clicking an actual link instead of the reply button of a form (the link is passed to the display template as reply_href). Be warned, however, that these links can get quite long; it's probably safer to use a reply button with POST processing (which is the default in the templates provided) for replies.

• thread levels: The display template additionally now receives "thread level" indicators, numeric identifiers that the template can use to separately style each "level" of the thread. For example, the top level of comments (i.e., the thread starters) will be thread level 1. Their immediate replies will be thread level 2; while grandchild replies will be thread level 3, and so on. In this way, separate CSS classes can be defined for each thread level, allowing for replies to be indented, separately colored, etc. Additionally, a set of boolean thread levels is also passed to the display template, which designers may find easier to work with in certain situations. For example:

  <TMPL_IF NAME="threadlevel1">
     styling for top level comments goes here
  </TMPL_IF>
  <TMPL_IF NAME="threadlevel2>
     styling for second level comments goes here
  </TMPL_IF>

One caveat with the new reply-to feature. If you delete a comment that has replies, then all of the comment's replies (and all of their replies) will be deleted. Since this could result in the deletion of many more replies than you intended, a special warning screen will be displayed and you must approve the deletion before the administration script will continue. This warning will only be displayed if at least one of the comments you had marked for deletion did, in fact, have a reply.

What Else Is New?

Other new features, in no particular order, include:

• Subjects: Users can now optionally submit, and the display template can now display, a subject for each comment. The subject can include the same types of HTML as the comment text itself; and it can be styled in the display template in any manner you require.

  A max_subject_chars parameter can now be specified in the configuration file, which indicates the maximum number of characters allowed in the subject line.

• Admin Flag: Within the administration script, a comment can now be identified as having been submitted by an administrator; i.e., a flag can set on each comment that indicates the comment as one that was submitted by an administrator.

  This flag is called "Admin Flag" only because that was the original use for which it was requested. But note that it could theoretically be used for any type of true/false flag that you wish to track on a comment-by-comment basis. The users themselves cannot actually set the flag (it is false by default on all newly submitted comments) and its actual label in the XML files is never seen by the users. Hence, by changing the description of the flag in the default display template, you can change the meaning of the flag entirely. In our default distribution, comments that have been flagged as from an admin get the word "Admin" displayed next to the submitter name in bold. The admin flag can be set for each comment as it's approved, or on individual comments in the adminsitrator's comment edit template.

• Ban IP: Also within the administration script, the administrator can now flag the IP of a particular message to be automatically banned when it (the message) is deleted.

  
  You can ban IP addresses as you process comments

• Comment numbers: Each comment will now have its own unique (per page) comment number, that can be displayed and/or referred to in the comment display template. This number will remain consistent for the life of the comment; i.e., even if the comment is deleted, no further comments on that same page (or more specifically, the same article key) will receive that identification number.

And, of course, a few bugs were also exterminated with this release of Simple Comments. The most prevalent of these are:

• White space in <pre> blocks was not always correct when displayed in Internet Explorer. In previous Simple Comments releases, we used embedded <br> and <p> tags to space out individual lines, but IE appears to ignore the <p> tags, so blank lines in <pre> blocks were not represented as such. To (hopefully) eliminate this problem in .920, we're reformatting <pre> blocks to include actual line breaks when they're displayed, instead of relying on embedded <br> and <p> tags.

• In previous versions of Simple Comments, the block IP functionality wasn't working as advertised; and in fact, only the last IP address listed in the block IP file would actually be blocked! Chalk this up to a missing chomp directive; as the IP addresses were being compared to the IP address in the file with their trailing EOL characters, and were therefore never matching the IP supplied from the user's communications. The chomp has been replaced and the block should work properly now (note that any existing IP addresses you've already included in your block IP file should now be blocked properly).

• A potential security error or script error (depending on version) was present in our use of Digest::MD5 for the implementation of password protection (for those implementations that could not utilize server-based authentication). This has been plugged, and detailed information pertaining to the problem can be found on the next page.

That pretty much sums up the new features, changes, and bug fixes in Simple Comments version .920. On the next page, we examine our Digest::MD5 problem in more detail, and explain why you might have similar problems in your own Digest::MD5 based scripts if you haven't accounted for it...

[next]

Created: December 26, 2006
Revised: December 26, 2006

URL: https://webreference.com/programming/perl/comments/v.920/index.html