• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

I have in my LocalSite.cfg

$TWiki::cfg{PluginsOrder} = 'SpreadSheetPlugin';
$TWiki::cfg{Plugins}{TestFixturePlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{TablePlugin}{Enabled} = 1;
$TWiki::cfg{Plugins}{SpreadSheetPlugin}{Enabled} = 1;

%ACTIVATEDPLUGINS% shows:

Activated plugins: SpreadSheetPlugin, SpreadSheetPlugin, TablePlugin, TestFixturePlugin 

TW


reviewing at the code in lib/TWiki/Plugins.pm, it looks like %PLUGINDESCRIPTIONS% and %FAILEDPLUGINS% would also suffer the same fate.

in Plugins.pm, load() says:

            # Note this allows the same plugin to be listed
            # multiple times! Thus their handlers can be called
            # more than once.
is that actually the desired behaviour?

i thought that making sure that $this->{plugins} doesn't have multiple instances of the plugin listed would be the way to fix this; however, it looks like plugin handlers might be relying on that behaviour (in some extreme cases)

WN

Yes, it's desired behaviour. It's the way Cairo worked. I can imagine a situation where you might actually use it, as well.

However in Thomas' example above, the SpreadSheetPlugin second instance should have been elided by the listing in INSTALLEDPLUGINS - that's where the bug is.

This is important, because it might have undesireable side-effects.

CC

Index: Plugins.pm
===================================================================
--- Plugins.pm  (revision 6663)
+++ Plugins.pm  (working copy)
@@ -189,7 +189,7 @@
             # Note this allows the same plugin to be listed
             # multiple times! Thus their handlers can be called
             # more than once.
-            push( @{$this->{plugins}}, $p );
+            push @{$this->{plugins}}, $p;
             my $anotherUser = $p->load();
             if( $anotherUser ) {
                 if( $userDefiner ) {
@@ -208,6 +208,7 @@
             $lookup{$pn} = $p;
         }
     }
+    @{$this->{plugins}} = _unique_list( @{$this->{plugins}} );

     return $user;
 }
@@ -759,4 +760,22 @@
     return $this->_dispatch( 'renderWikiWordHandler', @_ );
 }

+=pod
+
+---++ _unique_list( @array ) -> @unique_array
+
+Returns the unique elements of @array _while preserving order_
+
+=cut
+
+sub _unique_list
+{
+    my ( %seen, @unique );
+    foreach my $atom ( @_ )
+    {
+       unless ( $seen{ $atom } ) { push @unique, $atom; $seen{ $atom } = 1 }
+    }
+    return @unique;
+}
+
 1;

WN


What if a plugin is listed twice in the plugins order deliberately (e.g. so it is run before a certain plugin and then again after it)?
  • heavy sigh. i didn't realise that was a requirement; i will adjust the patch.

Oh, and do me a favour and document what @_ and $_ mean wherever you use them? To someone not immersed in Perl, that unique_list function (while efficient) would be rather obscure.

  • you've got to be kidding me... document what @_ means? where else in the code does that happen? i'd hardly call knowing what @_ is is "being immersed in perl", it's like on the first page of subroutines. if you don't know what @_ means, then i don't want you touching the code anyway... no, i will not document what @_ means. WN
    • however, if you'd rather have a local variable for the loop, i'm ok with that----no problem (adjusted code) WN
      • WN, I think all what CC was asking for is to have an indication of what these variables are being used for (in a sense, assigning $_ to a local variable is documentation, but it does cause an additional assignment). --TW

CC

Index: Plugins.pm
===================================================================
--- Plugins.pm  (revision 6671)
+++ Plugins.pm  (working copy)
@@ -172,7 +172,10 @@
         if( $TWiki::cfg{PluginsOrder} ) {
             @pluginList = split( /[,\s]+/, $TWiki::cfg{PluginsOrder} );
         }
-        push( @pluginList, sort keys %{$TWiki::cfg{Plugins}} );
+       foreach my $plugin ( sort keys %{$TWiki::cfg{Plugins}} )
+       {
+           push @plugInList, $plugIn unless grep { /^$plugin$/ } @plugInList;
+       }
         if ( $query && defined( $query->param( 'debugenableplugins' ))) {
             @pluginList = split( /[,\s]+/, $query->param( 'debugenableplugins' ));
         }
@@ -189,7 +192,7 @@
             # Note this allows the same plugin to be listed
             # multiple times! Thus their handlers can be called
             # more than once.
-            push( @{$this->{plugins}}, $p );
+            push @{$this->{plugins}}, $p;
             my $anotherUser = $p->load();
             if( $anotherUser ) {
                 if( $userDefiner ) {

SVN:6675

WN

ItemTemplate
Summary Plugins may show repeatedly in %ACTIVATEDPLUGINS%
ReportedBy ThomasWeigert
AppliesTo Engine
Priority Urgent
CurrentState Closed
WaitingFor

Checkins 6675 6676 6677
Edit | Attach | Watch | Print version | History: r12 < r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r12 - 2005-09-30 - ThomasWeigert
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback