create new tag
, view all tags

CommentPluginDev Archive


I have the solution for (clearing the text box when clicked). I stole code I found on: http://forums.devshed.com/f1/s.html I have extracted the relevant code. %INITIAL_TEXT% is the text you want to see in the box.

<form name='form_search' method='get' action='index.php'>
  <textarea name=comment rows=8 cols=50 wrap=soft
   onfocus="if (this.value=='%INITIAL_TEXT%') this.value=''"
   onblur="if (this.value=='') this.value='%INITIAL_TEXT%'"

See the above code in action at: http://nahaboo.org/tmp/test-js.html It works with linux Mozilla and Opera, so it should be fairly cross-browsers.

-- ColasNahaboo - 01 Oct 2003

I made a feeble attempt at reading the above but have given up, and decided to attempt a (minor) refactor by asking question(s):

  1. Background (and leading up to spitting out the question): "We" are considering setting up a TWiki for the Linux Documentation Project (tldp.org) (initially, I will put some pages on Wikilearn). There is (as is common with a wiki) some concern about vandalism. It might be nice (at least for some (paranoid?) HOWTO authors) if we could disable write access to a page (except for the HOWTO author and perhaps an LdpAdmin group), yet still allow comments by anyone.

  1. Is it possible to use the comment plugin (without authorization) to add comments to a page which is write protected? (i.e., with DENYTOPICCHANGE or similar set)

Oops, wait, maybe that's answered in or near the last previous comment. I'll save this and then make a renewed effort to read that section.

Ok, I'm too impatient, if somebody can answer the question I'd appreciate it, otherwise I'll try rereading again later.

-- RandyKramer - 21 Nov 2003

I'll refactor sometime ... not now.

  • re Q1: COMMENT uses savecomment script (not save as editing does) - just do not require valid user. you can see it in action here
  • re Q2: register in my test Twiki above and try it smile
  • Quickest way to contact me is via #twiki channel on TWikiIRC. Please email me if you need answer quick, and I am not on #twiki.

-- PeterMasiar - 22 Nov 2003

Peter M: What is the status of this Plugin? Any timeframe for releasing a new version that incorporates the Beta features and above fixes?

-- PeterThoeny - 25 Nov 2003

And what are the final installation instructions?

I installed v. 1.1. in Win2000 Prof. and couldn't overcome the "The server encountered an internal error or misconfiguration and was unable to complete your request.", while the log file informed:

"[Wed Nov 26 15:08:36 2003] [error] [client] (2)No such file or directory: couldn't spawn child process: c:/twiki/bin/savecomment"

So, I replaced the files with those of v. Oct02, and it does'n work at all - even the page of PluginComment can't be opened (without timeout error - Mozilla).

-- AndrzejGoralczyk - 26 Nov 2003

This Plugin is important and should go into the TWiki releases.

I believe it is better for the TWiki community if the Plugins repository at TWiki.org remains the central place for Plugins. Together we are strong, a fragmented community is week. Peter Masiar, do you intend to maintain this Plugin here on TWiki.org? If not, anyone else interested to take over the maintenance?

-- PeterThoeny - 09 Dec 2003

I have ben trying to get the comment plugin to work and have had a variety of problems. If anyone could shed some light, it would be appreciated!

with v. 1.0: a) %COMMENT% doesn't get proper default values

with v. 1.1: a) CommentPlugin page won't render (looks blank) b) %COMMENT% doesn't display a box

with v. 2.0: a) the REFRESH value always shows up, no matter if you click refresh or click on a link to get to the page b) Comments that are added in the box still have '\n' in place instead a line break. c) CommentsPlugin doesn't show up in the Plugins Lists


-- AndrewJMirsky - 14 Dec 2003

Can the authors, or anyone else, comment on the status of this plugin? Does it work? Does anyone feel ownership? Or is it what is seems; lost, alone, unloved and adrift?

I'm just going to have a look at it in detail, so I may answer some of my own questions; I'll post what I find out here.

-- CrawfordCurrie - 06 Feb 2004

Crawford - I do have Peter Masiar's version 2 working on my TWiki 18 Dec 2003 release. I had a brief email exchange with Peter a few days back and he's occupied with other things right now so this plugin is semi-orphaned but much-loved. Peter's version has some very nice functionality but is pretty rough in it's design. I personally consider this one of the most important plugins and would love to see it get some attention. Just today I was thinking that if someone else didn't do it, this would become the project where I have to start learning perl. And that's a frightening thought (at least for the plugin's prospects). smile

-- LynnwoodBrown - 06 Feb 2004

Everybody, but especially Peter Masiar; sorry, I have no confidence in this plugin so I took an executive decision to clean it up so I (and others) can use it. I have rewritten the front page to be readable, and made minor code improvements. I have also checked the latest version into CVS. It's a great plugin, and a crying shame to let it go to waste.

-- CrawfordCurrie - 07 Feb 2004

Based on chatting to Peter Masiar in the past I'm sure he'd be very pleased that someone's taken it on board again. I was confused by PeterThoeny's complaints about this plugin when he decided to not include it as one of the default plugins - the comment plugin is by far a) one of the most popular plugins with end users b) is a very wiki concept - most other wiki's these days have this functionality, c) solves the problem that many users don't want to go through registration hoops just to add a comment/correction.

I personally, didn't use Peter Masiar's code for the customisable UI I use in our comment plugin, preferring to pull in paramaterised named sections instead. (Which makes the UI for the comment plugin per user customisable) I also didn't particularly like his syntax for templates, but that's a personal viewpoint, not anything against the plugin.

-- MS - 07 Feb 2004

I haven't studied the code yet, but on first glance at the documentation, the "{...}" syntax instead of "<...&gt&;" sure is annoying. Crawford, since you just went through this plugin, could you explain the reason for this? I take it has to do something with that you want to see the "template" in the rendered topic?

  • The purpose of the { } syntax was so that user's could enter arbitrary HTML for the templates that looked the same both on view and on edit. Peter discussed several times about the possibility of a <nohtml> type container whereby templates defined within those would be rendered the same way in both edit and view. In the end he decided on { and } as a compromise of speed and simplicity versus what he actually had time to write. It's not pretty, but to be fair it's not that much worse than seeing HTML tags really, and certainly no worse than %TWIKI{"style" markup="tags"}% -- MS - 09 Feb 2004

-- ThomasWeigert - 07 Feb 2004

Yes, I think the {...} syntax was a solution for a perceived "get your head round it" problem; viz that when you view the CommentTemplates topic, if you use &lt;&gt; the HTML gets interpreted and you see forms etc, but if you use {...} it appears as written. A weak rationale, I know, but I can't think of any other reason. I very nearly changed it - my initial reaction was the same as yours - but left it alone in the interests of continuity (and time; I spent a total of 75 minutes on this plugin so far frown ).

Something which isn't entirely clear to me is the precise sequence of evaluations i.e. when variables get expanded. If I can work this out I'll document it and maybe we'll be able to use %URLPARAM in the templates - which would give the power to pass a whole lot more down through the invocation chain.

An earlier comment, from PeterThoeny I think, was that the "savecomment" script is spurious. I thought so too, at first, but on inspection I'm not so sure any more. Anyway, I just don't think it's worth the effort to remove.

I'm kinda assuming that PeterMasiar addressed everything else reported before the release of his V2.0, though I can't be sure.

Michael: "our comment plugins"? "parameterised named sections"? I'm assuming you are meaning that O'Wiki has a comment plugin, that never found its way back to support TWiki. [...] what's a "parameterised named section"? If O'Wiki has advanced the art (as it is supposed to do) I really don't want to be dragging it back into the neolithic again.... (Some aspect refactored to CoffeeBreak -- ThomasWeigert - 08 Feb 2004)

-- CrawfordCurrie - 07 Feb 2004

> And what's a "parameterised named section"?

