• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Preferences are defined in the following hierarchy:

  1. local site level in TWikiPreferences
  2. user level in individual user topics in Main web
  3. web level in WebPreferences of each web
  4. topic level in topics in webs
  5. plugin topics (see TWikiPlugins)
  6. 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:

  1. local site level in TWikiPreferences
  2. plugin topics (see TWikiPlugins)
  3. local site level in Main web
  4. user level in individual user topics in Main web
  5. web level in WebPreferences of each web
  6. topic level in topics in webs
  7. plugin topics (see TWikiPlugins)
  8. 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

ItemTemplate
Summary Precedence of preferences does not allow site, webs or topics to redefine plugin preferences
ReportedBy TWiki:Main.ThomasWeigert
Codebase 4.0.2, 4.0.4, ~twiki4
SVN Range TWiki-4.1-beta1, Mon, 24 Jul 2006, build 11161
AppliesTo Engine
Component

Priority Urgent
CurrentState Closed
WaitingFor

Checkins 11354 11391
TargetRelease minor
Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2007-01-16 - KennethLavrsen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback