CommentPluginDev Archive

A LOT OF EARLIER (IRRELEVANT) MATERIAL DELETED!

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%'"
  >%INITIAL_TEXT%</textarea>
</form>

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
• 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 127.0.0.1] (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)

doesn't get proper default values

with v. 1.1: a) CommentPlugin page won't render (looks blank) b)

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

Thanks!

-- 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).

-- 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 ).

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:

%CALENDAR%
%COMMENT%

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: AnonymousDonor? s, 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. AnonymousDonor? s 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

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) {DISABLED} %CMT:DISABLED%   {LOCKMSG} %CMT:LOCKMSG%   {ID} %CMT:ID%   {DATE} %DATE%   {TIME} %TIME%   {GROWHEAD} %CMT:GROWHEAD%   {GROWTAIL} %CMT:GROWTAIL%     %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.

Comments?

-- 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.

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? 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.

-- 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";
     }
     $$pidx++;
     return $input;

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

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" ) ||
        $defaultType;
+    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";
     }
     $$pidx++;
     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.
    Top level Second level Third level Fourth level
    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:

• The nasty {...} syntax in templates - ThomasWeigert, MS, CrawfordCurrie, PeterThoeny
  • implemented in the chop-down
• Get rid of the savecomment script - use beforeSaveHandler instead - PeterThoeny x 7
  • implemented in the chop-down

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.

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.

• I've fixed my problem with international topic names: CommentPluginAndInternationalTopicName. -- OgnyanKulev - 11 Mar 2004
• There's a simple change to fix this issue (see CommentPluginAndInternationalTopicName). Crawford, could you apply this? I've also created InternationalisingYourPlugin as a placeholder for plugin developers - any plugins that use their own forms within TWiki pages will need updating to work properly with international characters in topic names, when using Mozilla-based browsers. --Main.RichardDonkin

-- OgnyanKulev - 07 Mar 2004

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

-- SteveRJones - 11 Mar 2004

PTh

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

CC

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

PTh

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.

CC

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

MC

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

MC

We used not to need the {} after COMMENT, i.e.

should work. That plugins handle their own invocation allows for this inconsistency.

CC

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.

PTh

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

CC

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

MC

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 . . . ".

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.

-- SteveRJones - 11 Mar 2004