PROPOSAL: Better handling of plugin settings in upgraded environments

This proposal has a minor code change, but is a fairly important logic change in many respects. First the code then a discussion:

--- Plugins.pm  2003-12-19 13:32:02.000000000 +0000
+++ Plugins.pm.localoverride    2004-01-14 15:57:27.000000000 +0000
@@ -96,10 +96,11 @@

     # look for the plugin installation web (needed for attached files)
     # in the order:
-    #   1 fully specified web.plugin
-    #   2 TWiki.plugin
+    #   1 fully specified web.plugin - deprecated
+    #   2 %MAINWEB%.plugin
     #   3 Plugins.plugin
-    #   4 thisweb.plugin
+    #   4 TWiki.plugin
+    #   5 thisweb.plugin

     my $installWeb = '';
     # first check for fully specified plugin
@@ -114,12 +115,16 @@
     }

     if( ! $installWeb ) {
-        if ( &TWiki::Store::topicExists( $TWiki::twikiWebname, $plugin ) ) {
-            # found plugin in TWiki web
-            $installWeb = $TWiki::twikiWebname;
+        # See Codev.AllowLocalPluginSettingsToOverrideDistribution
+        if ( &TWiki::Store::topicExists( $TWiki::mainWebname, $plugin ) ) {
+            # found plugin in the "main" web. (Which is of course the user web)
+            $installWeb = $TWiki::mainWebname;
         } elsif ( &TWiki::Store::topicExists( "Plugins", $plugin ) ) {
             # found plugin in Plugins web
             $installWeb = "Plugins";
+        } elsif ( &TWiki::Store::topicExists( $TWiki::twikiWebname, $plugin ) ) {
+            # found plugin in TWiki web
+            $installWeb = $TWiki::twikiWebname;
         } elsif ( &TWiki::Store::topicExists( $web, $plugin ) ) {
             # found plugin in current web
             $installWeb = $web;

It should be obvious what I've done here. I've changed the search order for a plugins topic:

(I've been considering moving thisweb.plugin higher in the list as well - before the Main plugin in fact, but that's a separate issue)

What this does is this reduces the problems caused by this:

• User installs their wiki
• Changes their plugin settings
• Comes to do an upgrade, and has their settings clobbered

Use case story:

• User downloads a distribution of TWiki
• Downloads 2 plugins
  • Both install preferences topics in the Plugins web
• The user chooses to customise one topic, by copying the preference topic into their %MAINWEB%, and edits it there
• They later download later versions of both plugins
• Since the preference topics are in Plugins, the user's changes do not get clobbered
• They later perform an upgrade and taking all the new topics in the %TWIKIWEB%
  • Suppose these two plugins are now included in the distribution
  • This means these two preference topics now exist in the %TWIKIWEB%
    • However since the Plugins web overrides the %TWIKIWEB%, the users system continues working as expected.
    • Likewise since the %MAINWEB% overrides the Plugins web the changed settings do not get clobbered (in exactly the same way %MAINWEB%.TWikiPreferences doesn't get clobbered during upgrades if you allow everything in the %TWIKIWEB% to be changed.

There's more use case stories, but this is the simplest that covers most bases. Notes:

• This is complementary IMO to Sven's recent work, rather than completely alternative.
• This requires plugins to be packaged as AndreaStearbini originally had them - with config topics going into the Plugins web
• This then allows the main distribution to package plugins in the %TWIKIWEB% without clobbering user settings
• This is directly akin to searching ~/.app/settings , /usr/local/etc/app/settings , /etc/app/settings for settings, and also more in line with the way TWikiPreferences WebPreferences fall back.
  • This is also why I'd also prefer to allow Plugin config pages in the webs to be listed first, but since I don't need that at this instant I've not implemented that above.

I wanted this for my systems. If you want it feel free to use. If you don't, just ignore it - I'm only doing so because I think it might be useful to others.

-- MS - 14 Jan 2004