***

   web1.topic1
      include web2.topic2
          include web3.topic3
              include web1.topic4
                 ***
          include topic5
       include topic 6

If this is true, how does a plugin get the name of the TOPIC variable? If this isn't true do we need an % INCLUDEDTOPIC% variable??

This came up in the context of CommentPlugin. If a page with a comment block is % INCLUDEed% or view in a BookView search the button that installs the comment has an action that is set to topic1.

From the comment in Plugins.pm:

sub commonTagsHandler
{
    # Called by sub handleCommonTags, after %INCLUDE:"..."%
#    my( $text, $topic, $theWeb ) = @_;
    unshift @_, ( 'commonTagsHandler' );
    &applyHandlers;
    $_[0] =~ s/% PLUGINDESCRIPTIONS%/&handlePluginDescription()/geo;
    $_[0] =~ s/% ACTIVATEDPLUGINS%/&handleActivatedPlugins()/geo;
}

it looks like there is no way for the plugin to get the name of the current topic since the including has already occured and I think from my reading of the code the % TOPIC% and other variables have already been substituted.

The Comment plugin uses:

$text="\n\n<form name=\"comment\" action=\"$TWiki::scriptUrlPath/savecomment
$TWiki::scriptSuffix/$web/$topic\" method=\"post\">\n";

to create the action. Any ideas on what this should be to get the value of % TOPIC% as I show in the table above?

In place of that, is there anyway of telling if a % COMMENT% variable is comming from an included file rather than from the topic1 file? At least in that case the code could simply not render the comment in the base page.

My comments in Plugins.CommentPluginDev has some additional musings.

-- JohnRouillard - 10 Dec 2001

This would be easier to track from a plugin's perspective if the including could happen just after informing the plugins with a preIncludeHandler hook - as I've just added to the MorePluginHooks page...

-- TWikiGuest - 03 Feb 2002