r1 - 14 Jan 2004 - 17:15:42 - MichaelSparksYou are here: TWiki >  Codev Web > AllowLocalPluginSettingsToOverrideDistribution
Tags:
, create new tag

PROPOSAL: Better handling of plugin settings in upgraded environments

People upgrading their systems should be able to have their settings transparently not clobbered - either by new full distributions deciding to include a plugin, or by new versions of plugins.

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:

From thisTo this
  • fully specified web.plugin
  • TWiki.plugin
  • Plugins.plugin
  • thisweb.plugin
  • 1 fully specified web.plugin - deprecated
  • 2 Main.plugin
  • 3 Plugins.plugin
  • 4 TWiki.plugin
  • 5 thisweb.plugin

(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

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r1 | More topic actions
 
Powered by TWiki
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback SourceForge.net Logo