Preferences are defined in the following hierarchy:
- local site level in TWikiPreferences
- user level in individual user topics in Main web
- web level in WebPreferences of each web
- topic level in topics in webs
- plugin topics (see TWikiPlugins)
- session variables (if sessions are enabled)
Settings at higher-numbered levels override settings of the same variable at lower numbered levels, unless the variable was included in the setting of FINALPREFERENCES at a lower-numbered level, in which case it is locked at the value it has at that level.
However, this has the consequence that one cannot set web-specific values for the plugin variables, if a plugin variable was defined. However, most plugins do make settings, as examples, or to configure the plugin. Thus, these settings can only be modified globally.
I could not find a documentation on the relative precedence of plugin topic vs. other topics in older versions of TWiki. But for sure, I do remember that we locally modified plugin settings in webs.
I believe that the correct order is that plugin topic settings can be overridden by the local site already, i.e., that they should have the lowest precedence. Otherwise, installation will always be a night mare. We can debate what exactly the preference is, but certainly it needs to be below web level.
I mark this as a show stopper.
P.S. Looking at the code, the above doco seems incorrect also in that session plugins are pushed on the preference stack
before the plugins, thus receiving lower precedence. (I did not test this, as I have to confess I don't know what session preferences are.) --
TW
I agree on this one. It is a real pain that you
- Have to remove a preference definition from a plugin topic to use it in topics. This is really harming usability.
- Cannot put plugin preference settings in Main.TWikiPreferences so they override the setting in the Plugin topic and does not get reset each time you upgrade a plugin (quite common event).
- Example. Each time I upgrade BlacklistPlugin I have to set 2-3 settings again like white list and some other values.
- I ran into the problem just a few days ago with the new SignaturePlugin which is actually a brilliant plugin for other things than signing off provided that you can set the preferences that defines the signature inside the topic. I even reported an error because I could not imagine that you cannot override the setting inside the topic. I can also remember setting preference settings locally in Cairo.
There is no compatibility issue here that I can think of. Noone can have made a TWiki Application which takes advantage of the current behavour. This simply needs to be corrected so that Plugins goes to the top, so at least Main.TWikiPreferences, WebPreferences, user topic settings and local topic settings all can override the settings. Unless defined as FINALPREFERENCES in the plugin topic.
--
KJL
Here is my proposed order of precedence:
- local site level in TWikiPreferences
- plugin topics (see TWikiPlugins)
- local site level in Main web
- user level in individual user topics in Main web
- web level in WebPreferences of each web
- topic level in topics in webs
- plugin topics (see TWikiPlugins)
- session variables (if sessions are enabled)
From skimming the code it appears that there might be an issue that some preferences need to be defined before certain other activities are taken (e.g.,
TWikiPreferences must be read before renderer is initialized). It is not clear to me whether there is any dependencies of
TWiki::Plugins::enable
on any of the preferences, as this is the call that would have to be moved earlier... --
TW
Looked at this some more... here are some considerations on the current implementation...
- The plugins must be initialized after the renderer has been created, as they call
initPlugin
which may render text.
- The renderer requires that
NEWTOPICBGCOLOR
, NEWTOPICFONTCOLOR
, NEWTOPICLINKSYMBOL
, and LINKTOOLTIPINFO
have been set (thus at least the TWikiPreferences must have been invoked).
- Therefore, these variables cannot be changed after the plugin preferences are set (bet you did not know that these cannot be changed in plugins or session preferences).
- Further, if plugin preferences are given lower precedence, this further limits the ability to modify these four preferences in more local settings.
- And finally, if the plugins use certain settings to create static information in the
initPlugin
routine, these will not be affected by preference changes in more local settings.
All that said, it seems clear that
- Plugin settings must be overridable by the Main web settings and above
- There are dependencies between settings that are difficult to untangle
--
TW
Wrote the code changes to
- Separate plugin setting collection from initialization
- Separate settings from TWikiPreferences and Main web
- Push plugin settings right after TWikiPreferences
- Push settings from Main web after Plugin settings
Still need to modify the test cases.... would appreciate feedback before I get too excited about this...
--
TW
TWiki.TWikiPreferences -> Plugin prefs -> Main.TWikiPreferences -> etc makes absolute sense. This has been propsed in
TWiki:Codev/MainTWikiPreferencesOverridePluginSettings
--
PTh
Do you want me to check the code change into developbranch?
--
TW
No, absolutely not; it is a huge security hole, which is why the order is as it is. See
TWiki:Codev/MainTWikiPreferencesOverridePluginSettings
--
CC
Please see continued discussion on this topic at
TWiki:Codev.MainTWikiPreferencesOverridePluginSettings.
--
TW
I believe the concerns have been addressed, we should be ready to have it checked in.
--
PTh
Dunno what Thomas' solution was, so I wrote my own (a simple reordering in TWiki.pm)
CC
Rewrote headline for release notes
KJL
4.1.0 released
KJL