Item13560: configure does not set initial values when extensions are installed with an external package manager.

External package management might happen using the operating system's yum or apt-get, or via git or plain unzip.

The old configure propagated defaults from an extension's Config.spec to LSC. Not so the new one in ConfigurePlugin. This especially applies to extensions installed via unzip or git, i.e. not using configure's own download mechanism.

Also, the core then reports missing {Module} entries for plugins installed that way. Running configure again or issuing a tools/configure -save does not cure the problem.

-- MichaelDaum - 27 Jul 2015

See also Item13574

-- MichaelDaum - 29 Jul 2015

Note that the new configure DOES propagate the settings, it just happens at a different place / time. The code in the Install extensions wizard applies all the new configuration, creates the Module entry, and when run from CLI does an automatic save, and when run from the web, leaves the changes in the DOM for the user to chose to save or not.

The code in Configure/Package.pm

• The Config.spec additions are applied by the call to _SpecChecker->new( $reporter,... at line 1001
• The Plugin {Module} and {Enabled} settings are applied at lines 457-497
• The Spec is merged by package _SpecChecker beginning at line 516

I suggest the fix is to add a function to the extensions installer to trigger just the merge of the specs. So after unzip or pseudo-install, you would still run a configure wizard, but with a merge spec option. Auto-enabling the plugins is a bit more complex, because that's driven off of the manifest file that is embedded in the [Extension]_installler file.

Longer term, it would be nice to give Configure/Package.pm the ability to:

• Install from an unzipped archive. (That part exists, but needs to be externalized)
• Install from a traditional MANIFEST file (Currently it requires that the [Extension]_installer file exist to recover the embedded MANIFEST
• Symlink instead of Copy, so that it could also replace much of the pseudo_install function

So we would still support "unzip", but not directly into the installation. There are some big advantages of that: It supports renamed webs and topics, and unusual directory locations.

-- GeorgeClark - 29 Jul 2015

What I need to be able to do as a normal admin (not pseudo-install) is to unpack a zipped plugin, throw it on my working installation. Look at configure - and save. And then I expect the plugin settings to be in my config. I don't want to run installers that I do not know what are doing. I have burned myself on those where I had to spend hour cleaning up the mess it did to my package management system.

-- KennethLavrsen - 29 Jul 2015

I wonder if an old bug I reported Item13316 is not related. I bet it has nothing to do with the specific plugin but with the fact that I probably installed it by applying a zip.

-- KennethLavrsen - 30 Jul 2015

Checking in a possible fix. This adds a new wizard. It works from the CLI just fine, but for some reason I can't get it to actually update the configuration from the Web UI.

tools/configure -wizard Plugins
tools/configure -wizard Plugins -method repair -save

This will identify any conflicts between Foswiki & TWiki plugins and the {Plugins}{..}{Module} definitions. with the -method repair, it adds missing definitions. And the act of saving the configuration also merges the .spec files.

Not added to MANIFEST until the web UI interface is resolved. Patch for enabling the WebUI:

diff --git a/core/lib/Foswiki.spec b/core/lib/Foswiki.spec
index 1f410cf..f554aba 100644
--- a/core/lib/Foswiki.spec
+++ b/core/lib/Foswiki.spec
@@ -2415,7 +2415,7 @@ $Foswiki::cfg{ExtensionsRepositories} =
 # *FINDEXTENSIONS* Marker used by bin/configure script - do not remove!
 
 #---+++ Configure how plugins are loaded by Foswiki
-# **STRING 80 LABEL="Plugins Order"**
+# **STRING 80 LABEL="Plugins Order" FEEDBACK="label='Validate plugin modules';wizard='Plugins'; method='repair'"**
 # Plugins evaluation order. If set to a comma-separated list of plugin names,
 # will change the execution order of plugins so the listed subset of plugins
 # are executed first. The default execution order is alphabetical on plugin
diff --git a/core/lib/Foswiki/Configure/Checkers/PluginsOrder.pm b/core/lib/Foswiki/Configure/Checkers/PluginsOrder.pm
index ab24d53..6fecb99 100755
--- a/core/lib/Foswiki/Configure/Checkers/PluginsOrder.pm
+++ b/core/lib/Foswiki/Configure/Checkers/PluginsOrder.pm
@@ -49,6 +49,8 @@ sub check_current_value {
 'TWikiCompatibilityPlugin is enabled.  It  must be first in the list for proper operation'
         );
     }
+
+    $reporter->WARN("Inconsistencies in plugin modules detected. Repair recommended.") if ($Foswiki::pluginModuleInconsistencies);
 }
 
 1;