Named includes that support parameterisation (well all includes do, but that's a special case). Used throughout owiki.org to result in heavy customisation that allows end users to change the entire look, rather than a systems admin. (eg http://owiki.org/ uses exactly the same skin as http://owiki.org/Community/. The only difference is a single "furniture" page. Having alternate format, parameterised comments is a trivial addon after that.)

(And yes, the include functionality is too bloated, at some point I'll be ripping that out to plugin level. Currently it's still too intertwined.)

-- MS - 07 Feb 2004

Michael, could you point us to an example in OWiki of the use of the comment plugin and the parameterized named sections. It is difficult to find it by just poking around. I looked a little yesterday without much luck.

  • Owiki:CHAOS, Owiki:OffTopic, Owiki:SiteNits, OWiki:Scratch/ParameterisedSectionComment. The first two examples actually also dump down sectionedit tags eitherside of comments as well, making it so that the comments can be re-editted or specifically commented on afterwards. This is particularly used in the three first examples given. At work I use a slightly different format for other purposes. -- MS - 09 Feb 2004
-- ThomasWeigert - 08 Feb 2004

Michael, I think I understand. While I don't particularly like the current approach, I don't see a huge advantage in moving away from it at this point - unles you can sell me (be bothered selling me) on the advantages.

-- CrawfordCurrie - 08 Feb 2004

BTW, I haven't seen this comment here before - highly popular application of this plugin:


I've not seen a smaller application cause as much of hit in any group of people. (Not even TWikiDrawPlugin - which I still really like)

-- MS - 09 Feb 2004

Further thought that I missed earlier - the idea of subsuming the save functionality of the comment plugin into the save script misses a very useful trick of the comment plugin: AnonymousDonors, and Wiki:SoftSecurity via a TrollGroup.

Many wiki users balk at the idea of being forced to register in order to leave a comment. It's heavily outside the realm of expectation. Some users are working in environments where they would like to say things that they can't normally say because they're afraid "the boss" will read it and call them to account. Or maybe they have an idea they think is probably stupid, but might not be.

Installing savecomment without requiring authorisation solves many of these problems - since users can then leave anonymous comments. AnonymousDonors feel comfortable - they have a comment and bam it's there. People who end up in the TrollGroup can be denied editting, but allowed a right to reply via commenting on pages with comments. (essentially their power is caged) Furthermore, the any user can release someone from the TrollGroup if they think appropriate. They can think twice however since any user can place them in the TrollGroup - thereby encouraging Wiki:SoftSecurity.

This then means that the admin of a site can loosen up on who can edit & change TWikiPreferences and WebPreferences since there's an easy place to put someone if they're accidentally breaking content. Or start making enmasse changes without community support. It also moves the relationship between those who "run" a wiki and those who "use" a wiki back onto a more even keel - moving back to a relationship of trust. ("We trust you not to break our forms, our preferences, etc")

Another use is in blog type scenarios - you can run a personal web whereby only a specific group of people can edit articles (think slashdot), but anyone can reply (think slashdot). You don't get the rating aspects of how good/bad comments are, so this doesn't scale to slashdot levels of users, but it does work pretty well.

All in all the social benefits of the CommentPlugin can be very, very high.

-- MS - 09 Feb 2004

Michael, yes, a very good thought. However the same thing can be done with a simple "cp save savecomment" in the same way as is done for the EditTablePlugin. The advantage of eliminating the savecomment script is purely and simply code reuse - nothing else.

I love the calendar application; I'll add it to the CommentPlugin topic as an example of use.

Oh, and none of your owiki links work (as of 09.33 GMT 8/2/04)

-- CrawfordCurrie - 09 Feb 2004

Crawford, thank you, thank you, thank you, thank you for maintaining this important Plugin! It has been neglected for a long time. With you it will be in good hands smile

At work we use this Plugin (an early version) and did a lot of bug fixes, some are listed here on top.

When reworking this Plugin I suggest to keep this in mind:

Some organizations want a complete audit trail, that is no anonymous comments. In other cases, anonymous comments are more appropriate. A site-level switch can address this.

Doc bug? The {COMMENT} seems is documented in the INPUT template, but should move to the OUTPUT

Suggestions for CommentTemplates topic:

  • Use %TOC{ depth="1" }% on top. That way you can simplify the ---++ !!before:INPUT syntax to ---++ before:INPUT
  • As noted by others get rid of the {} syntax. How about using the simple template syntax of the SlideShowPlugin? That, use HTML "as is" for a WYLAIWYG (what you look at is what you get) and use %CMT:SOMETHING% variables understood only by the Comment Plugin (that is not rendered in the template page, but rendered by the %COMMENT{}%).

I suggest to expand the same variables like edit and register does, see ExpandVariablesInEditTemplateTopic. This makes it consistent and less surprizing for users.

That is, how about renaming them as follows:

From To Note
{COMMENT} %CMT:COMMENT% (for ease of use, but see next note)
{URL} %CMT:URL% Why is that needed? Named HTML form fields in INPUT and %URLPARAM{"name"}% in OUTPUT gives you total flexibility
{LINK} %CMT:LINK% (same as above)
{ID} %CMT:ID%  
  %USERNAME% new, see ExpandVariablesInEditTemplateTopic
  %WIKINAME% new, see ExpandVariablesInEditTemplateTopic
{USERNAME} %WIKIUSERNAME% note different name!
  %URLPARAM{"name"}% new
  %NOP% new, see ExpandVariablesInEditTemplateTopic
  %NOP{...}% new, see ExpandVariablesInEditTemplateTopic (could be omitted)

  • PeterThoeny, please comment on what you consider has to be done to make this plugin acceptable for (1) installation and twiki.org and (2) default installation in the release. -- CrawfordCurrie
    • Installation at TWiki.org: Anytime you tell me it is safe to install (reworked syntax as a "nice to have") -- PeterThoeny
    • Default installation: Reworked syntax (request) and get rid of savecomment (not hard request) -- PeterThoeny

-- PeterThoeny - 10 Feb 2004

OK, I made a second pass simplification using the standard template mechanisms and the beforeSaveHandler, which chops the code down to ~100 lines total. However it's quite a radical rewrite, and may be abhorrent to some because the templates are drawn from the templates directory (templates/comment.tmpl by default) rather than from a user topic. Obviously this means they are not user-editable.


-- CrawfordCurrie - 10 Feb 2004

I, for one, have no problems with the templates being in the template directory. This slight disadvantage, in my opinion, is better than the nasty syntax that they have today. Maybe somebody will, in a next release, figure out how to make these things user editable....

-- ThomasWeigert - 10 Feb 2004

Michael, Peter, please don't clutter up this nice Dev page with irrelevancies (look at diffs if you want to see what I mean).

BTW the chop-down resulted in only 4 special variables for the comment templates, for no net loss (a net gain in fact) in functionality.

-- CrawfordCurrie - 10 Feb 2004

I am back. I welcome if anybody will take over this plugin and make it usable. If I would not like new functionality, I can still keep mine. smile

  1. templates in standard editable page: I found that wiki page and not in templates is rather useful - one user created whole new format without even bothering me. So if you get rid of it - I will like new one less.
  2. {} syntax for HTML tags: what is your proposal? I believe flexibility in formatting is rather important.
  3. {URL}: somebody proposed smart javascript magic which can be placed to mozilla toolbar and insert bookmarks as comments into specific pages. To make it work, 3 fields were needed: URL, LINK, and TEXT of comment. I had it half-working before directly from toolbar - and it was even cooler than plain comments.

I am glad if somebody would finally adopt this plugin and put it to standard distro. When and if I'll have time to play with Twiki again, I may dig into it and fork/enhance/whatever. Not now.

-- PeterMasiar

Thanks Peter. The proposal is to use the standard TWiki templating magic (%TMPL:DEF etc). The template has to be in the templates directory, because the Func module only provides the "readTemplate" function to support this magic. Note for core team: If you could readTemplate from a topic, then this problem would go away.

BTW one issue with killing off the savecomment script is loss of the "back-off" strategy described in the CommentPlugin page. The section "Important note regarding locks" would have to be rewritten as follows: The plugin checks if the page is locked for edit. When a locked page is displayed in 'view' mode, comment input is automatically disabled.

Note that if the page was read long time ago, it's possible that page was locked by another user after it was read, and the lock is still outstanding. In this case, comments cannot be saved, and you will be redirected to a "topic is locked" page. You then have two options:

  • Cancel - throw away your comment and return to viewing the page.
  • Back and try to save the comment again later - WARNING some browsers might requery the page and lose your comments - so test how your browser behaves before using the Back button.

To help avoid edit conflict, a reminder to refresh the page before entering comments is the default text for a %COMMENT

-- CrawfordCurrie - 11 Feb 2004

Crawford, you wrote (in red) exactly what I had on my mind. How can you do that? smile Also, I went with {} syntax, avoiding %TMPL:DEF way, because IMHO %TMPL:DEF is horrible, unfriendly and proprietary. If user knows HTML, with {} can just dive in, editing plain pages. YMMV. When you will be done, and I'll have time, I may add {} back - maybe.

-- PeterMasiar - 11 Feb 2004

Peter, could you explain your arguments for the {} syntax. It does not look like HTML at all to me. It is very difficult to make the mental translation. On the other hand, the template syntax is familiar to anybody who is likely to tinker with defining templates for the plugin. The consistency with the twiki template mechanism is very important, in my opinion. However, I am eager to hear your explanation. But to tell you the truth, ever since I first saw the templates for comment plugin, I thought that there was some mistake in the rendering.....

Please let's abandon that grotesque syntax.... I appreciate all the work you put into this plugin, but please accept this input...

-- ThomasWeigert - 11 Feb 2004

I've attached the chop-down to this topic; please download and test, it should work with beta18012004. I haven't written any tests for it yet, so the more you can do to try it out, the better.

-- CrawfordCurrie - 13 Feb 2004

Okeydokey, St Valentine has been, cupid has fired his arrows, and the feature set is frozen for this release.

CORE TEAM it would be much, much nicer if you could _readTemplateFile from user topics, but then you knew that already.

-- CrawfordCurrie - 15 Feb 2004

I just installed version RC1 (13 Feb 2004) and here are some bugs that I've seen:

  • Whenever some change has been made to the page, the notify script gives the following error: Use of uninitialized value in pattern match (m//) at /usr/share/perl5/TWiki/Plugins/CommentPlugin/Comment.pm line 42.
  • Adding a comment puts a lock on the page (even if RELEASEEDITLOCKCHECKBOX is checked). Did I miss some COMMENTLOCK setting? (For now, I added a hidden input field for unlock with value="1" in the comment template file.)
  • When the page is locked, the textarea does not show up correctly and the number of minutes remaining on the lock is invalid.
  • If a comment starts with a WikiName in type=below mode, the WikiName won't be activated until there is another comment entered. I believe this is because there is no space between the % closing COMMENT and the WikiName.

Beside all this, it works great... thanks!

-- PatriceFournier - 16 Feb 2004

Patrice, many thanks for trying it out! I'll address those issues posthaste.

-- CrawfordCurrie - 17 Feb 2004

Crawford, this is really nice. The small bugs I found, in addition to Patrice's above, are as follows: (using tableappend)

(1) If a line break (enter key) is included in an entry, this breaks the table.

(2) If a lot of text is entered in a comment, then the resulting table smushes the signature field in order to make room for the comment field.

(3) The CommentsPlugin page won't let me edit the page at all (e.g. to change the settings). Instead it just appends my signature to the top of the page.

Also, I'm wondering if there's a way to combine this plugin with the section edit plugin...to have comments appended right before/after a < sectionedit > label rather than right before/after the %comments% label. That would make for some very interesting new options.

-- SamAbrams - 17 Feb 2004

Also there may be a conflict with ActionTracker. Just got the following error from actionnotify:

[dreamboat]$ ./actionnotify.cgi 'open' "my" variable $baz masks earlier declaration in same scope at ../lib/TWiki/Plugi ns/LoginNamePlugin.pm line 128. Use of uninitialized value in pattern match (m//) at ../lib/TWiki/Plugins/Commen tPlugin/Comment.pm line 42.

-- SamAbrams - 18 Feb 2004

Arrgh, the only way to fix the table problems is probably to generate full HTML for the table in the template. I used | because it was quick and easy. The first two issues you report would be fixed by this. I don't understand the report on the third.

At the moment the most complicated thing this plugin does is to find the %COMMENT that generated it in the source file! I did think of doing a sort of "include tag" feature; something like "%INSERT_HERE%" which would be filtered in normal topic view, but act as a placeholder for the comment insertion. Would that work for you?

It's not an error, it's a warning. You can safely ignore it. It shouldn't appear with the release.

I'm releasing now.

-- CrawfordCurrie - 18 Feb 2004

Re: your "%INSERT_HERE%" placeholder. BEAUTIFUL IDEA! That would let us insert the text where it makes sense, cleanly. This would be number one on my wish list for the plugin.

Re: the table problem. I'm not personally going to use the table feature; the other features work so cleanly for me. Just reporting the bugs. So unless someone else chimes in, it sounds like a low priority hassle for now.

Re: the TWiki/CommentsPlugin page. I tried to edit this page in order to change the refresh message. There seems to be some extra code, maybe javascript, that won't let any changes to the page be fully saved. (It saves, adds my sig to the top of the page, and blows away the changes.) I'm assuming the refresh message can be modified in the code anyway, so probably not a big deal.

-- SamAbrams - 18 Feb 2004

Crawford, with your Feb 18th release, I am still able to replicate Patrice's page lock problem. When the page is locked, the add comment button gets greyed out, and the following text replaces the textarea box:

"< textarea disabled rows=3 cols=50 name="comment" wrap="soft" onfocus="if(this.value=='You cannot comment as the topic is locked temporarily by SamAbrams for the next 1 minutes.')this.value=''" onblur="if(this.value=='')this.value='You cannot comment as the topic is locked temporarily by SamAbrams for the next 1 minutes.'">You cannot comment as the topic is locked temporarily by SamAbrams for the next 1 minutes."

-- SamAbrams - 18 Feb 2004

Okay, I diagonosed the TWiki/CommentsPlugin page problem...it's a bit more severe than it first seemed. The plugin seems to be interfering with the save.cgi.

Specifically, about half the time I try to edit a page, the edits are lost when I press Save Changes (from the preview page). And a signature stamp is added where the comments would normally go. However, when I remove the CommentsPlugin from my site, the problem immediately goes away.

The problem is also isolated to pages with the %COMMENT% variable.

-- SamAbrams - 18 Feb 2004

Sam, broke your lock, hope I didn't kill anything.

The symptoms you describe suggest that the beforeSaveHandler is getting confused. It sounds like the behaviour I would expect if the form containing the COMMENT was not correctly closed; this would tie in with your report regarding the truncated textarea. I don't know what's causing this problem, but I have a workaround; try editing your comments.tmpl and removing the "onblur" and "onfocus" parameters from the textarea.

-- CrawfordCurrie - 18 Feb 2004

Okay, removing the onblur and onfocus parameters fixed things. And manually editing the plugin page worked as well. I'm a happy camper.

The "%INSERT_HERE%" placeholder is my last dream. smile

-- SamAbrams - 18 Feb 2004

Here is a patch that fixes the remaining bugs I reported earlier...

diff -u -r1.2 Comment.pm
--- Comment.pm  18 Feb 2004 15:36:58 -0000      1.2
+++ Comment.pm  19 Feb 2004 00:29:31 -0000
@@ -53,8 +53,7 @@
       TWiki::Func::checkTopicEditLock( $_[2], $_[1] );
     if( $lockUser ) {
       # Topic is locked by another edit
-      $lockTime = ( $lockTime / 60 ) + 1; # convert to minutes
-      $message = "You cannot comment as the topic is locked temporarily\n" .
+      $message = "You cannot comment as the topic is locked temporarily " .
        "by $lockUser for the next $lockTime minutes.";
     } elsif ( $previewing ) {
       # We are in Preview mode
@@ -112,11 +111,13 @@
       # need to provide text or the save script will reject us; even though we
       # are going to override it in the beforeSaveHandler
       $input .= "<input name=\"text\" type=\"hidden\" value=\"dummy\" />\n";
+      # Do not lock the page
+      $input .= "<input name=\"unlock\" type=\"hidden\" value=\"1\" />\n";
       # the presence of these next two urlparams indicates a comment save
       $input .= "<input name=\"comment_type\" type=\"hidden\" ";
       $input .= "value=\"$type\" />\n";
       $input .= "<input name=\"comment_index\" type=\"hidden\" ";
-      $input .= "value=\"$$pidx\" />\n</form>";
+      $input .= "value=\"$$pidx\" />\n</form>\n";
     return $input;

SamAbrams, could you remember to unlock the page when you're done? smile

I've got more bugs to report, as soon as I finish my tests...

-- PatriceFournier - 19 Feb 2004

Setting the DEFAULT_TYPE to an innexistant value (and using it) will not give the error we see when we specify the wrong type directly, but will show a half parsed comment template.

Now, even if the DEFAULT_TYPE is valid, it still won't work... It seems the getPreferencesValue() function returns the type followed by a space. Is that a bug in getPreferencesValue() (01 feb 2003), in the plugin code for not triming the result or somewhere else?

-- PatriceFournier - 19 Feb 2004

About Sam's line breaks in table problem, I believe you could change the templates to use the newline parameter to URLPARAM. See UrlParamWithNewlineArg. I've not tested as I'm still running 01 feb 2003.

-- PatriceFournier - 19 Feb 2004

Here's another patch... implementing the %INSERT_HERE% type of marker... You can specify any TWikiVariable you want as the marker (You may want to create a new empty variable for this purpose) and use either below or above as comment_type. You specify the marker you want with the following command: %COMMENT{type="below" marker="INSERT_HERE"}% where INSERT_HERE specifies that the marker will be the first %INSERT_HERE% TWikiVariable encountered.

The patch incorporates the previous one...

diff -u -r1.2 Comment.pm
--- Comment.pm  18 Feb 2004 15:36:58 -0000      1.2
+++ Comment.pm  19 Feb 2004 06:06:56 -0000
@@ -53,8 +53,7 @@
       TWiki::Func::checkTopicEditLock( $_[2], $_[1] );
     if( $lockUser ) {
       # Topic is locked by another edit
-      $lockTime = ( $lockTime / 60 ) + 1; # convert to minutes
-      $message = "You cannot comment as the topic is locked temporarily\n" .
+      $message = "You cannot comment as the topic is locked temporarily " .
        "by $lockUser for the next $lockTime minutes.";
     } elsif ( $previewing ) {
       # We are in Preview mode
@@ -81,6 +80,8 @@
     my $type =
       TWiki::Func::extractNameValuePair( $attributes, "type" ) ||
+    my $marker =
+      TWiki::Func::extractNameValuePair( $attributes, "marker" ) || "";

     # Expand the template in the context of the web where the comment
     # box is
@@ -112,11 +113,15 @@
       # need to provide text or the save script will reject us; even though we
       # are going to override it in the beforeSaveHandler
       $input .= "<input name=\"text\" type=\"hidden\" value=\"dummy\" />\n";
-      # the presence of these next two urlparams indicates a comment save
+      # Do not lock the page
+      $input .= "<input name=\"unlock\" type=\"hidden\" value=\"1\" />\n";
+      # the presence of these next three urlparams indicates a comment save
       $input .= "<input name=\"comment_type\" type=\"hidden\" ";
       $input .= "value=\"$type\" />\n";
       $input .= "<input name=\"comment_index\" type=\"hidden\" ";
-      $input .= "value=\"$$pidx\" />\n</form>";
+      $input .= "value=\"$$pidx\" />\n";
+      $input .= "<input name=\"comment_marker\" type=\"hidden\" ";
+      $input .= "value=\"$marker\" />\n</form>\n";
     return $input;
@@ -132,6 +137,7 @@
     my $query = TWiki::Func::getCgiQuery() || return;
     my $type = $query->param( 'comment_type' );
     my $tgt_idx = $query->param( 'comment_index' );
+    my $marker = $query->param( 'comment_marker' );

     # the presence of these two urlparams indicates it's a comment save
     return unless ( defined($type) && defined($tgt_idx) );
@@ -156,8 +162,14 @@
     } elsif ( $position eq "BOTTOM" ) {
       $_[0] .= "$output";
     } else {
+      if ( $marker eq "" ) {
+        $marker = "%COMMENT{.*?}%";
+      } else {
+        $tgt_idx = 0;
+       $marker = "%".$marker."%";
+      }
       my $idx = 0;
-      $_[0] =~ s/(%COMMENT{.*?}%)/&_embed($1,\$idx,$position,$tgt_idx,$output)/ego;
+      $_[0] =~ s/($marker)/&_embed($1,\$idx,$position,$tgt_idx,$output)/ego;

Hmmm... How long a patch is too long to embed in the discussion?

-- PatriceFournier - 19 Feb 2004

Patrice, if a patch is too long, save it to a file and attach it instead of embedding it. I would say the patch above is just on the upper limit.

I incoporated your first patch, but not the second, because I already found what I think is a nicer way to do the same thing. Instead of %INSERT_HERE% I used standard TWiki anchors; so if you put "#CommentHere" in "Myweb.MyTopic" and then %COMMENT{target="Myweb.MyTopic#CommentHere" type="below"}% it inserts the comment relative to the anchor. This has the double benefit that the anchor can be used as a target in other URLs as well. Apart from that our code is pretty similar (great minds etc). I thought about removing the "relative to the %COMMENT" capability, as it is rather to complex to explain for my tastes, but in the end I left it in.

I also found a bug that neither of you spotted; the lock check was being performed on the topic where the %COMMENT was, and not the topic where the resultant comment was targeted. This may have been the cause of Sam's problems, but I don't really think so; that one is still mystifying (and worrying) me so I'm going to write some more tests before I post again.

Patrice, Sam, thanks for the terrific input!

-- CrawfordCurrie - 19 Feb 2004

I just had a quick look, not into details. Feedback:

  • Bug: raw html is shown when writing simply %COMMENT{ }%. It should show a box with defaults
  • XHTML: Make it compatible, e.g. <textarea  rows="3" cols="50" ... instead of <textarea  rows=3 cols=50 ...
  • Plugin seems to have lost protection against access setting attacks. Filter out any attempts to add access settings. Old code:
    my $errMsg = '<font color="red">(attempt to change authorization settings detected)</font>';
    $comment =~ s/\s*\*\s+Set\s+(ALLOW|DENY)(TOPIC|WEB)(CHANGE|RENAME|POST)\s*.*/$errMsg/go;=

The %COMMENT{target="Myweb.MyTopic#CommentHere" type="below"}% syntax pointing to named anchors is powerful; it could open up potential issues where a comment is added to the wrong place by mistake. This can be prevented if the user needs to type some text for the target, like %COMMENT{ name="CommentHere" }%. Just a thought.

In all, great enhancements!

-- PeterThoeny - 19 Feb 2004

The "raw HTML" problem was probably the previously reported issue with the default type. Try with the latest upload, which also contains the anchor target implementation (and the XHTML corrections in the template). Settings attacks: the way it now works is to expand URLPARAMs when writing the topic, and it knows nothing about the actual fields used. I have changed the default templates to defend against this by using the newline parameter to URLPARAM and prefixing a nop on the inserted text, but local templates could always open up this risk again.

As for targeting anchors; I think the scenario you describe is pretty unlikely, and the attraction of being able to jump straight to the insertion point by referring to the anchor is really nice.

-- CrawfordCurrie - 19 Feb 2004

Just downloaded the new version to look at the changes (CVS repository is not yet updated?), not yet tested it. You didn't remove the $lockTime = ( $lockTime / 60 ) + 1; line as my first patch did... isn't $lockTime already containing the number of minutes remaining on your TWiki installation?

I'll test it later tonight...

-- PatriceFournier - 19 Feb 2004

Sorry Patrice, I had a priority interrupt; the fence posts I needed to repair my fence (blown down in the recent gales) arrived, so I've been digging holes all afternoon - very therapeutic.

Yes, I missed that aspect of your first patch. I just checked and you are right (another piece of code I inherited, that one). I'll update CVS now.

-- CrawfordCurrie - 19 Feb 2004

Just finished some testing. Here is some feedback:

(1) For the life of me, I can't get the anchor working.

If I type %COMMENT{target="SamAbrams#TheAnchor" type="below"}% into a page, and then put #TheAnchor somewhere down lower on the page, nothing happens when I submit a comment. If I take out the two references to #TheAnchor, then the plugin works normally.

(2) My preference would be for the anchor to be modifiable, at least to skilled hands.

For example, I'm trying to combine the comment plugin with the section plugin. I'm going to hide the % COMMENT () % call in an uneditable section of the page. I'd then like the comments to be written into an editable section of the page.

To do this, I'd need to modify the anchor to be "< sectionedit >", otherwise I'd need to stick #TheAnchor into the editable section of the page. For me, one of my more unskilled users will undoubtadly delete #TheAnchor.

(3) The insertion of < nop > before each comment is a buzz kill. As you can see from (2) above, I'll have to explain to my users what < nop > means.

I can customize the plugin for my site, but others may benefit from these features as well.

-- SamAbrams - 20 Feb 2004

A "nice to have" is parameters compatible with the old Plugin syntax. That way existing installations do not need to search 35K pages to fix the comment syntax. This could be an undocumented feature. Here is the old doc:

  • rows: Any number > 0 will set the rows of the text area (default is 5)
  • cols: Any number > 10 will set the columns of the textarea (default is 70)
  • mode: The word "after" tells Comment to put the posted data after the form in reverse chronological order (default = "normal" chronological order)
  • button: This lets you change the text of the submit button (default is "Add Comment")
  • id: This gives a unique name for a COMMENT, in case you have more than one COMMENT tag in a topic (mandatory with > 1 COMMENT)

-- PeterThoeny - 20 Feb 2004

Crawford, I just put in a fresh copy of the plugin, and blew away all my other plugins to avoid conflicts. The result is the same as I reported earlier:

  • Specifically, about half the time I try to edit a page, the edits are lost when I press Save Changes (from the preview page). And a signature stamp is added where the comments would normally go. However, when I remove the CommentsPlugin from my site, the problem immediately goes away. The problem is also isolated to pages with the %COMMENT% variable.

Previously you suggested removing the onblur and onfocus parameters in the template, which worked. Those parameters are no longer in the template, so I'm at a loss for other things to try. Sorry I'm not making this easy on you.

Previously you mentioned the SaveHandler as a possible culprit. Are there any specific files related to this handler? I can then try uploading a fresh copy of these files, to see if it makes a difference.

-- SamAbrams - 20 Feb 2004

Sam, thank you, yes, there was a problem with the anchors. Latest zip fixes. Apologies for rushing things last night.

Your other problem is a mystery to me. If I try to explain the logic perhaps something will spark. In a topic with a %COMMENT in it, the COMMENT gets expanded to a form. This form has two hidden parameters. When the topic is saved, the beforeSaveHandler recognises those two hidden parameters and takes their presence to mean that we are doing a comment save. In this case it throws away the text being saved, rereads the topic and puts in the comment.

This is all consistent with what would happen if the URL generated when the "Save Changes" button is hit also contains the two hidden parameters. It shouldn't, as it's part of an entirely different form, but the browser may be getting this wrong. Alternatively, if the form and /form tags in the %COMMENT are being munged, the form may not be closed and the parameters are getting stuck in anyway. The preview page has a clean separation of the forms (unless Sam changed his templates; did you, Sam? what skin are you using?).

Reviewing the preview page there is clearly one thing being done wrong in the plugin; the forms are generated even in preview mode (how does a rendering handler know you are in preview mode?). The inputs need to be more than disabled; they need to be crippled. Renaming them would work.

Conclusion: Sam is a victim of a browser bug combined with some sloppy coding. We can fix the coding...... Sam, watch for an updated zip.

In terms of targeting something other than anchors; I rather like targeting anchors, it's elegant and simple. However ..... goto CommentPluginDev

All the things that you thought were fixed (in one version or another) but seem to have got lost.

  • JosephWang's version had the ability to post the comment to a different topic. -- LynnwoodBrown - 07 Feb 2004
    • Something that is needed. For a simple fix see my post dated 08 Nov 2003 -- PeterThoeny - 10 Feb 2004
    • Again, feel free to rip this code out of my code as well. (I wasn't aware that JosephWang had done this as well.) For contrast, I took the approach of defining a target - not all %COMMENT% tags defined a comment box. Logically they normally define a source (comment box) and a target. I allowed the two notions to be seperated out. -- MS - 09 Feb 2004
    • implemented in the chop-down

All the things this plugin should be able to do, but can't.

I'm working on the assumption that we are looking for a fully-feature blog plugin, here.
  • Support a generic passthrough of %URLPARAM, so many different parameters in the INPUT template can be passed through to the OUTPUT. - CrawfordCurrie
    • implemented in the chop-down
  • Please consider enabling the user to decide in which DOM level the comments will be included into the document. For some purposes it is good to comment on the whole document, and ---++ is OK. But it is only a question of time that Twiki will come to implicitly named sections, and for some applications a deeper level will be appropriate, say ---+++, ---++++ etc. The setup/switch of DOM level of the comments will be necessary at least at the web level, if not at the topic level. -- AndrzejGoralczyk - 11 Feb 2004
    • Hope I reworded correctly. Hmm, interesting idea; something like this can be done today, interactively with an appropriate selector on the form in the template e.g.
      or non-interactively by simply using a WebPreferences variable in the template e.g. %DOM_LEVEL%
    • Great :), esp. if implementing is easy -- AG

All the things that work but are really naff about it and should be fixed:

Currently discussion context: PeterThoeny asked for support of legacy parameters rows cols etc. SamAbrams asked for alternative targets (not anchors) for comments. These have been addressed in the 20 Feb 2004 zip.

<snip>... what you ask can now be done through the alternative parameter anchor, which lets you specify a regular expression that uniquely identifies the insertion point - for example, %COMMENT{type="after" anchor="^< sectionedit >"}%. And Sam, any local customisations you do that would be useful for the community at large should be fed back via patches.

I replaced the nop with a - sign, a bit more user-friendly.

Peter, yes, it would be nice to have reverse compatability. However these parameters were not well thought out, and I removed the implementation for very good reasons.

On reflection, I have been able to handle rows, cols, and button as follows. Any parameters to the %COMMENT not recognised are expanded in the template, matching %param|default% (e.g. %rows|3%, %button|Push me%). "mode" has been made synonymous with "type", and I have added an "after" template. "id" I can't do anything about, as the mechanism for locating the relevant comment has changed completely. However "id" should be quite safe to ignore (though you would need to double-check this). I have also added tests for this reverse compatibility, so it should be maintained in future versions, and updated the documentation.

Note that I (once again!) used the Attrs class I wrote oh so long ago. I'm now using this module in ALL the plugins I maintain. BTW, I never really understood your objections to making this module a standard. It fully supports the existing attribute syntax as well as the more user-friendly extended syntax, is easy to use, and is more functional than extractNameValuePair. It could quite happily be installed alongside it.

-- CrawfordCurrie - 20 Feb 2004

Just installed a fresh copy of your Feb 20 release. Left all my plugins in place. It worked flawlessly out of the box. Even that annoying problem I had editing the plugin page went away.

A caveat worth mentioning to other installers using regex: Remember if you reference a tag in the location, you've just inserted another tag in your page. So only reference a portion of the tag -- instead of referencing "< sectionedit >", reference just "< sectioned".

I'll followup with any bugs I find, but so far no bugs glare at me. More of a nit than anything: if there's text already above the anchor, the first initial comment gets smushed against that text. It would be nice if a line break was inserted along with the first comment, as it is with the second and third comments.

Also, it might be worthwhile mentioning in the docs the security risk with the plugin. For example, I prefer removing the tag (now just a dash) inserted at the beginning of the comment plugin. It's easy enough for me and others to remove in the template. But clearly Peter sees some security risk in doing so.

(I personally don't fully understand the risk. In fact, I see more of a potential new feature, by automatically inserting the three spaces and bullet, and perhaps automating the process of changing settings. A newbie's two cents...)

-- SamAbrams - 20 Feb 2004

Sam, that's great; "flawlessly out of the box" is thanks mainly to your thorough and prompt testing. smile

I've done a documentation fix on the regex. The security issue was already documented. The important thing about it is that the shipped plugin can't compromise security. What a punter does with it once it's installed is their lookout.

-- CrawfordCurrie - 21 Feb 2004

I just installed this useful Plugin on TWiki.org. Some things I noticed:

  1. If you try to submit a comment in the CommentPlugin topic of the Plugins web you get a "The "Plugins/Trash" web does not exist" error. In the TWiki web's CommentPlugin I changed the target to Sandbox.CommentPluginTest and get a similar error message "The "TWiki/Sandbox" web does not exist".
  2. Most TWiki installations probably have a Sandbox web. Suggest to use a default target="Sandbox.CommentPluginTest"
  3. Default type="below" comment should behave like the convention of manually adding text, e.g. real empty lines for paragraphs (not br tags), bullets as bullets, TWiki tables and tables, and the standard signature like -- Main.PeterThoeny - 26 Feb 2004
  4. Better to show the "Remember to refresh before you comment" text only if JavaScript is enabled (user needs to select - delete it now)
  5. The Plugin calls directly the save script and it works. The save script actually was not designed to be called directly, good testing needs to be done to make sure that there are no surprises. As described in GlobalReplacePluginDev, this Plugin could call the viewauth script when submitting a comment, which fires off a topic load/patch/save action when viewing a COMMENT with special parameters supplied by URL parameters. You can study the GlobalReplacePlugin to see how this works (it does so reliably)

-- PeterThoeny - 26 Feb 2004

  • Point 1; the error message is clearly wrong, I'll investigate.
  • Point 2; Can do, but Sandbox seems every bit as unreliable as Trash, if not more so!
    • Almost all TWiki installations I have seen do retain the Sandbox web. I think it would be a good choice to have an actual working test page; the Sandbox.CommentPluginTest topic can be bundled in the Plugin package. -- PTh - 04 Mar 2004
  • Point 4; How can you initialise the content of a textarea depending on whether JavaScript is enabled or not? Seems to me you would have to rewrite the page.
    • Do not add the text in the template, but let JavaScript add it. However, showing this text is not needed after all, see next point. -- PTh - 04 Mar 2004
  • Point 5; The plugin doesn't call the save script; it writes a URL that when clicked, invokes the save script. As such it is no different to the standard preview page. The plugin uses the beforeSaveHandler to intercept saves that have associated comment targets. This is the process you previously recommended!
    • Sorry, I realize now that I was confusing the comment save handling with a post-processing of edited text, in which case the beforeSaveHandler is appropriate. The comment Plugin actually needs to manipulate topic text on disk with a read/modify/save operation. This is how the EditTablePlugin and the GlobalReplacePlugin work. Since this operation is done in a split second there is no need for a "remember to refresh" message. This can be done as follows:
      1. The action of the form calls viewauth so that users are authenticated
      2. The form has all visible input fields defined by the template; it also has:
      3. a hidden name="topic" value="TargetTopic" input field, indicating the target topic
      4. a hidden name="commentaction" value="savecomment" input field, used to detect when a save action is required
      5. When the form is submitted, viewauth renders the target topic; the Plugin gets called via the COMMENT variable
      6. In the comment variable you check if there is a commentaction=savecomment parameter
      7. If yes, do the read/modify/save operation (see example at TWiki::Plugins::EditTablePlugin::doSaveTable) to persistently store the text, and manipulate the topic text with the received text (so that the users sees the resulting topic text delivered by viewauth)
      • Hope this makes sense -- PTh - 04 Mar 2004

-- CrawfordCurrie - 26 Feb 2004

Peter, the target failure you describe happens because the latest code moved $webNameRegex into the $regex hash. This makes it unavailable to plugins. See RefactorPluginAPI for lists of other plugins that may be impacted by this change.

The latest (27 Feb) upload fixes the following problems:

  1. Bad message when target topic is locked
  2. Not working with GnuSkin
  3. Target topic does not exist (only happens with bleeding edge alpha) - fixed at the cost of sloppier parsing of targets.

-- CrawfordCurrie - 26 Feb 2004

The more I work with it, the more I realise how important it is to have these templates in user topics, rather than the templates directory. This is for two reasons:

  1. Many users are sophisticated enough to properly define their own templates, and want to do so
  2. Upgrades will overrwrite comments.tmpl, which would be a mistake.
There are two options to enable support.
  1. Support inclusion of user topics from templates
  2. Read templates from a user topic, and do template processing in the comment plugin

Unfortunately the default template reading code in Store is impossible to leverage for re-use. Supporting inclusion of templates from user topics depends on the core team making changes. I see no alternative to duplicating the template processing code in the plugin. Bah. Still, it gives us an opportunity to write a module to do it properly, I suppose.

-- CrawfordCurrie - 28 Feb 2004

OK, just uploaded a revision of the plugin (to the main CommentPlugin topic) that supports user definition of templates in web topics. The capability can easily be switched off.

-- CrawfordCurrie - 28 Feb 2004

With the latest patch, TWiki will be able to read templates from user topics and the templates hack in this plugin will no longer be required. This is a note to remind me to take it out after the Cairo release!

-- CrawfordCurrie - 03 Mar 2004

If the appendTopicText function that I wrote on FuncDotPm was implemented, it would not be necessary to "Remember to refresh before you comment" and "a plugin to accept input from e-mail" would be easier.

In fact, the latter problem has been solved a couple of times, once in the MailInAddOn and again in MailToTWikiAddOn; both times the common requirement is to be able to not have to know what was on the topic before adding some more and to have the topic locked for the minimum amount of time.

-- MartinCleaver - 03 Mar 2004

I'm using 01 Feb 2003 TWiki and when topic name is in cyrillic (KOI8-R) and "Add comment" is pressed, a new topic is created with name that is like UTF-8 encoded original topic name, but shown in KOI8-R. How this can be fixed? I properly configure twiki conf to use bg_BG.KOI8-R locale.

-- OgnyanKulev - 07 Mar 2004

Crawford, outstanding work. Simply to use, very functional. I like it.

-- SteveRJones - 11 Mar 2004

Almost all TWiki installations I have seen do retain the Sandbox web. I think it would be a good choice to have an actual working test page; the CommentPluginTest topic can be bundled in the Plugin package. -- PTh - 04 Mar 2004
And I am aware of at least 5 installations that do not have a sandbox web. I am not aware of any that do not have a Trash web, which is why I picked it for the demo from the Plugin page. The behaviour you saw before, where it appeared to be confused about the target topic, was caused by running on twiki.org, which was running alpha code ahead of anything I'd tested. -- 04 Mar 2004

Sorry, I realize now that I was confusing the comment save handling with a post-processing of edited text, in which case the beforeSaveHandler is appropriate. The comment Plugin actually needs to manipulate topic text on disk with a read/modify/save operation. This is how the EditTablePlugin and the GlobalReplacePlugin work. Since this operation is done in a split second there is no need for a "remember to refresh" message. This can be done as follows etc.

Nice idea, but no cigar. A save to a locked topic will currently bounce quite safely - there's no need to go through the viewauth grind. However the reason Peter implemented the refresh-me message - user friendliness - is still valid. I can disable the message all right - actually, anyone can, just by changing the template and removing the javascript - but I for one quite like it. -- 04 Mar 2004

And why is a save to a locked topic such a bad thing? Only because additions are actually replacements. If append to was implemented you would care slightly less. -- 04 Mar 2004

We used not to need the {} after COMMENT, i.e. %COMMENT% should work. That plugins handle their own invocation allows for this inconsistency.

It was supposed to, Martin. Gah, I hate perl REs.

Filtering content.

* Point 3; You can't have your cake and eat it! The br tags are used to make it impossible to insert a Set statement, as you requested. Either compromise formatting, or compromise security. Note that the nl->br expansion is controlled from the template, not the plugin code.

Why not simply filter out all =* Set ALLOW/DENY... settings from the received text before saving, e.g. like the old Plugin did? Or relax this security issue (anyone who has permission to edit a page can lock it down anyway). Users used to the TWiki ML expect to use it in the comment box. -- PTh - 04 Mar 2004

Filtering is definitely out. Why should this plugin make value judgements or assumptions about how it is going to be used? My attitude is: the shipped templates don;t permit the security violation, the risk is documented, and if templates are edited, it's caveat emptor. -- 04 Mar 2004

This is only necessary because we store permissions in the topic text. I'd contend that PermissionsAreMetaData - I'd like to get agreement that they be treated as such so that we can have a special control look after them and so that operations that affect the TopicText cannot inadvertantly alter permissions. (I would, afterall, not expect comment to be able to change the topic parent).

- The only issue that I see now is if someone wants to enter a comment with some TML to render a bulleted list, like:

* this
* and
* this
-- SteveRJones - Wed Mar 10 21:38:38 2004

- Or
* this

* and this

Guess this is the cake part, huh? -- SteveRJones - Wed Mar 10 21:41:54 2004

Uh-oh, Steve's back. Got over the initial shock of working for a water filter company, then Steve?

Out-of-the-box your examples above do indeed have the limitation you surmise. However you can easily define your own templates, either in comments.tmpl or in the user template include topic, or even another topic included from there. RTFM.

-- CrawfordCurrie - 11 Mar 2004

I've commented above about an I18N fix that should be applied and is now working so CommentPlugin can make comments on pages with Bulgarian names (amongst other languages).

-- RichardDonkin - 11 Mar 2004

Yep, I did RTFreakingM (even after the initial shock) and tried a couple of late night mods to the template to see if I could get it to format using TML bullets but I made a small adjustment that satisfies my simple tastes. It was late, I was tired, give me a break. I'll look deeper but at the moment I'm not looking for a solution just trying to anticipate some user whining "Why doesn't it do . . . ". big grin

BTW, you do realize that such devices as being hawked at http://www.freescale.co.uk/ are the Old-West equivalent of Snake Oil?

OhMyGod, perhaps this is the intended marketing ploy of . . . an unnamed "new" company. hehe!

-- SteveRJones - 11 Mar 2004

I've uploaded a revision with the following changes:

  1. Uses viewauth technique to do save
  2. Removes concept of REFRESH message
  3. Adds nonotify= parameter to COMMENT
  4. Moves templates fully into topics, with a hook for including site-specific templates
  5. re-supports %COMMENT%
  6. RichardDonkin's internationalisation fix incorporated

Because of the change to the viewauth saving, there are a considerable number of code changes. Please, download and try it out, see if we can't catch any gotchas before the average punter finds them. I have tested as thoroughly as I can, but you never know.

-- CrawfordCurrie - 13 Mar 2004

Thanks, Franz, for the User templates! I'll have a look at incoporating in the next release. -- CC

Could you also have another look on your CommentsTmpl, especially the action template (and some formatting). It seems not to work properly on my system (using the latest ActionTrackerPlugin wink ). Thanks.
Are there any other usefull templates out there? (it's a great feature!)

-- FranzJosefSilli - 17 Mar 2004

When you say "the latest version" do you really mean "the latest version"? A bugfix update was uploaded a couple of days ago. Part of that update fixed the action template - at least, it works for me! So if you are still seeing a problem, I need a lot more detail. -- CC

Yes, I mean "the latest version" (the bugfix). Today I played around with the action type delivered with your template. Did simplify it so that it now works for me in order to append actions to a list (table) of actions. Here is what I've done:

%POS:BEFORE%%NOP{%ACTION}%{ state="open" creator="%WIKIUSERNAME%" due="%URLPARAM{"due"}%" created="%GMTIME{"$day-$month-$year"}%" who="Main.%URLPARAM{"who"}%" }% %URLPARAM{"comment"}%
The %NOP{}% and the %GMTIME{}% parts have turned out to be essential for proper action creation. Maybe one should provide the date format expected by the ActionTrackerPlugin as help text for the due field or use the JavaScript calendar of the EditTablePlugin with proper date setting instead of ordinary forms.

-- FranzJosefSilli - 24 Mar 2004

Awfully I lately experienced an error when using the NotificationPlugin together with the latest CommentPlugin and the DiscussionForumAddOn. Have not figured it out yet, maybe someone else has already seen the following error message when executing the mailnotify script coming with the NotificationPlugin:

Can't call method "param" on an undefined value at ../lib/TWiki/Plugins/CommentPlugin.pm line 31.

-- FranzJosefSilli - 24 Mar 2004

Aw, heck, this is because mailnotify is called without a CGI query in hand. This shouldn't affect anything, but to get rid of the message then here's a quick workaround; in lib/TWiki/Plugins/CommentPlugin, in the function commonTagsHandler, after the line reading:

  my $query = TWiki::Func::getCgiQuery();
add another line
  return unless ( defined( $query ));

I've updated the codebase.

-- CrawfordCurrie - 24 Mar 2004

Thanks, this solved my problem with the NotificationPlugin. But the strange behaviour with the DiscussionForumAddOn (the comments are not inserted into the actual article topic, they are written to - well - don't know where or if they are written anywhere, the WebHome of the web including the DiscussionForumAddOn topics gets modified, but without any content change) still exists. I will keep trying to figure out what is happening.

-- FranzJosefSilli - 24 Mar 2004

Hi, I have installed TWiki20030201 and have installed this CommentPlugin. This first problem I found was that this plugin needed a symlink called viewauth to view in the bin directory. My problem now is when I create a comment (one word test) I get five entry's

- test -- RichardSkelton - 01 Apr 2004

- test -- RichardSkelton - 01 Apr 2004

- test -- RichardSkelton - 01 Apr 2004

- test -- RichardSkelton - 01 Apr 2004

- test -- RichardSkelton - 01 Apr 2004 

-- RichardSkelton - 01 Apr 2004

Richard, can you tell me exactly what version of the plugin you downloaded? And also what other plugins / skins you have installed? I've seen a similar problem before, but it was fixed several revs of the plugin ago.

-- CrawfordCurrie - 02 Apr 2004

Crawford, I downloaded the zip file from http://twiki.org/cgi-bin/view/Plugins/CommentPlugin The version from the file Plugins/CommentPlugin.pm is 3.001 I had no other plugins at the time of posting. I now have the MailToTWikiPlugin which is working.

-- RichardSkelton - 02 Apr 2004

Unfortunately that's not quite enough. If you can post a listing of the file dates in the zip you downloaded (do a zip -l and paste the output here) I can maybe help. But the most likely cause is that you have downloaded an old zip; try downloading the zip currently posted in the CommentPlugin topic, if that isn't the one you already tried.

-- CrawfordCurrie - 02 Apr 2004

drwxr-xr-x  2.0 unx       0 b- stor  7-Feb-04 11:36 data/
drwxr-xr-x  2.0 unx       0 b- stor 13-Mar-04 11:29 data/TWiki/
-rw-r--r--  2.0 unx   12797 b- defN 13-Mar-04 11:29 data/TWiki/CommentPlugin.txt
-rw-r--r--  2.0 unx    5441 b- defN 13-Mar-04 08:14 data/TWiki/CommentsTmpl.txt
drwxr-xr-x  2.0 unx       0 b- stor  7-Feb-04 11:40 lib/
drwxr-xr-x  2.0 unx       0 b- stor  7-Feb-04 11:36 lib/TWiki/
drwxr-xr-x  2.0 unx       0 b- stor 13-Mar-04 11:25 lib/TWiki/Plugins/
-rw-r--r--  2.0 unx    1127 b- defN 13-Mar-04 11:25 lib/TWiki/Plugins/CommentPlugin.pm
drwxr-xr-x  2.0 unx       0 b- stor 13-Mar-04 11:29 lib/TWiki/Plugins/CommentPlugin/
-rw-r--r--  2.0 unx    2461 b- defN 20-Feb-04 10:09 lib/TWiki/Plugins/CommentPlugin/Attrs.pm
-rw-r--r--  2.0 unx    8345 b- defN 13-Mar-04 11:17 lib/TWiki/Plugins/CommentPlugin/Comment.pm
-rw-r--r--  2.0 unx    2677 b- defN 13-Mar-04 08:44 lib/TWiki/Plugins/CommentPlugin/Templates.pm
-rw-r--r--  2.0 unx    4719 b- defN 28-Feb-04 13:33 lib/TWiki/Plugins/CommentPlugin/build.xml
-rw-r--r--  2.0 unx    6838 b- defN 13-Mar-04 11:29 lib/TWiki/Plugins/CommentPlugin/test.zip
drwxr-xr-x  2.0 unx       0 b- stor  9-Mar-04 08:25 templates/
-rw-r--r--  2.0 unx      35 b- defN  9-Mar-04 08:25 templates/comments.tmpl
16 files, 44440 bytes uncompressed, 19486 bytes compressed:  56.2%

-- RichardSkelton - 02 Apr 2004

I confess I am mystified. I just created a brand new install of Beijing (TWiki20030201), and installed the comment plugin in it. It works fine! Please download and unzip the zip file for the Comment plugin and try again. If it still doesn't work then it's something in your installation, and I'm stuck without being able to browse your install.

Wait a mo; what is your server? A windows box?

-- CrawfordCurrie - 02 Apr 2004

Hi Crawford, The server is a sparc Solaris 8 system which was using the perl that came with the OS. I have changed all the bin files to use perl 5.6.1 and the problem has gone away smile Thanks for the support.

-- RichardSkelton - 05 Apr 2004

I just installed the version 13 Mar 2004 from the CommentPlugin topic on my test installation. When I add a comment it gets added 9 times, consistently. The issue is that the save action is triggert unconditionally in the commonTagsHandler, which gets called several times for each topic view.

Here is a fix for CommentPlugin.pm that makes sure save gets executed only once, also for a mod_perl environment:

*** CommentPlugin.pm1   2004-04-05 23:32:57.000000000 -0700
--- CommentPlugin.pm    2004-04-05 23:54:47.000000000 -0700
*** 8,17 ****

  # =========================
  use vars qw(
!           $web $topic $user $installWeb $VERSION

! $VERSION = '3.001';

  sub initPlugin {
    ( $topic, $web, $user, $installWeb ) = @_;
--- 8,22 ----

  # =========================
  use vars qw(
!           $web $topic $user $installWeb $VERSION $readyForAction

!   $VERSION = '3.001';
!   $readyForAction = 0;
! }

  sub initPlugin {
    ( $topic, $web, $user, $installWeb ) = @_;
*** 20,25 ****
--- 25,31 ----
      TWiki::Func::writeWarning( "Version mismatch between CommentPlugin and Plugins.pm $TWiki::Plugins::VERSION" );
      return 0;
+   $readyForAction = 1;

    return 1;
*** 27,44 ****
  sub commonTagsHandler {
    ### my ( $text, $topic, $web ) = @_;   # do not uncomment, use $_[0], $_[1]... instead

!   my $query = TWiki::Func::getCgiQuery();
!   my $action = $query->param( 'comment_action' ) || "";
!   if ( defined( $action ) && $action eq "save" ) {
!     CommentPlugin::Comment::save( $_[2], $_[1], $query );
!   } else {
!     # Nasty, tacky way to find out where we were invoked from
!     my $scriptname = $ENV{'SCRIPT_NAME'} || "";
!     my $previewing = ($scriptname =~ /\/preview/ ||
!                     $scriptname =~ /\/gnusave/);
!     CommentPlugin::Comment::prompt( $previewing, @_ );

--- 33,54 ----
  sub commonTagsHandler {
    ### my ( $text, $topic, $web ) = @_;   # do not uncomment, use $_[0], $_[1]... instead

!   my $query = TWiki::Func::getCgiQuery();  # query not set if invoked by shell script
!   if( $query ) {
!     my $action = $query->param( 'comment_action' ) || "";
!     if( ( $readyForAction ) && ( $action ) && ( $action eq "save" ) ) {
!       $readyForAction = 0;
!       CommentPlugin::Comment::save( $_[2], $_[1], $query );  # should never return
!       return; # in case browser does not redirect
!     }
+   $readyForAction = 0;
+   # Nasty, tacky way to find out where we were invoked from
+   my $scriptname = $ENV{'SCRIPT_NAME'} || "";
+   my $previewing = ($scriptname =~ /\/preview/ ||
+                   $scriptname =~ /\/gnusave/);
+   CommentPlugin::Comment::prompt( $previewing, @_ );


Further, I have not tested this, but from reading the code it looks like the CommentPlugin::Comment::buildNewTopic method does not handle the ( $position eq "BOTTOM" ) correctly. Text should be added before the trailing META tags like META:FORM or META:FILEATTACHMENT. Unfortunately we do not have yet an API to manipulate topic text with meta data. For now you need to apply a regex to insert text at the bottom:

  • scan over %META:TOPICINFO if present
  • scan over %META:TOPICPARENT if present
  • scan over all lines not starting with %META:[A-Z]
  • insert your text, needs to be terminated by \n

One more feedback: I think, the most logical default behaviour for the comment plugin is to add comments after the form, preserving text as entered (which might include TWikiML), and signed in the standard TWiki convention.

-- PeterThoeny - 06 Apr 2004

Hmmm. OK, I take on board what you have done BUT why is this behaviour suddenly manifesting itself? This has not been an issue before (or maybe it has, and I just haven't realised; I'm just not immersed enough in the complexities of the TWiki rendering cycle, I guess). Whatever the cause, I have incorporated your patch, thanks!

Yes, your code reading is correct - well spotted! The same occurs with TOP. When I originally wrote it, I was working with the erroneous belief that %META tags could appear anywhere in text. I had already fixed this in my local copy. Obviously it would be a lot cleaner if I had access to readTopic and saveTopic, but this isn't the first time I've had to do this trick.

The default insertion point can be set from the COMMENTPLUGIN_DEFAULT_TYPE variable, as described in the plugin topic. I have changed the "default default" to below, because I agree it is more logical. The comment template may also be edited on a per-installation basis - see CommentsTmpl

The zip attached to the CommentPlugin topic contains the fixes described. It also shifts the templates out of the templates directory completely, and puts them all into a user topic. Exposing them this way gives people an opportunity to read and learn from them, without changing the functionality of install process.

-- CrawfordCurrie - 06 Apr 2004

I tested it out, it works now on my test installation.

The default is still not what I would expect as a regular TWiki user:

  1. It should be of type "above" so that it behaves like a linear thread in a topic: Comment box at the end, comments from oldest to latest
  2. It should add a signature with date (but no hour:min) like \n\n-- Main.PeterThoeny - 06 Apr 2004\n\n (note that leading newlines need to be added as needed, depending on how many trailing newlines the user entered)
  3. No leading dash; text should be preserved "as is"
  4. TWikiML should be preserved, including tables and bullets

Also, is the templates.tmpl really needed? It adds the flexibility of skins overloads, but would anyone actually use it? Possibly drop this for KISS.

-- PeterThoeny - 06 Apr 2004

  1. I disagree. I followed your suggestion above, and having seen it, I like it the way it is. The reason? Well, if a COMMENT is at the top of the page, then visitors to that page see the comment box and the most recent comments without having to scroll down.
  2. I disagree. I have had several requests for the time, especially where multiple timezones are involved.
  3. See your remarks about security
  4. See your remarks about security
Note that any and all templates and defaults can be modified on a per-installation basis, so if you don't like the defaults, just override them locally.

As for templates.tmpl. No, it's not necessary any more, but I didn't remove it because I wasn't sure what the reaction from the core team to moving templates into user topics would be. It can be removed at any point, but I don't perceive any urgency. It's more important to get the Templates.pm module in the CommentPlugin moved into a BeijingCairoCompatability module.

-- CrawfordCurrie - 08 Apr 2004

Is there any way to have the CommentsPlugin create new topics when configured to post comments to another topic (not the default of the current page)? Currently the Plugin borks at the 'oops' it gets when the topic it is trying to post to does not exist yet.

-- AdamTheo - 13 Apr 2004

Has there been any resolution to the problem described by FranzJosefSilli on 24 Mar 2004? I've been encountering the same problem when using the CommentPlugin as part of the DiscussionForumAddOn. Attempting to add a comment to an article results in eiter the DiscussionForumHead file or WebHome page being loaded up, usually minus the comment. Any ideas?

-- DeclanGraham - 11 May 2004

I ran into the same issue with DiscussionForumAddOn. I recently (this week) installed the addon then began to fix it as it had quite a number of problems, one being the CommentPlugin support. I already had Crawford's updated plugin installed on our site - but not the latest version. The Addon worked flawlessly. I then upgraded to the latest CommentPlugin and wham the next comment I entered completely obliterated the Discussion topic and I got a single word -- "dummy" follwoed by a hard rule. I suspected Crawford knew it was I somehow and had inserted a bomb just waiting for me! (not really) Needless to say I back-graded to the previous version of CommentPlugin - the version without template support in userspace.

I have not had a chance to try and figure out what is going on.

-- SteveRJones - 12 May 2004

Sorry, but I haven't tested against DiscussionForumPlugin in any way at all. The parameters controlling CommentPlugin have changed - I hadn't realised that other dependencies existed. You can continue to use the older version of CommentPlugin if you need DiscussionForumPlugin, but if you want to take advantage of the new features of CommentPlugin someone is going to have to fix the DiscussionForumPlugin code. Steve, since you are already in there, you sound like a natural candidate......

Adam, sorry, I hadn't noticed your question appearing; I'm not sure why it's not working; I'll have a look.

-- CrawfordCurrie - 12 May 2004

DiscussionForumAddOn isn't a Plugin at all - it is simply a set of pre-created templates using such things as URLPARAM, SEARCH, pattern, etc. to create a really neat, no overhead . . . um . . Discussion Forum! I'll see if I can chase down why the new CommentPlugin acts so weird with this addon. It works fine with the Feb 18, 2004 version that you released but not with April 11 version. The only difference that I saw was the move of the templates.

I'll keep digging.

-- SteveRJones - 12 May 2004

Todays cvs checkout has variables in the data/TWiki/CommentPlugin.txt instead of values (MANIFEST%, DEPENDENCIES% and 'CrawfordCurrie - %$DATE%' )

-- MattWilkie - 13 May 2004

That's OK, Matt, it's supposed to be that way. The release zip is built using the build file in the package that expands those variables to their final values.

-- CrawfordCurrie - 14 May 2004

Problem reported in the Support web revealed a very nasty problem when commenting on a page that includes, or has as a search result, another topic that contains a %COMMENT. To fix, change the line in CommentPlugin.pm that reads:

  if ( defined( $action ) && $action eq "save" ) {
  if ( defined( $action ) && $action eq "save" &&
    $query->path_info() eq "/$_[2]/$_[1]" ) {
The essence of the problem seems to be the change to the method for saving using the view script. When a search or include is on the page that returns text that includes a %comment, the commonTagsHandler is called on the included/searched topic before it is called on the topic being saved, but using the same query so the "action=save" parameter is passed in. This "sub-request" call is distinguished from a "proper" call by virtue of the fact that the CGI query path_info is for the correct file, but the web and topic passed to the commonTagsHandler are for the included topic. Mindbending. I will release a version with the workaround ASAP.

-- CrawfordCurrie - 16 May 2004

The problem was reported here: CommentPluginDoesNotWorkWithSEARCH

The above code fixes it, but your explanation is not quite correct. The included or searched page does not need to include a %COMMENT. If you have a page with a %COMMENT, and also on that page you have a %SEARCH or %INCLUDE, the bug shows up. The %SEARCH can return nothing, or the %INCLUDE can include a non-existent topic. You can even have them not run by wrapping them in HTML comment tags, and the bug still occurs.

But all this is less than highly relevant, as the above code modification fixes the problem.

-- KenMankoff - 17 May 2004

Which may explain why DiscussionForumAddOn does not work with the latest CommentPlugin as there is a %INCLUDE that pulls in a common header, and this header has a %SEARCH directive.

-- SteveRJones - 18 May 2004

Does the 20040516 CommentPlugin work with the TWiki 20040507beta ? By us with only SpacedWikiWordPlugin, the plugin doesn't render the %comment edit box.

-- BenoitFauvel - 18 May 2004

I think you will find the answer on the page TWiki.InstalledPlugins

-- MartinCleaver - 18 May 2004

Thank you Martin for this, but as I investigate further, I notice an error in my data/warning.txt that says "can't locate TWiki/Plugins/SharedCode/Attrs.pm in @INC (... perl 5.6.1 ...) compilation aborted at ../lib/TWiki/Plugins/CommentPlugin.pm 9 ... iniPlugin did not return true" and I read in the the plugin installation instructions that I must install TWiki:Plugins/SharedCode only with TWiki version earlier than Feb 2004. I'm a bit stucked for now, please could you give me any clue ?

-- BenoitFauvel - 19 May 2004

Aw heck, Benoit, you're right, you need the Attrs.pm module. You will have to download and install SharedCode. You need the CairoCompatibilitModule, which is part of SharedCode, for TWiki pre Feb 2004, but I'd forgotten about Attrs.pm :-(. Sorry. I'll update the docs.

Thank you Crawford for your very quick answer - It works fine : it's a great plugin, very useful for final users !! -- BF

-- CrawfordCurrie - 19 May 2004

Tried to install newest version of CommentPlugin (16052004) to my own system, but I encountered the following error message, when trying to enter a new comment:

Undefined subroutine &TWiki::Store::readTemplateFile called at /var/www/html/twiki/lib/TWiki/Plugins/CairoCompatibilityModule.pm line 70.

I have Beijing release installed with KoalaSkin, I also installed SharedCode (12052004). Should I update my whole installation to get CommentPlugin to work, or is there any easier ways to do it?

Now it works, download latest zips of CommentPlugin and SharedCode. Thanks for Crawford for fast fixes in IRC -- HV

-- HarriVartiainen - 21 May 2004

OK, the latest CommentPlugin (3.003 11 Apr 2004) is installed again on TWiki.org. I did some small tweaks and suggest to take them into the next package:

  1. Changed default type to above, this is the usual linear collaboration we have here on TWiki.org
  2. Added a outputstandard template definition to CommentsTmpl that preserves entered text as is, and appends a signature exactly like we are used at TWiki.org
  3. Changed the OUTPUT:above and OUTPUT:below template definitions to use the outputstandard template definition.

In addition, until the spec for contributed code has been fleshed out I did a small change to the code:

  1. Copied Attrs.pm back to the CommentPlugin subdir (where it used to be)
  2. Named the module TWiki::Plugins::CommentPlugin::Attrs and fixed the code accordingly.

For reference, here are the changes:

*** up/lib/TWiki/Plugins/CommentPlugin/Comment.pm       2004-05-21 03:56:26.000000000 -0700
--- lib/TWiki/Plugins/CommentPlugin/Comment.pm  2004-08-07 19:25:35.000000000 -0700
*** 6,18 ****
  use strict;

! use TWiki::Plugins::SharedCode::Attrs;
!   if ( $TWiki::Plugins::VERSION < 1.020 ) {
!       require TWiki::Plugins::CairoCompatibilityModule;
!   }
! };

  { package CommentPlugin::Comment;

--- 6,13 ----
  use strict;

! use TWiki::Plugins::CommentPlugin::Attrs;
! use TWiki::Plugins::CommentPlugin::Templates;

  { package CommentPlugin::Comment;

*** 87,93 ****
         $disable, $defaultType ) = @_;

      $attributes =~ s/^{(.*)}$/$1/o if ( $attributes );
!     my $attrs = new TWiki::Attrs( $attributes );

      my $type =
        $attrs->remove( "type" ) || $attrs->remove( "mode" ) || $defaultType;
--- 82,88 ----
         $disable, $defaultType ) = @_;

      $attributes =~ s/^{(.*)}$/$1/o if ( $attributes );
!     my $attrs = new TWiki::Plugins::CommentPlugin::Attrs( $attributes );

      my $type =
        $attrs->remove( "type" ) || $attrs->remove( "mode" ) || $defaultType;

*** CommentPlugin3/Attrs.pm     2004-02-20 10:09:18.000000000 -0800
--- CommentPlugin/Attrs.pm      2004-08-07 19:26:01.000000000 -0700
*** 20,26 ****
  # Class of attribute sets
  # An attribute set is a hash containing an entry for each parameter. The
  # default parameter (quoted string) is named "__default__" in the hash.
! { package CommentPlugin::Attrs;

    # Parse a standard attribute string containing name=value pairs. The
    # value may be a word or a quoted string (no escapes!)
--- 20,26 ----
  # Class of attribute sets
  # An attribute set is a hash containing an entry for each parameter. The
  # default parameter (quoted string) is named "__default__" in the hash.
! { package TWiki::Plugins::CommentPlugin::Attrs;

    # Parse a standard attribute string containing name=value pairs. The
    # value may be a word or a quoted string (no escapes!)

I plan to take this version into CairoRelease.

-- PeterThoeny - 07 Aug 2004

A suggestion - I have just installed this plugin on my wikiweb and noticed it's quite happy to accept an empty comment - I changed the following in 'sub save' in Plugins/CommentPlugin/Comment.pm :

 sub save {
    my ( $web, $topic, $query ) = @_;
    return if ( $inSave );

    # ignore empty or white-space only comments
    unless ( grep /\S/, @{$$query{'comment'}} )    
      $query->param( -name=>'comment_action', -value=>'none' );
      TWiki::Func::redirectCgiQuery( $query,
                TWiki::Func::getViewUrl( $web, $topic ) );

Is there a way to get some kind of message back to the user (like - "You must enter a valid comment") ?

-- PhilipSterry - 15 Aug 2004

Peter, the latest version (about to be uploaded) uses dependency management, so there is no need to copy attrs back into the comment module.

The goal with the standard comment style was to be "blog-like", rather than "wiki thread mode", which means keeping comments compact. In most blogs I've seen the most recent comment gets added to the top, which is the behaviour you get from "below". I also don't want to change the default behaviour yet again. So I added a new template "threadmode" to the shipped templates that works the way you want it to. You can set the default in the plugin topic for a specific installation such as twiki.org using Set DEFAULT_TYPE = threadmode

Philip, fair enough, but an empty comment may be a valid comment. I might want to write "If you approve, add your name to the list below with an optional comment".

-- CrawfordCurrie - 16 Aug 2004

One interesting use of this plugin: We can insert "template snippets" to topics that may consist of tables, lists and any standard structure. (For example, we can add one of the several %EDITTABLE" templates.) Main advantage is that users don't have to remember the syntax anymore. Place the comment plugin in template so that it will appear in sidebar, and a drop-down box to choose from available template snippets.

Haven't yet tried out, but should be possible easly. We would probably require "type" field to be selected from drop-down list (i.e. OUTPUT templates should be selected dynamically.)

-- VinodKulkarni - 07 Sep 2004

That's an good idea. I had thought about using it to insert actions in meeting minutes, as well. But that sort of thing is most useful when you are already editing. Which leads me to the thought; WIBNIF there was a way to simply add "arbitrary content providers" to the edit page? So, when a punter does an edit, they get a button as Vinod describes, that allows them to click and add structured content? The idea could be extended to all sorts of content provided by plugins, or variables. I can imaging how to do it with the obsolute minimum of javascript. For example, let's imagine we have a template topic called "EditTableTemplateNumberOne", and in WebPreferences we say something like:

   * Set EDIT_SHORTCUTS = <button onclick="pasteTopicContent('EditTableTemplateNumberOne')">#1</button>
then, when the button is hit, it downoads the topic and pastes in the content. Or, the topic content could be compiled into the javascript on the edit page when it is composed.

This could all be done by a plugin, using the beforeEditHandler - no core code changes required. If you were smart, you could even pass parameters in to the javascript so - for example - you could do a pull-down of the types of Edit Table template that were available.

-- CrawfordCurrie - 07 Sep 2004

How about getting the plugin to add to signatures (i.e. "-- Main.someone - date") an Add Comment box, so that every signed posting can be commented on without going through an edit-save cycle? Indeed, the plugin could also add a rating poll (I agree, doesn't make sense, etc) to each posting. Easy contribution should increase the number of contributions - and a well picked set of ratings should improve the S:N ratio as well.

-- MartinCleaver - 07 Sep 2004

Could the line returns not be output in lines 145-170 of Comment.pm. I'd like to use a commentplugin inside TWiki table markup.

-- SamHasler - 19 Sep 2004

Done, because it was trivial. In future, I'll consider applying any patches provided.

-- CrawfordCurrie - 20 Sep 2004

  • This poll is defined in CommentsTmpl. It will be removed in the next installation of CommentPlugin upgrade unless I remember to restore the old settings. Better define in UserTemplates (alternative below)
  • It would be nice if the CommentPlugin allows definition of the PROMPT and OUTPUT in an arbitrary topic, not just CommentsTmpl and UserTemplates. That way polls could be defined in the poll topic, keeping content neatly together.
    1. Sure. I just noticed that it existed, I didn't look to see who defined the poll. - MC

-- PeterThoeny - 15 Sep 2004 (moved from another topic by MC)

-- MartinCleaver - 20 Sep 2004

Suggestion for a feature. Let us assume every comment is a record (in assumed table). And a mechanism to replace a record if selected fields match (as opposed to adding a new record).

How do we do it?

  • Any field whose name starts with "id_" is considered a special, ID field. There can be more than one.
  • When user fills form, if the ID fields match, then that record is overwritten.
  • To facilitate the identification of record,special markers are introduced: %COMMENT_RECORD_START% and END are used (with no output in view).
  • To facilitate identification of each field, %COMMENT_FIELD_START_name% (and corresponding END) is used. name is the form field name. (With no output in view.)

This capability will simplify the most often required use case: Getting votes and remarks from every user. And by generating a unique id for each row + user id, you can modify your own previous records. (And ... if you provide capability to delete records, it will start to compete with EDITTABLE!)

-- VinodKulkarni - 20 Sep 2004

It looks like removing the line returns can affect how other definitions are displayed, e.g. in UserTemplates#patternbugreport the first row does not become part of the table because the first "|" is after the form tag and not on a line on it's own. I had to insert a space after the start of the definition or the newline I wanted to insert at the start was removed.

|  Page | <select %DISABLED% name="patternbugreport_page">  

-- SamHasler - 20 Sep 2004

Don't forget to update the change history when you release new versions of a plugin. It is nice to know if it is worth upgrading an already installed plugin.

-- KennethLavrsen - 20 Sep 2004

Bug: Variables like %M% get expanded if entered in a comment box. Ideally it would do the same as ExpandVariablesInEditTemplateTopic.

  • Here contained a test: %M% was written here in a comment box. It should have left the text %M% in the topic, rendering a "MOVED TO...". Instead it gets expanded to its rendering equivalent:
<img src="http://twiki.org/p/pub/TWiki/TWikiDocGraphics/arrowright.gif" border="0" alt="MOVED TO..." width="16" height="16" />

-- PeterThoeny - 23 Sep 2004

In CommentPlugin.pm, I found a writeWarning call with the string Version mismatch between ActionTrackerPlugin and Plugins.pm $TWiki::Plugins::VERSION. Will not work without compatability module.. Shouldn't that mention CommentPlugin instead of ActionTrackerPlugin?

-- BruceDawson - 25 Sep 2004

Recommondation: Name supporting topics so that they can be identified as part of this Plugin. Right now it is not obvious because this Plugin is preinstalled with the TWiki distribution.

  • CommentsTmpl --> CommentPluginDefaultTmpl (or CommentPluginDefaultTemplates)
  • UserTemplates --> CommentPluginUserTmpl (or CommentPluginUserTemplates)

-- PeterThoeny - 25 Sep 2004

Peter, expandCommonVariables is called to instantiate the OUTPUT template into the string = and submit it looks good at the surface but the added code is not the ACTION code but a complete javascript function and an HTML table and naturally the whole thing does not work.

-- KennethLavrsen - 29 Sep 2004

Starting to think that template names starting with a capital letter should mean that the system looks on a topic by that name. Shouldn't break much... only mine seem to be named by wikiwords. My motivation is that I want to mix definition and description on the same page.

Would this spec refinement break anything?

-- MartinCleaver - 30 Sep 2004

Kenneth, after some analysis I understand the problem with actions. It's a bug, more of a bug with the Plugins API than the CommentPlugin but still a bug. The only way I can fix it is to call a method in the TWiki core directly. I've re-released with the fix in, or here's a workaround that you can use to patch existing code

edit lib/TWiki/Plugins/CommentPlugin/Comment.pm and find the line that reads:

my $t = TWiki::Func::expandCommonVariables("",$topic,$web )
(in function _getTemplate). Change it to
    my $t = TWiki::handleTmplP( $name );

-- CrawfordCurrie - 06 Oct 2004

Currie. It works great. I cannot wait to add that to our meeting minute template at work. My colleages will love it. Thanks.

-- KennethLavrsen - 07 Oct 2004

I am trying to use a EDITTABLE definition (with percent symbols) in the output prompt definition (for creating addtable type - that will insert a predefined EDITTABLE in the topic.)

But use of % symbol seems to be undefined - I sometimes find a nop getting inserted.

Perhaps $percnt and some similar variables can be recognized and interpreted?

-- VinodKulkarni - 07 Oct 2004

Vinod - I'm not entierly sure what you are trying to do, but the prompt template is processed through the commonTagsHandler when it is generated, so if you put tags into it they will be expanded at the time the prompt is instantiated. To insert text you would normally put that text into the output template. The output template was also processed by the commonTagsHandler before the latest version. In the latest version, it is processed through expandtagsOnTopicCreation instead, which only expands a selected subset of tags.

-- CrawfordCurrie - 08 Oct 2004

I've isolated that comment insertion bug. It's unrelated to polls or the %COMMENT% syntax without braces.

I often use comment boxes on the inline diff pages from WebChangesForAllWebs. It seems to be caused by commenting from rdiff pages when there is more than one comment box on the topic. Try commenting in the second box from this link: http://twiki.org/cgi-bin/rdiff/Sandbox/CommentPluginTest?type=last&render=sequential&context=1000

-- SamHasler - 09 Oct 2004

I haven't looked, but I can guess what is happening. It finds the relevant box for commenting by counting the comment boxes it sees in a topic. If a search or diff puts another one in, I guess it can get confused.

Perhaps I need to reintroduce the unique id number again, same as I had to for Actions.

-- CrawfordCurrie - 10 Oct 2004

There aren't any extra comment boxes in the diff now and it's still happening, so I don't think it's a straightforward counting problem.

Comparing the source in view and rdiff shows that rdiff gives every box a comment_index value of 0, whilst view numbers them properly. Comparing the source from different revisions shows some strange results:

hmm, should a comment box that has been removed in a diff be usable? I don't suppose there's any way the code would know to deactivate it. Maybe you could do some CSS cleverness to make then non-visable or replace them with something else. You could do something like:

.twikiDiffDeletedText textarea[name="comment"] { display:none; }

-- SamHasler - 10 Oct 2004

One thing I noticed: I often use the comment box that shows in the diff (indeed I am now): in this mode I can see what has changed and respond to it directly so I'd prefer it worked than got deleted.

I appreciate it can misbehave, placing the comment after the first comment tag (even it if is a poll instead of a comment) seemingly regardless of where that comment box appeared on the page.

-- MartinCleaver - 11 Oct 2004

So do I Martin.

Comment boxes inside table cell with the class twikiDiff Deleted Text have been removed from the topic, so they shouldn't be used. This would leave any boxes that were already in the topic or added in this diff (inside twikiDiffAddedText class).

-- SamHasler - 11 Oct 2004

Trouble is, there's no way for the plugin to know where the comment box it's rendering came from. It has to do the best it can based on what it sees, and if rdiff makes it see multiple COMMENT tags where there is in factonly one, then the plugin is stuffed.

The only way to reliably do this is (I think) to disable the comment boxes in the rdiff view. I just can't see how else it can work.

Please, someone prove me wrong!

-- CrawfordCurrie - 11 Oct 2004

What you probably need is plugin hooks in rdiff to process the added and deleted sections separately.

Maybe plugins should be able to add stylesheet links to any template. See follow up in ChangeDefaultTemplatesToProvideFunctionHook.

-- SamHasler - 11 Oct 2004

It looks like CommentPlugin catches its dependencies failing, specifically puts errors in the error log, and then loads without it. Although this is thoughtful, it fails to put report the failure on the TWiki.InstalledPlugins page.

-- MartinCleaver - 26 Oct 2004

I did some XHTML fixes on the Plugin topic ( FORM vs form, break with trailing slash, etc) and some other minor corrections. Also, better to spell out the links in the "Plugin Home" and "Feedback" rows (the InterwikiPlugin might not be installed/enabled on target system)

-- PeterThoeny - 27 Oct 2004

THANKS SO MUCH for the installer which grabs and installs the dependencies!

-- MattWilkie - 05 Nov 2004

%COMMENT{type="below" target="#anchorname"}%

and have

in your page, then the comment ("comment text here") is added on the same line, as such

#anchornamecomment text here

I have tweaked my copy of Comment plugin as follows starting at line 275 :- (basically slotting in a newline before $output in the AFTER section and a newline after the $output in the BEFORE section)

      } elsif ( $anchor ) {
      # position relative to anchor
      if ( $position eq "BEFORE" ) {
        $text =~ s/^($anchor)/$output\n$1/m; # put newline after comment to keep anchor left justified
      } else { # AFTER
        $text =~ s/^($anchor)/$1\n$output/m; # put newline before comments so don't merge with anchor

Now, I am not entirely sure that this is completely correct in the case of Windows, Mac, Unix (EOL varies), but it works for me in Linux. (I gather there would be some global constant which defines what a EOL is somewhere)

Also, on a slightly different tack, I think the 'COMMENT' plugin should translate HTML entity characters, particularly angle brackets, otherwise it becomes very easy to accidentally ruin a pages HTML structure by simply adding a comemnt. Also, users get awfully confused if they actually entered <some text> and it disappears in the comments!

-- LyallPearce - 14 Dec 2004

Bug: Danes (ie. ĉ,ĝ,ċ) and Firefox and CommentPlugin - bad cocktail

  • An error in CommentPlugin.pm made it impossible to add comments in Danish named topics (using Firefox) - IE no problem eek!
  • The problem was UTF8 characters in $query->path_info() in CommentPlugin.pm

Please add to next release of the CommentPlugin - and thanx for a super Plugin smile

-- NielsKoldso - 29 Dec 2004

The purpose of that code was to prevent recursion. It was really an extra mechanism, which I should have removed but didn't in case there was some obscure circumstance in which it was needed. I've removed it in the attached version, but I remain slightly nervous w.r.t functionality with mod_perl in this version. Perhaps you can thrash it about a bit and let me know if there are any problems?

-- CrawfordCurrie - 03 Jan 2005

I just installed and configured CommentPlugin. Nice piece of software. I was able to configure the output to look just the way I need it in a few minutes. Everything works as I'd like it to, except for a minor detail: Every new comment gets "signed" by the TwikiGuest user.

I'm using Twiki v2004-09-02 and the latest CommentPlugin available as of Jan/2005 (sorry, I don't know how to see the version I have installed). In my environment, users are required to authenticate using "basic auth" for everything (including reading pages), which should guarantee that REMOTE_USER is set at all times.

Another interesting piece of information: if I add %WIKINAME% to the body of the comment, it expands correctly to my username...

Any help will be appreciated.

-- MarcoPaganini - 13 Jan 2005

%PLUGINVERSION{"CommentPlugin"}% is supposed to do it. The version here is $Rev: 24977 (2013-10-14) $.

It sounds like there is some gap betwene the instantiation of the comment template (which is done in the beforeSaveHandler) and the viewing of the topic (which is done using the view script). Do you have view and save both authenticated?

-- CrawfordCurrie - 17 Jan 2005

QUESTION? I ran into this problem : CommentPluginUndefinedSubRoutineOnFeb2003, maybe someone can help .. ?

-- KeithHelfrich - 23 Jan 2005

I am running Feb 2003 with CairoContrib on a testing Debian system. By default, the comment plugin does not work. To get it to work, I did the following:

  • Edit /var/lib/twiki/lib/TWiki/Contrib/CairoContrib.pm :
Around line 63, change
$theText =~ s/%URLPARAM{(.*?)}%/&handleUrlParam($1)/geo;  # expand URL parameters
$theText =~ s/%URLPARAM{(.*?)}%/TWiki::handleUrlParam($1)/geo;  # expand URL parameters
  • Edit /var/lib/twiki/lib/TWiki/Plugins/CommentPlugin/Comment.pm :
Around line 260, change
$output = TWiki::expandVariablesOnTopicCreation($output);
my $theUser = &TWiki::Func::getWikiName( );
$output = TWiki::expandVariablesOnTopicCreation($output, $theUser);

Also, SamHasler on IRC helped a lot!!! Thanks!

-- JacobEisinger - 04 Feb 2005

Crawford, some topic formatting fixes got lost with the latest version: Tag fixes, XHTML fixes, and full URL instead of Interwiki link for feedback link. See debug diff.

Also, how about measuring and publishing the PluginBenchmarks of this Plugin?

-- PeterThoeny - 26 Feb 2005

Jacob, Thanks for the note above, I've been trying to get the CommentPlugin to work on a FreeBSD system. Your modifications seem to have worked for me as well.

Crawford, excellent Plugin now I've got it to work , thanks very much.

-- MarkHyde - 02 Mar 2005

Is there some way to display the comment prompt for "normal" viewing but hide it when using a "printable" view/skin? I'm using the CommentPlugin for an event sign up form, but when I print it out the "add my name to the list" comment is useless and just gets in the way.

-- DavidBright - 02 Mar 2005

The only thing I can suggest is an alternative comments.tmpl for the print skin i.e. comments.print.tmpl that overrides the default definitions. TBH I never really thought this aspect through.

-- CrawfordCurrie - 05 Mar 2005

are there any known problems with CP v3.009 (feb-25) and TWiki 02 Sep 2004 $Rev: 1742 $ ?

On one site when ever anyone tries to add a comment they get thrown back to the home page and the comment is not saved. The cgi-error log says

[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in pattern match (m//) at /var/www/twiki/lib/TWiki/Store.pm line 143.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in pattern match (m//) at /var/www/twiki/lib/TWiki/Store.pm line 143.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in pattern match (m//) at /var/www/twiki/lib/TWiki/Store.pm line 143.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in pattern match (m//) at /var/www/twiki/lib/TWiki/Store.pm line 143.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in pattern match (m//) at /var/www/twiki/lib/TWiki/Store.pm line 143.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in concatenation (.) or string at /var/www/twiki/lib/TWiki/Store/RcsFile.pm line 775.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in concatenation (.) or string at /var/www/twiki/lib/TWiki/Store/RcsFile.pm line 775.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in concatenation (.) or string at /var/www/twiki/lib/TWiki/Store/RcsFile.pm line 756.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in concatenation (.) or string at /var/www/twiki/lib/TWiki/Store.pm line 906.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in pattern match (m//) at /var/www/twiki/lib/TWiki/Store.pm line 143.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in substitution (s///) at /var/www/twiki/lib/TWiki.pm line 1554.
[Sun Mar 13 23:21:05 2005] viewauth: Use of uninitialized value in substitution (s///) at /var/www/twiki/lib/TWiki.pm line 1554.

Comments worked fine when the as-shipped version was being used (the site admin didn't realise it came pre-installed).

-- MattWilkie - 14 Mar 2005

There is a known issue using CommentPlugin alongside FindElsewherePlugin; see FindElsewherePluginDev.

-- CrawfordCurrie - 21 Mar 2005

With regard to suppressing the comment prompt for printing, CrawfordCurrie's suggestion of an alternative template did indeed work. There are a couple caveats:

  • Creating an empty templates/comments.print.tmpl is not enough. You also need a templates/comments.print.pattern.tmpl (at least if you use the pattern skin).
  • Make sure the template file is empty (zero length)! I tried with a template that just had a blank line (or two) and the result is the plugin complains about the templates not being defined. An empty template avoids that problem.
  • The plugin generates errors in the server log with an empty template (but at least does not splatter it on the rendered page!). To avoid that, I added the following patch:
--- lib/TWiki/Plugins/CommentPlugin/Comment.pm.orig   2005-04-12 19:39:23.633132722 -0500
+++ lib/TWiki/Plugins/CommentPlugin/Comment.pm   2005-04-12 19:40:17.867553703 -0500
@@ -98,6 +98,7 @@
     # box is (not the target of the comment!)
     my $input = _getTemplate( "PROMPT:$type", $topic, $web );
+    return '' if (!defined($input));
     return $input if $input =~ m/^%RED%/so;
     # Expand special attributes as required

-- DavidBright - 13 Apr 2005

Finally got 'round to trying #JacobsEdits, but they're still not working for me. I still get the same CommentPluginUndefinedSubRoutineOnFeb2003 :

Undefined subroutine &TWiki::Contrib::CairoContrib::handleUrlParam called at ../lib/TWiki/Contrib/CairoContrib.pm line 63.

To be sure, I've installed the latest versions of CommentPlugin, CairoContrib, and AttrsContrib. About the only thing I haven't done is break down & upgrade to CairoRelease (CarpalTunnel pain).

Any words of wisdom ?

-- KeithHelfrich - 16 Apr 2005

Keith, I vaguely recall this problem, but with everything that's going on with Dakar release I really don't want to re-release the contrib. I'm inclined to suggest you upgrade to Cairo. If you can wait for Dakar to ship I'm sure I can make time after that.

-- CrawfordCurrie - 22 Apr 2005

I've been thinking about a sticky-note feature for a while. Essentially, I am looking for a way for a reviewer to leave comments scattered around the page which the main author can then incorporate into a future revision. (The comment could be rendered as a Post-It note with a little bit of CSS). This feature would make TWiki much more accessible for anyone who is scared of or unfamiliar with TML. There are many managers who resent TWiki, since it is not easy for them to do the simple things that they have been used to in the past (comments are well supported by MS Word and Excel). On the other hand, people writing the documentation wouldn't dream of doing it any other way.

One would like to be able to add notes anywhere on the page. However, providing the ability to add/delete notes on a per-section basis would be a great start. CommentPlugin provides almost all this, except that the target location is fixed. It would be great if the user could select from a pulldown menu of section headings, and the note would get attached to the corresponding anchor. Ideally, each Post-It would also have "Edit" and "Delete" buttons for convenience.

I've also posted this in the SectionalEditPluginDev page, since it places an Edit button next to each section. A Comment button alongside could also do the above.

-- PankajPant - 05 May 2005

When using this plugin in tableappend mode (probably other modes as well), it doesn't use the default timezone of the TWiki installation (it looks like it defaults to GMTIME). Can the default timezone be set globally, or (perhaps even better) read from the TWiki preferences? (Just putting 2015-09-15 - 01:24 in the template is no good, it doesn't expand).

I guess the best approach would be to read the $displayTimeValues from TWiki.cfg, the second best to somehow allow a global switch to SERVERTIME instead of TIME / GMTIME?

-- SteffenPoulsen - 13 May 2005

It uses the TWiki default expandVariablesOnTopicCreation method, which is not fully documented but expands the following variables:

  my $today = formatTime(time(), "\$day \$mon \$year", "gmtime");
  $theText =~ s/%DATE%/$today/go;
  $theText =~ s/%USERNAME%/$theUser/go;                     # "jdoe"
  $theText =~ s/%WIKINAME%/$theWikiName/go;                 # "JonDoe"
  $theText =~ s/%WIKIUSERNAME%/$theWikiUserName/go;         # "Main.JonDoe"
  $theText =~ s/%URLPARAM{(.*?)}%/&handleUrlParam($1)/geo;  # expand URL parameters
so basically you are stuffed. This has been corrected on DevelopBranch, where GMTIME and SERVERTIME are both expanded on topic creation.

-- CrawfordCurrie - 15 May 2005

I am not seeing the comment text area nor the button. I see: "If installed correctly, you should see a %COMMENT edit box below here.

%COMMENT{type="top" target="Sandbox.Comments"}%" I installed the AttrsContrib.

-- KellyBrace - 24 May 2005

Well, upgrading to the latest CommentPlugin resulted in Perl 5.6.1 going into an unrecoverable loop. Symptoms are:

  1. view.cgi keeps growing in memory
  2. system either dies from memory starvation OR
  3. the process is manually killed

This version of CommentPlugin was upgraded from teh version that ships with the 20040902 version of twiki.

I am reverting until this problem of hogging the resources is fixed.

-- SteveRJones - 23 Jun 2005

It would also be helpful if this plugin implemented a debugging flag -- not knowing where the loop begins occurring is rather frustrating.

-- SteveRJones - 23 Jun 2005

I am using the comment plugin to add comments to a read only topic by including a "comments" topic that contains the COMMENT variable and the comments. I have added a redirect to the "comments" topic and this works well for general usage as the user is returned to the bottom of the topic they are commenting on which is where their last comment will be.

There are some instances where I would like users to access the "comments" topic on its own. this is not possible with the redirect in the topic.

Would it be possible to add a parameter to the comments plugin to redirect to a topic or url after the comment has been added?

For example: %COMMENT{redirect="topic"}% where topic could be a url, topic name, web.topic name and could include an anchor.

-- ChrisSBrown - 25 Oct 2005

How do I solve a "Change Access Denied" error? Who does the CommentPlugin run as? This plugin works properly in my unrestricted Sandbox web, but my Main web (which has DENYWEBVIEW = TWikiGuest and DENYWEBCHANGE = TWikiGuest, GuestUser) produces the "Change Access Denied" error when using the CommentPlugin. Do these settings break the plugin or is it something else?

-- DavidForrest - 02 Nov 2005

David: What is the topic you are trying to change?

Using COMMENT is no different from trying to edit. If you can edit but you can't COMMENT then you have a problem. However ...

If you are running as GUEST and the topic you are trying to change in a web that has DENY CHNAGE anf the topic does not have an explicit ALLOW, or if you are trying to change someone else's home topic in Main .... or any of the situations where normal access control would prevent you editing the topic, then this is what is expected.

-- AntonAylward - 02 Nov 2005

I can edit (as myself, a member of the TWikiadmin group, but on my Main web (with the above DENYWEB* settings in WebPreferences) COMMENT does not work.

COMMENT works fine in my unrestricted TestTopic4 but not in my TestTopic4 web.

I've been experimenting with ALLOWTOPICCHANGE, but that doesn't see to help.

-- DavidForrest - 03 Nov 2005

By adding a " * Set DENYTOPICCHANGE = NoBody" to my topic I can enable commenting and disable the

Change Access Denied
You do not have permission to change topic Main.TestTopic4.
error message, so I think it has something to do with the DENYWEBCHANGE = TWikiGuest, GuestUser settings in my Main.WebPreferences. Fiddling with that ( s/TWikiGuest/XTWikiGuest/ ) also fixes it, so it really seems like my CommentPlugin acts as if it does its edits as TWikiGuest. It doesn't seem to work this way here on http://twiki.org/

  • My Twiki version: 02 Sep 2004 $Rev: 1742 $ PLUGINVERSION=1.025 PLUGINVERSION{CommentPlugin}=3.003
  • http://twiki.org version: TWiki-6.0.0, Mon, 14 Oct 2013, build 26523 PLUGINVERSION=6.00 PLUGINVERSION{CommentPlugin}=$Rev: 24977 (2013-10-14) $

My current workaround is to add a DENYTOPICCHANGE = NoBody to pages using the CommentPlugin.

-- DavidForrest - 03 Nov 2005

Updating to the 3.009 version did not fix it.

From the WebChanges and revision history pages, I can see that the CommentPlugin is making the changes as TWikiGuest.

Upthread there was mention of the TWikiGuest user as a result of something odd in authorization, but it seemed unresolved. I have a .htaccess file with 'require valid user' for view and save, but no entry for viewauth -- it gets the default 'allow from all'. Any hints or pointers?

-- DavidForrest - 03 Nov 2005

It was an incompletely set up BasicAuthentication (TWiki.TWikiUserAuthentication#Authentication_Options) that caused my COMMENT to use TWikiGuest.

-- DavidForrest - 04 Nov 2005

I desparately need to prevent CommentPlugin from expanding certain tags (CommentPlugin calls commonTagsHandler which expands everything it sees before the topic gets saved). This seems to have come up before, but I cannot seem to find any solutions.

Any suggestions?

-- PankajPant - 25 Jan 2006

The variables I am trying to suppress are handled by a plugin that I am working on. Is there a way to tell the plugin that it is being called by the CommentPlugin's internal loop? Or, alternately, could CommentPlugin disable my plugin before calling the commonTagsHandler?

-- PankajPant - 25 Jan 2006

Here's what I came up with:

my $query = TWiki::Func::getCgiQuery();
return $_[0]
  if ($query->param('comment_action') ||
      $query->param('comment_type')   ||

Does this look reasonable?

-- PankajPant - 25 Jan 2006

We discovered a "bug". We had a page which had a help section at the top that contained a couple of %COMMENT{...}% lines in a verbatim block.

Unfortunately, the plugin thinks that these are real, and it's location count comes up 2 short (there were two of these lines). Maybe it should ignore everything in HTML comments and verbatim/pre blocks?

I just wanted to point this out. We've changed the help section to work around this.

-- PankajPant - 24 Feb 2006

Is there some way to post a comment without having change permissions to the page containing the comments. That would make a "comment once, dont change" behavior possible even for non authentication users without write permissions to a page/web/wiki.

-- TobiasRoeser - 28 Feb 2006

Why would one want to do this on a Wiki?! -- I see, you are looking for an Annotation feature. Hm, you could try the fresh TagMePlugin and see if that does what you want. -- And of course you could use the CommentPlugin to collect comments on an unlocked topic and include the results in your locked down topic. -- Once more: this is a Wiki, if that means something. wink

-- FranzJosefSilli - 28 Feb 2006

Yes I know very well what wiki means, and I use it myself in many environment with many teams. But, If you got addicted, you want to use a wiki everywhere or at least in as many places as possible just because it is easy to setup and easy to produce content and navigation. But for some public content e.g. blogs or some kind of news, you have to ensure, that the original content could not be changed by other persons. If you want comments, it is sometime not appropriate to force the "guests" to register on a foreign site and remember logins and passwords. (This is typical for Open Source! People tents to do with it anything that is somehow possible. And they (including me) don't care if this is the intended use of the software, or not. smile Sorry bad English.)

-- TobiasRoeser - 28 Feb 2006

I have two questions about CommentPlugin:

  • I have MainTopic that includes IncludedTopic with comment in it. Any time I add a comment my browser goes from the MainTopic to IncludedTopic. How to prevent such behaviour? (I have heard about RedirectPlugin, but using this one does not allow to view the IncludedTopic separately.)
  • When sb. comments a topic all URL parametres are lost. Is there any possibility to store this URL parametres somehow to use them after commenting?

-- JacekSzkutnik - 07 Mar 2006

Problems including TWiki.UserCommentsTemplate:

I created a TWiki.UserCommentsTemplate with custom comment templates, but it doesn't seem to be included in TWiki.CommentsTemplate (I get the message No such template def TMPL:DEF{PROMPT:innlegg} in topics using %COMMENT{type="innlegg"}%.

I experimented with variations on the %TMPL:INCLUDE{"%TWIKIWEB%.UserCommentsTemplate"}% in TWiki.CommentsTemplate, and it seems that INCLUDE ing UserComments or TWiki.UserCommentsTemplate works, but none of UserCommentsTemplate, TWiki.UserComments, %TWIKIWEB%.UserComments or %TWIKIWEB%.UserCommentsTemplate work.

(TWiki 4.0.1, with CommentPlugin (Dakar, 8164).)

Is this a bug in CommentPlugin, or in TWiki, or is there something I've misunderstood?

-- BjornHelgeMevik - 18 Mar 2006

Ah. I see now that this has been reported and fixed already. I'm sorry; I should've checked that first.

-- BjornHelgeMevik - 19 Mar 2006

We added a couple of more parameters comment_removeprompt (deletes the comment box) and comment_postandremoveprompt (posts the message and deletes the comment box).

This is useful in some cases where the comment box is needed only once, e.g. in meeting minutes. Each meeting has a box for entering minutes, action items, etc, and once the scribe submits it, the form goes away, which keeps the page nice and tidy. There are many other places where we use this.

The changes required to Comment.pm are very minimal: copy _nth() to _delete_nth(), make the changes and call it in the correct places.

Thought that I'd share this with everybody.

-- PankajPant - 04 Apr 2006

Hi Pankaj, this is exactly what I need! Would it be possible to make these changes and upload a new version to the CommentPlugin topic? (It has a FeelFreeToModify policy, and alas... I can't code...

Would be great!

-- JosMaccabiani - 01 May 2006

The comment plugin is maintained in subversion. You are welcome to make changes in subversion on 2 conditions; first, that all the unit tests are run and pass before checkin, and second, that you document you changes (user docs and code docs).

It would be great if you could share your code!

-- CrawfordCurrie - 02 May 2006

The CommentPlugin can't comment on a i18n topic. Like that: TesteAurélio.

-- AurelioAHeckert - 03 May 2005 15:06:16

_Aurélio, I put a comment in TesteAurélio - can you be more specific regarding your problem?

-- SteffenPoulsen - 13 May 2005

I've uploaded a patch against CommentPlugin version 3.0009 (downloaded from CommentPlugin r1.57). Could someone run the necessary checks in subversion and incorporate the changes if they seem OK? I haven't checked out the patched file myself, since we are on the original version bundled with Cairo.

-- PankajPant - 05 May 2006

I'm hoping to use CommentPlugin to add a link to the bottom of a topic page so that the user can easily subscribe to WebNotify for that topic.

However, I am finding that only some variables are expanded before being inserted in the page. For example %WIKIUSERNAME% is expanded and hence the actual username is inserted into the page, but %TOPIC% is inserted as %TOPIC% and hence only expanded (to WebNotify) when WebNotify is viewed. I would want it to display the topic where the link is inserted.

Would be grateful for any comments.

-- MartinMoss - 13 May 2006

Have found a work-round - apologies if this is stating the obvious! (I'm new to this!)

within the prompt template - just defined a hidden field, e.g.

<input type="hidden" name="sourcetopic" id="sourcetopic" value=%TOPIC%>

and then just used %URLPARAM{"sourcetopic"}% in the output template.

Appreciate any comments as to whether you think this is OK or am I missing something?

-- MartinMoss - 16 May 2006

That's an excellent solution! smile

-- CrawfordCurrie - 17 May 2006

WIBNIF people could use format, header and footer parameters in very much the same way as with the %SEARCH% variable. IMHO that would allow easy customization of the look and feel. I find having to use TWiki template a bit too heavy. Maybe it's just because I'm not familiar with them. I have the impression that I have to change templates on the server side to modify the rendering of comments or am I missing something? With format, header and footer it would be dead easy to do from your web browser.

Ok one does not have to go to the server, in fact one can just do it from CommentPluginTemplate or UserCommentsTemplate. It's actually quite easy to do. I should read the doc first smile

-- StephaneLenclud - 05 Sep 2006

Actually, I find your idea good for this scenario: If I want to create a simple form used just once, WIBNIF you could define the form and the output simply with %COMMENT{}% parameters?

-- PeterThoeny - 05 Sep 2006

Yeah, it's a good idea. Added to the WIBNIF list.

-- CrawfordCurrie - 06 Sep 2006

Can anyone tell me if I can use the spreadsheet plugin in the comment plugin template?

-- CarlMcKinney - 06 Sep 2006

Didn't you simply try it? wink IIRC it depends on the PluginsOrder specified via configure. I think the SSP must have been loaded before the CommentPlugin.

-- FranzJosefSilli - 06 Sep 2006

Crawford, this is probably a stupid question, but what does "done by CrawfordCurrie in 11359" imply? That is, where do I download the files from?

-- PankajPant - 26 Sep 2006

The number refers to the subversion check-in number. The plugins repository is currently at http://develop.twiki.org/svn/twiki/branches/TWikiRelease04x00/twikiplugins/ Check the plugin topic to see if the latest version is already published.

-- PeterThoeny - 30 Sep 2006

This topic is getting very big; also, it makes it difficult to find out what has been added since there are several comment boxes. Time to put some into the CommentPluginDevArchive?

-- PeterThoeny - 07 Oct 2006

For a long time, I've been convinced that this plugin can be used to make uploading files easier for users of our wiki. Well I've done it (I think!). See attached file Comment.pm_attachfiles. The changes I made are:

  1. Use upload script instead of save script (Note: A small change to Upload.pm would allow the upload script to be used even if there is no file. At present, it throws an error.)
  2. Use enctype=>'multipart/form-data'
  3. Define some additional variables to allow file information (name, comments, type) to be defined in the template

Here's the template I use:

<table width="100%">
<tr valign="middle"><td colspan=3><textarea %DISABLED% rows="5" cols="80"  name="filecomment"  wrap="soft"></textarea></td>
<tr><td align="left"><input %DISABLED% type="submit" value="%button|Add Comment%" /></td>
<td >Attach a file: <input type="file" name="filepath" value="%FILEPATH%" size="40" /></td>

%POS:BEFORE% %URLPARAM{"filecomment" newline="<br />"}%



-- JohnFitzpatrick - 06 Feb 2007

Fascinating idea.

-- FranzJosefSilli - 08 Feb 2007

IMPORTANT ISSUE: save script bug

We have the following problem with the Plugin. When user is not logged in and trying to "Add comment" he is redirected to login form and after that gets the following oopsattention message: Incorrect parameters to the save script. Has anyone else experienced the problem?

-- JacekZapotoczny - 11 Oct 2006

I have, infact, i found this topic by doing a good search to find a solution.

When a user is Logged in already, the CommentPlugin works fine, however if the user is not logged in he is redirected to


appears to be the same exact issue as JacekZapotoczny describes here.

I am using Dakar TWiki 4.0.4 with latest CommentPlugin package.

-- TravisBarker - 29 Oct 2006

my TWiki is located at http://postlogger.com/twiki/bin/view feel free to Register there and give it a try.

to reproduce the issue in question simply register, log out and then attempt to post a comment to any page using one of the CommentPlugin POST boxes

-- TravisBarker - 29 Oct 2006

no reply for quite some time so I'm just doing a status check, who is maintaining this plugin?

-- TravisBarker - 09 Jan 2007

The primary maintainer is CrawfordCurrie. He prefers bugs to be reported at Bugs:CommentPlugin.

-- PeterThoeny - 10 Jan 2007

I prefer questions to be asked in the Support web, usually because I'm not the only one who can answer them! Real bugs with reproducable testcases need, as Peter said, to be reported at Bugs:CommentPlugin.

Because this question was embedded into the middle of this topic, I missed it completely.

Note that this is clearly not a common problem, as COMMENT works fine here and on most other TWiki sites. Therefore it is an issue with your specific configuration. Please report your detailed configuration when you raise the support query, especially versions of CGI, what browser you are using etc. Thanks.

-- CrawfordCurrie - 10 Jan 2007

This topic needs refactoring. Readers are easily list, there are three(!) comment boxes. I suggest to move the "wouldn't it be nice if" section to the top or to a new topic, to move old comments to the archive, and to have only one comment box (at the bottom.)

-- PeterThoeny - 10 Jan 2007

Any one know the syntax to provide a default value to be placed in the COMMENT box? I notice below it states that this was done by CrawfordCurrie, but I don't see any documentation of the syntax to use this feature on the CommentPlugin page.

-- EricHanson - 10 Nov 2006

Is there a way to extract the first line of the comment? The idea would be to take the first line of the comment and treat it as a heading. So the standard one liner template looks like so:

%TMPL:DEF{outputoneliner}%   * %URLPARAM{"comment"}% -- %WIKIUSERNAME% - %SERVERTIME%%TMPL:END%
can this be changed to something like this:
%TMPL:DEF{outputoneliner}%*%URLPARAM{"commentfirstline"}%*%BR%%URLPARAM{"comment"}% -- %WIKIUSERNAME% - %SERVERTIME%%TMPL:END%
This is a poor example but I just thought I'd use it to illustrate the point (hopefully). Does this ability already exist or does anyone know how this would be done?

-- RobLeach - 21 Nov 2006

Eric, I uploaded the latest version in subversion, which has the default parameter.

Rob, no.

-- CrawfordCurrie - 22 Nov 2006

comment_removeprompt and comment_postandremoveprompt are not documented.

-- ArthurClemens - 27 Nov 2006

Hi Arthur, I have attached a template definition which is usefull at our site. Maybe its interesting to put it in the default template styles. Its named belowthreadmode, which fixes the position of the comment edit box an append the comments in threadmode below the box.

Comments, signed and dated, added recurse after comment box




-- ThomasFreudenberg - 28 Nov 2006

Thomas, I've added your example, as well as an example for target that redirects the user to the topic the prompt is in (using form param origurl, see FlexibleReturnFromEdit).

-- ArthurClemens - 03 Dec 2006

I have added new template bulletabove to add items to a bullet list.

-- ArthurClemens - 10 Dec 2006

Thanks Arthur, it's really excellent to get some help with maintaining this beast!

-- CrawfordCurrie - 11 Dec 2006

I have added 2 examples:

  • return to show how to automatically return to the same topic after saving the comment (for TWiki 4.1)
  • noform to show how to pass custom parameters with the save form

-- ArthurClemens - 19 Dec 2006

I've created a comment template for capturing user input. How can I make some fields of the comment template mandatory so that the user is unable to submit the comment form with an empty field. I tried to validate my comment template fields via a Java Script function that I downloaded from the following site. But it did not work with CommentPlugin.


-- AlokNarula - 20 Mar 2007

Can't say was you problem was there. I've implemented validation in comment templates using js so i know it's workable. It can be a bit tricky though...

-- LynnwoodBrown - 20 Mar 2007

Hi Lynnwood, could you pls share your example either on this page or on the Support Web

-- AlokNarula - 21 Mar 2007

I have create a new update: it is now possible to define a comment template in any topic.

-- ArthurClemens - 08 Apr 2007

Very useful addition, thanks Arthur!

-- PeterThoeny - 09 Apr 2007

can anyone help with HowToMakeCommentFieldMandatory ?

-- SvenDowideit - 28 Apr 2007

We incorporated GoogieSpell into our default UserCommentsTemplate promptbox.

An issue arose when there are more than a single %COMMENT{}% in a single topic. The supporting javascript needs a unique variable for each textarea. We didn't want to require that each usage have an incremented index variable ala %COMMENT{index="1"}%.

So we added an internal %COMMENT_UNIQUE% variable which starts at zero (using the internal variable $$pidx). This was a simple change in CommentPlugin/Comment.pm.

# PRIVATE generate an input form for a %COMMENT tag
sub _handleInput {
    if ( $input !~ m/^%RED%/ ) {
        $input =~ s/%DISABLED%/$disable/g;
        $input =~ s/%MESSAGE%/$message/g;
        my $n = $$pidx + 0;

        $input =~ s/%COMMENT_UNIQUE%/$n/ge;  # EXPAND internal index

        if ( $disable eq '' ) {

My question? Is this re-inventing something which already exists? And if not, is it a useful addition?

-- CraigMeyer - 09 May 2007

Each comment form already has a unique identifier. The textarea within the form can be reached using that id.

-- ArthurClemens - 09 May 2007

(modified...after re-reading ...)

Arthur, Yes, thanks. That does solve the problem of uniquely referencing the textarea. The supporting Javascript also needs a unique object for Googiespell, for each textarea instance. This is done, at the time the prompt template is expanded for display, and also supports only including the needed JS code once. I am doing something like:

%IF{ " %COMMENT_UNIQUE% <= 0" then="... load up the needed javascript ..." }%
var googie_spell%COMMENT_UNIQUE% = new Googiespell( ... );
So, each textarea instance gets it's own unique javascript object. (This is only an issue when there are multiple %COMMENTS% in a topic) Maybe the new variable should be called %COMMENT_INDEX%?

-- CraigMeyer - 09 May 2007

I'm having (I think) a similar problem / question. I have a custom comment template that works great when it's the only %COMMENT% prompt in the topic.

But when there are two %COMMENT% tags in the same topic, inputs from the TOP comment box are inserted above the BOTTOM one, which ruins the application. What is the way to handle this ?

-- KeithHelfrich - 15 Jul 2007

Do you have this problem with on the CommentPluginExamples topic as well?

-- ArthurClemens - 15 Jul 2007

Can't test there because I don't have permission on CommentPluginExamples. This is for my development of the QuickCheckListApp, which isn't able to be demonstrated on twiki.org, either.

The QuickCheckListApp works perfectly if it's the ONLY %COMMENT% on the page. But like twiki.org, all of my topics have a comments section at the bottom. And in that case, input from the QuickCheckListApp gets inserted above the comment box at the bottom of the topic.

Guess my questions are :

  • shouldn't each COMMENT box have a unique ID ?
  • If they do, then why doesn't it work ?
  • Can I set %COMMENT{id="myName"}% ?

-- KeithHelfrich - 15 Jul 2007

Note that the same buggy behaviour was happening in the QuickCheckListApp topic itself until I fixed the bottom comment tag with


Otherwise, new comments were being inserted into the verbatim code of the instructions...

Since it's not always possible to use the target work-around, we need a clean way to distinguish between multiple COMMENT tags that are on the same page. Especially as ever increasing numbers of TWikiApplications use the comment templates to do their dirty work.

-- KeithHelfrich - 15 Jul 2007

But you can try CommentPluginExamples in your own installation. I have created that example page and never noticed any problems before.

-- ArthurClemens - 15 Jul 2007

I've fixed the COMMENT box on this topic, also, with a target. Otherwise, the comments were being inserted above in the verbatim of my example. To me this is a problematic behaviour which doesn't allow for multiple comment templates to co-exist in the same topic.

-- KeithHelfrich - 16 Jul 2007

For what it is worth....

In our version of CommentPlugin "13353 (10 Apr 2007)", I added a single line to the CommentPlugin/Comment.pm, which creates a new %COMMENT_INDEX% variable. It starts at zero and increments for each %COMMENT{}% placed on the page.

sub _handleInput {
    # Expand special attributes as required
    $input =~ s/%([a-z]\w+)\|(.*?)%/_expandPromptParams($1, $2, $attrs)/ieg;
    $input =~ s/%COMMENT_INDEX%/$$pidx/ge;   # 7/18/2007 CRM

This allows us to use GoogieSpell on each Comment without collision problems.

Here is the code for the promptbox in UserCommentsTemplate

%TMPL:DEF{promptbox}%%IF{ "  %COMMENT_INDEX% <= 1 " then='
<script type="text/javascript" src="%PUBURLPATH%/TWiki/GoogieSpell/AJS.js"></script>
<script type="text/javascript" src="%PUBURLPATH%/TWiki/GoogieSpell/googiespell.js"></script>
<script type="text/javascript" src="%PUBURLPATH%/TWiki/GoogieSpell/cookiesupport.js"></script>
<link href="%PUBURLPATH%/TWiki/GoogieSpell/googiespell.css" rel="stylesheet" type="text/css" />' }%
<table><tr valign="middle"><td><textarea %DISABLED% rows="%rows|5%" cols="%cols|80%" id="comment_%COMMENT_INDEX%" name="comment" wrap="soft" onfocus="if(this.value=='%MESSAGE%')this.value=''" onblur="if(this.value=='')this.value='%MESSAGE%'">%MESSAGE%</textarea>
<script type="text/javascript">
  var googie_%COMMENT_INDEX% = new GoogieSpell("%PUBURLPATH%/TWiki/GoogieSpell/", "%SCRIPTURL%/send_aspell?lang=");
</td><td><input %DISABLED% type="submit" value="%button|Add comment%" CLASS="actionButton" /></td></tr></table>

-- CraigMeyer - 18 Jul 2007

I am having difficulty making the "templatetopic" feature work.

I've tried it on three installations of TWIki: twiki.org, our company's beta server (which I am assured ha the latest CommentPlugin installed) and my persnal desktop system, which is running CommentPlugin version $Rev: 11359 $. All fail.

twiki.org test pages are visible: Sandbox.VickiCommentTemplate

I copied the examples straight from the documentation. Is there something missing?

-- VickiBrown - 21 Jul 2007

I must also point out that the Plugins.CommentPlugin page contains many tempting references to non-existing documentation, e.g. CommentPluginExamples

-- VickiBrown - 21 Jul 2007

is there any way to place some default "starter text" inside of the promptbox ?

I would like to have a prompt box that comes pre-filled with empty <verbatim></verbatim> tags ..

-- KeithHelfrich - 12 Aug 2007

Variation on threadmode with the blanking javascript removed.

%TMPL:DEF{PROMPT:keepdefault}%<div class="commentPlugin commentPluginPromptBox"><table border="0" cellpadding="0" cellspacing="0"><tr valign="middle"><td><textarea %DISABLED% rows="%rows|3%" cols="%cols|70%" name="comment" class="twikiInputField" wrap="soft" >%MESSAGE%</textarea></td><td>&nbsp;<input %DISABLED% type="submit" value="%button|Add comment%" class="twikiButton" /></td></tr></table></div><!--/commentPlugin-->%TMPL:END%




| I could add my web-wide templates to the site-wide instead of oiverriding TWiki.<nop>UserCommentsTemplate with %<nop>WEB.<nop>UserCommentsTemplate | Main.VickiBrown | 31 Aug 2007 - 13:40 |
|  | Main.EricCharikane | 12 Sep 2007 - 03:09 |
%COMMENT{templatetopic="%TOPIC%" type="keepdefault" default="<%NOP%verbatim><%NOP%/verbatim>"}%

If you will be using it a lot, putting the template in your UserCommentsTemplate with the verbatim surrounding the MESSAGE would save entering templatetopic and default every time.

-- JustinLove - 13 Aug 2007

I apparently don't understand how %TMPL:INCLUDE{"...}% is supposed to work.

I tried adding

to my %WEB/<nopUserCommentsTemplate because I would prefer to merge web additions with site-wide raqther than overriding! But I get errors when I try to use a template from the TWiki.UserCommentsTemplate.

What am I doing wrong?

-- VickiBrown - 31 Aug 2007

Just curious: will it be possible to use TinyMCE within comments?

-- FranzJosefGigler - 12 Sep 2007

Topic attachments
I Attachment History Action Size Date Who Comment
Compressed Zip archivezip comment-oct02.zip r1 manage 9.9 K 2003-10-02 - 17:34 PeterMasiar Comment 2.0 beta
Texttxt commentpluginfromatemplate.txt r1 manage 0.6 K 2003-05-06 - 08:08 MartinCleaver add to the end if no COMMENT found
Compressed Zip archivezip cpluginlockfix.zip r1 manage 4.7 K 2002-12-11 - 20:53 JonLambert locking issues
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2009-03-27 - VickiBrown
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.