Plugins WebTags:
CommentPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on CommentPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the CommentPlugin bug database.
• See CommentPluginDevArchive for older discussions.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the CommentPlugin bug database.
• See CommentPluginDevArchive for older discussions.
Feedback on CommentPlugin
Older feedback moved to CommentPluginDevArchiveOlder stuff moved to archive 21 Feb 2004 I've uploaded a revision with the following changes:
- Uses viewauth technique to do save
- Removes concept of REFRESH message
- Adds nonotify= parameter to COMMENT
- Moves templates fully into topics, with a hook for including site-specific templates
- re-supports %COMMENT%
- RichardDonkin's internationalisation fix incorporated
action template (and some formatting). It seems not to work properly on my system (using the latest ActionTrackerPlugin 
). 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:
%TMPL:DEF{OUTPUT:action}%
%POS:BEFORE%%NOP{%ACTION}%{ state="open" creator="%WIKIUSERNAME%" due="%URLPARAM{"due"}%" created="%GMTIME{"$day-$month-$year"}%" who="Main.%URLPARAM{"who"}%" }% %URLPARAM{"comment"}%
%TMPL:END%
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
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
);
! BEGIN {
! $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, @_ );
}
}
1;
--- 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, @_ );
}
1;
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
- 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
- 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) - No leading dash; text should be preserved "as is"
- TWikiML should be preserved, including tables and bullets
- 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.
- I disagree. I have had several requests for the time, especially where multiple timezones are involved.
- See your remarks about security
- See your remarks about security
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" ) {
to
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:
- Changed default type to
above, this is the usual linear collaboration we have here on TWiki.org - Added a
outputstandardtemplate definition to CommentsTmpl that preserves entered text as is, and appends a signature exactly like we are used at TWiki.org - Changed the
OUTPUT:aboveandOUTPUT:belowtemplate definitions to use theoutputstandardtemplate definition.
- Copied Attrs.pm back to the CommentPlugin subdir (where it used to be)
- Named the module
TWiki::Plugins::CommentPlugin::Attrsand fixed the code accordingly.
*** 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;
!
! BEGIN {
! 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 ) );
return;
}
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.
- Sure. I just noticed that it existed, I didn't look to see who defined the poll. - MC
- 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.
nameis the form field name. (With no output in view.)
%TMPL:DEF{PROMPT:patternbugreport}%(space)
| 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 "
". 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" />
- -- MartinCleaver - 26 Sep 2004
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)
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:
- http://twiki.org/cgi-bin/rdiff/Sandbox/CommentPluginTest?rev1=1.6&rev2=1.5 - comment_index values: 0,0 (both boxes current)
- http://twiki.org/cgi-bin/rdiff/Sandbox/CommentPluginTest?rev1=1.5&rev2=1.4 - comment_index values: 0,0,0,2,0 (first removed, second already present, third and fourth removed, fifth already present)
- http://twiki.org/cgi-bin/rdiff/Sandbox/CommentPluginTest?rev1=1.4&rev2=1.3 - comment_index values: 0,0,1,2,4,5 (first removed, the rest added this diff)
.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 twikiDiffDeletedText 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
#anchornamein your page, then the comment ("comment text here") is added on the same line, as such
#anchornamecomment text hereI 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)
- Note : filed a bug report on this one : CommentPluginOnAnchorsBroken -- OlivierBerger - 24 Feb 2005
- An error in
CommentPlugin.pmmade it impossible to add comments in Danish named topics (using Firefox) - IE no problem
- The problem was UTF8 characters in
$query->path_info()inCommentPlugin.pm
- See attached CommentPlugin-UTF8-bugfix.diff
- Diffed with
CommentPlugin.pmversion 3.008
-- 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.Regards -- MarcoPaganini - 13 Jan 2005 %PLUGINVERSION{"CommentPlugin"}% is supposed to do it. The version here is $Rev: 14736 (05 Sep 2007) $. 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
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 :
$theText =~ s/%URLPARAM{(.*?)}%/&handleUrlParam($1)/geo; # expand URL parameters
to
$theText =~ s/%URLPARAM{(.*?)}%/TWiki::handleUrlParam($1)/geo; # expand URL parameters
- Edit /var/lib/twiki/lib/TWiki/Plugins/CommentPlugin/Comment.pm :
$output = TWiki::expandVariablesOnTopicCreation($output);to
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.tmplis not enough. You also need atemplates/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 %SERVERTIME% 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: -
view.cgikeeps growing in memory - system either dies from memory starvation OR
- the process is manually killed
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-4.1.1, Mon, 05 Feb 2007, build 12770 PLUGINVERSION=1.11 PLUGINVERSION{CommentPlugin}=$Rev: 14736 (05 Sep 2007) $
my $query = TWiki::Func::getCgiQuery();
return $_[0]
if ($query->param('comment_action') ||
$query->param('comment_type') ||
$query->param('comment_index'));
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.
-- 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. 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?
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!
-- 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
-- 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? 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: - 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.)
- Use enctype=>'multipart/form-data'
- Define some additional variables to allow file information (name, comments, type) to be defined in the template
TMPL:DEF{PROMPT:attach}%
<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>
</tr></table>
%TMPL:END%
TMPL:DEF{OUTPUT:attach}%
%POS:BEFORE% %URLPARAM{"filecomment" newline="<br />"}%
%POS:BEFORE%%COMMENT_FILESTART% * [[%ATTACHURLPATH%/%COMMENT_FILENAME%][%ICON{%COMMENT_FILETYPE%}% %COMMENT_FILENAME%]] %COMMENT_FILEEND%
-- %WIKIUSERNAME% - %DATE%
%TMPL:END%
-- 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 followingoopsattention 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
/twiki/bin/oops/Main/WebHome?template=oopsattention;def=bad_script_parameters;param1=save
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.
---+++belowthreadmode
Comments, signed and dated, added recurse after comment box
<verbatim>
%TMPL:DEF{PROMPT:belowthreadmode}%%TMPL:P{promptbox}%%TMPL:END%
</verbatim>
<verbatim>
%TMPL:DEF{OUTPUT:belowthreadmode}%%POS:AFTER%
---++++ %WIKIUSERNAME% - %SERVERTIME%
%URLPARAM{"comment"}%
%TMPL:END%
</verbatim>
-- 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: -
returnto show how to automatically return to the same topic after saving the comment (for TWiki 4.1) -
noformto show how to pass custom parameters with the save form
%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:
%DEF:TMPL{promptbox}%
%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"}%?
#InsertHere
%COMMENT{target=#InsertHere}%
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=");
googie_%COMMENT_INDEX%.decorateTextarea("comment_%COMMENT_INDEX%");
</script>
</td><td><input %DISABLED% type="submit" value="%button|Add comment%" CLASS="actionButton" /></td></tr></table>
%TMPL:END%
-- 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 "star