archive_me1Add my vote for this tag extract_stuff1Add my vote for this tag create new tag
, view all tags

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 | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2008-09-02 - TWikiJanitor
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.