Item2103: configure is overly agressive in not saving unchanged values

<SvenDowideit> if we're right, its an issue in the release branch as well as trunk
<SvenDowideit> oh well, maybe i'll have time tomorrow
<DunsScotus> I tried to fathom it, but got distracted
<SvenDowideit> its pretty easy - add a new cfg to a previously installed contrib's Config.spec
<SvenDowideit> and then goto configure and see that it tells you nothing to save
<SvenDowideit> any plugin that assumes that cfg values will be correctly saved (ie, has no defaulting in the code) will fall over
<SvenDowideit> JQueryPlugin and its addition of the UI plugin showed it nicely

so if there's a new cfg param in a previously installed Plugins Config.spec, configure will tell you 'nothing to save'

-- SvenDowideit - 19 Sep 2009

I have a Release01x00 with SafeWikiPlugin pseudo-installed and enabled.

1. Using a text editor I modified SafeWikiPlugin/.../Config.spec to include:

       # **BOOLEAN**
       # Cheep
       $Foswiki::cfg{Plugins}{SafeWikiPlugin}{SpamAlbatross} = 0;
       

2. I then ran configure, and hit "next".
3. After saving, I checked LocalSite.cfg, and found:

      $Foswiki::cfg{Plugins}{SafeWikiPlugin}{SpamAlbatross} = 0;
      

so that works. I then deleted that line and repeated step 2; again, it was added to LocalSite.cfg. In both cases configure reported "0 configuration items changed" which is correct, because the user (me) did not change any configuration items interactively.

trunk refuses to save at step 2, because there have been no (interactive) changes. If I make a (spurious, irrelevant) change, however, save is enabled and once again, SpamAlbatross appears in LocalSite.cfg.

I haven't tried this with a manually installed extension, but there is no difference as far as configure is concerned.

I appreciate that most people will think that configure should report when a new configuration item is added this way, but it doesn't work like that. Here's why:

1. Most configuration items come from Foswiki.spec
2. Foswiki.spec is always read by Foswiki; LocalSite.cfg only stores configuration items which differ from the defaults in Foswiki.spec
3. If a new configuration item is added to Foswiki.spec, there is no need to add it to LocalSite.cfg, unless the value changes from the default.

Since we invented Config.spec I appreciate there is a new scenario; Config.spec is not read for defaults, so the default value has to be written to LocalSite.cfg, and it is this that you are perceiving as a "changed value". In fact, as far as configure is concerned, it is still a default and has therefore not changed; it's just being written to a different place.

I don't believe this is Urgent, so I've downgraded it to "Normal". I'd be interested to hear people's take on this.

-- CrawfordCurrie - 19 Sep 2009

This bites us again and again in JQueryPlugin, where users are unable to take advantage of a new JQ plugin until they manually edit LocalSite.cfg to enable something in the $Foswiki::cfg{JQueryPlugin}{Foo} space.

Crawford, I don't believe your test would have worked if you had tested $Foswiki:cfg{SafeWikiPlugin}{SpamAlbatross} = 1;= because I have seen this failing to work in JQueryPlugin.

Also, we need a way to invalidate deprecated plugins: users may skip upgrades and have stale .pm files enabled which are trying to call deprecated methods, crashing their wiki.

Increased to urgent for 1.1.

-- PaulHarvey - 28 Mar 2010

I believe I've seen something similar with getting a {Switchboard} entry saved for GenPDFAddOn. It's a hidden spec, and is not detected as modified. Unless something else is changed, it gets missed.

-- GeorgeClark - 29 Mar 2010

The Valuer class in configure maintains two sets of values; the default values, and the current values. The default values are populated by reading Foswiki.spec and Config.spec. The current values are populated from LocalSite.cfg.

If you have an extension that requires config settings but does not have a Config.spec (and there are a few) then there will be keys in the current hash that do not exist in the defaults hash. This condition will also pertain if you remove an extension. If the Config.spec of an extension changes, then the "old" keys will still be in LocalSite.cfg.

So the only way to resolve this situation is to require that every extension have a Config.spec and require that the keys in LocalSite.cfg be audited against the "allowed" keys in Foswiki.spec/Config.spec. Then the current values hash can be trimmed to the allowed keys (and any missing keys added).

There is still no way of recognising the case where a value in LocalSite.cfg was a valid default value in a previous version of a Config.spec, before an extension is upgraded. The only way to deal with that is to clear down the configuration of an extension whenever it is upgraded (unlikely to be a popular move) or in some way mark values in LocalSite.cfg as default values.

Another approach might be to remove the defaults from the Config.spec's from LocalSite.cfg and explicitly do the Config.spec's from the extension installations before local settings. So LocalSite.cfg would end up looking like this:

do 'Foswiki/Plugins/JQueryPlugin/Config.spec';
do 'Foswiki/Plugins/TinyMCEPlugin/Config.spec';
$Foswiki::cfg{JQueryPlugin}{Debug} = 1;
etc.

This would avoid the defaults from Config.spec being repeated in LocalSite.cfg.

-- CrawfordCurrie - 30 Mar 2010

I'm sure I was seeing this:

• Upgrade JQueryPlugin that comes with new module /lib/Foswiki/Plugins/JQueryPlugin/FOO.pm
• Observe that /lib/Foswiki/Plugins/JQueryPlugin/Config.spec contains a sensible default: $Foswiki::cfg{JQueryPlugin}{Foo}{Enabled} = 1
• Observe that this is reflected in Configure: it appears in the plugins list as "enabled"
• However, plugin behaves as if it's disabled
• Setting $Foswiki::cfg{JQueryPlugin}{Foo}{Enabled} = 1 manually LocalSite.cfg cures the problem.

It sounds crazy, I know. In a few weeks I will have a chance to check this is actually the case, or FastCGI was playing silly buggers with me.

-- PaulHarvey - 30 Mar 2010

I'm making this report wait for your feedback, because if it's just the case I described, then it should not be a release blocker.

It occurs to me that configure could write an explicit file containing do 's for all enabled plugins that have Config.spec's. That way only the non-default settings need live in LocalSite.cfg (though it does make configuration more complex and potnetially error-prone).

-- CrawfordCurrie - 06 Apr 2010

I suppose this shouldn't be a release blocker for 1.1.0. Intend to lower to normal after I do some testing this weekend.

-- PaulHarvey - 22 May 2010

I fixed Item1347, which copies Config.spec of enabled plugins when pseudo-install'ing -A (autoconfig).

This will at least make the unit tests pass, but won't solve much here

-- OlivierRaginel - 11 Sep 2010

This issue is still unresolved, and a major PITA.

-- ArthurClemens - 04 Jan 2011

I've removed myself from WaingFor in hopes that somebody has the time to look into this (I don't atm).

-- PaulHarvey - 07 Jan 2011

Reassigning to 2.0 It has been hanging as urgent for a year and was elevated to urgent by a core developer. If it can hang for a year it cannot be urgent.

-- KennethLavrsen - 06 Mar 2011

This is dead since configure was re-engineered for 1.2

-- CrawfordCurrie - 13 Dec 2014