Priority: Normal
Current State: No Action Required
Released In: n/a
Target Release: major
Applies To: Engine
Component: Configure
Branches:
<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.
- Using a text editor I modified SafeWikiPlugin/.../Config.spec to include:
# **BOOLEAN**
# Cheep
$Foswiki::cfg{Plugins}{SafeWikiPlugin}{SpamAlbatross} = 0;
- I then ran configure, and hit "next".
- 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:
- Most configuration items come from Foswiki.spec
- Foswiki.spec is always read by Foswiki; LocalSite.cfg only stores configuration items which differ from the defaults in Foswiki.spec
- 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