-- GeorgeClark - 07 Aug 2015

This has me stymied. It appears that under some conditions, configure.js fails to detect the new values of configure items set by a wizard. It's not just the new Plugins wizard, as I'm able to observe this on some Extensions installations as well. It seems to be something going wrong around line 408 of configure.uncompressed.js

        // Reflect changed values back to the input elements and
        // run the checker on them
        $.each(results.changes, function(keys, value) {
            // Get the input for the keys, if it's there
            var spotted = false, pendid, $pending, handler;

            console.log( "REFLECT: " + keys + " value " + value);  // This shows the expected new value,  so it works up to here.

            $('#' + _id_ify(keys))
                .closest('.node')
                .each(function() {
                    var $node = $(this),
                        handler = $node.data('value_handler');

                    handler.useVal(value);   //  This either sets the wrong element, or the wrong value to the right element.
                    spotted = true;
                    // Fire off checker
                    check_current_value($node, true);  
                        // This call,   calls   update_modified_default($node);
                            // Which calls handler.isModified
                               // Which always compares  "null" to "null"  and claims the setting is not modified.  
                               // So the configuration is not updated.
                               //  And I have no idea why...
                });

The wizard is working, configure has an issue. And I need some javascript help.

-- GeorgeClark - 10 Aug 2015

Trace from Wizard:

• Removed {FindElsewherePlugin}{Module} and {Enabled} from LSC
• Ran Plugins Merge wizard

{"jsonrpc":"2.0","method":"wizard","params":{"wizard":"Plugins","method":"merge","keys":"{ExtensionsRepositories
}","set":{},"cfgusername":"testuser","cfgpassword":"xxxxxxx"},"id":"iCall-merge_14"}

Response:

{
   "result" : {
      "requireSave" : 1,
      "messages" : [
         {
            "text" : "Module Foswiki::Plugins::FindElsewherePlugin is not referenced in the configuration"
,
            "level" : "notes"
         },
         {
            "text" : "Configuration changes required.",
            "level" : "warnings"
         }
      ],
      "changes" : {
         "{Plugins}{FindElsewherePlugin}{Module}" : "Foswiki::Plugins::FindElsewherePlugin",
         "{Plugins}{FindElsewherePlugin}{Enabled}" : null
      }
   },
   "id" : "iCall-merge_14",
   "jsonrpc" : "2.0"
}

{"jsonrpc":"2.0","method":"check_current_value","params":{"keys":["{Plugins}{FindElsewherePlugin}{Module
}"],"set":{},"check_dependencies":true},"id":"iCheck---Plugins--FindElsewherePlugin--Module-_15"}

and response

{
   "id" : "iCheck---Plugins--FindElsewherePlugin--Module-_15",
   "jsonrpc" : "2.0",
   "result" : [
      {
         "reports" : [],
         "keys" : "{Plugins}{FindElsewherePlugin}{Module}",
         "path" : [
            "Extensions",
            "Extension operation and maintenance",
            "Enable or disable installed extensions"
         ]
      }
   ]
}

-- GeorgeClark - 19 Aug 2015

There seems to be confusion as to where the issues are.

• Three possible paths to install an extension
  • web based InstallExtension wizard
  • CLI based invocation of wizard ( either SomeExtension_installer or vi tools/configure)
  • File system install (unzip/tar, Debian/RPM pkg, or pseudo-install)

• In all cases the *.spec files must be merged into the configuration. That happens in the Save wizard, so you always must trigger a save after installing any extension.
• In the special case of a Plugin, then the non-Spec setting {Module} and {Enabled} must also be applied.

-- GeorgeClark - 19 Aug 2015

Thanks George. I don't know when you added these comments, but I think I made the process simpler, mostly by moving things around, fixing a couple of small bugs, and adding the 'reset_may_repair' flag. Your merge wizard is a fine solution to the external install problem, though would benefit from a clearer explanation of the results (perhaps add a "Now save the changes" to the end of the report? And possibly suppress the checkers, which are really just noise in this context?)

-- Main.CrawfordCurrie - 20 Aug 2015 - 05:47

Commenting is disabled while not logged in