create new tag
, view all tags

Proposal: Main.TWikiPreferences should override the Plugin Settings

For easy upgrade it is desirable to leave the TWiki web untouched. The Plugins are typically configured with settings in the Plugin topic. When upgrading TWiki or a Plugin, those settings need to be restored. A Plugin setting named XYZ of FooBarPlugin is stored as a FOOBARPLUGIN_XYZ setting, and is accessible as %FOOBARPLUGIN_XYZ%. Plugin settings currently cannot be overridden by the Main.TWikiPreferences site preferences settings.

For easy maintenance it is desirable that the Plugin settings can be overridden by the site preferences settings. That is, the proposed new evaluation order is:


(11:16:03 PM) MartinCleaver: Should PLUGINNAME_FOO on Main.TWikiPreferences override the setting FOO on topic TWiki.PluginName?
(11:16:32 PM) QBFreak: you have the naming correct, but iirc it does not
(11:16:52 PM) QBFreak: I tested this a few months ago, I forgot to record the results
(11:17:26 PM) MartinCleaver: Can I tell all the settings belonging to PLUGINNAME, i.e. iterate the keys under PLUGINNAME_* ?
(11:17:47 PM) ***QBFreak is lost
(11:18:06 PM) QBFreak: are you refering to writing one?
(11:18:15 PM) MartinCleaver: ok, so I want something to tell me all keys matching PLUGINNAME_*
(11:18:24 PM) QBFreak: I came at it from a twiki admin persepctive, not as a plugin author
MartinCleaver: well, as an admin I want to know what settings are in effect 
MartinCleaver: I can't find the spec of this
MartinCleaver: i.e. what says the preferences evaluation order
QBFreak: I think one exists somewhere, but also keep in mind some plugins check PLUGIN_FOO on their own in a different order\
MartinCleaver: this one uses getPluginPreferencesValue
QBFreak: best I can suggest is looking at the source or making a test plugin and trying it out
MartinCleaver: To me it looks like the plugin page overrides the on on Main.TWikiPreferences
MartinCleaver: but that's crap if you're trying to not change the stuff in the TWiki web
QBFreak: I know
QBFreak: that fits with what I think I found :)
QBFreak: and I agree with what you're saying

-- Contributors: MartinCleaver, PeterThoeny


Is there good reason why Main.TWikiPreferences shouldn't take priority over the plugin pages?

-- MartinCleaver - 09 Jul 2006

Would making settings FINAL in Main.TWikiPreferences allow settings to be centralised there?

-- MartinCleaver - 09 Jul 2006

I see no reason why site level settings should not be able to override Plugin settings.

It should be possible to block further overload of Plugin settings with FINALPREFERENCES (as usual.)

-- PeterThoeny - 10 Jul 2006

It is even worse... not even web preferences or user preferences can override plugin settings now...

-- ThomasWeigert - 13 Aug 2006

This is tracked in Bugs:Item2757, code by TW

-- PeterThoeny - 13 Aug 2006

The discussion from Bugs:Item2757 inserted here:

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.

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...

... 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

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 --PT

-- ThomasWeigert - 12 Aug 2006

What confuses users is that some plugins allows local topic settings of variables. Example (disabled - I need propeor format later in this topic)

  • #Set TABLEATTRIBUTES = tableborder="1" cellpadding="0" cellspacing="1" headerbg="#E000E8" databg="#E0F0F0,#FFFFFF"

Test More
dffs fdsfs
dsf dsfasd

I have been very confused about this many times and have thought that it was buggy plugins.

So I am supporting the spec change. It is OK if Plugin settings are between TWiki.TWikiPreferences and Main.TWikiPreferences. That will work fine. I do not think any existing TWiki Apps will break because of this change because the old behavour could not really be used in apps. The proposed change will be an enabler of more flexible use of several plugins.

-- KennethLavrsen - 14 Aug 2006

The reason plugin settings can't be overridden is security. Any preference that can be overridden can be overridden at the topic level. Say I have a plugin, with a setting that defines a program to be run:

  • Set LS_COMMAND = ls -l
(this is a common case in many plugins). All a hacker needs to do is:
  • Set LS_COMMAND = hack -hack -destroy -munge
in their topic. So, obviously you can't allow override at the topic level. Because web settings are often editable, you can't allow it there either. So somehow you have to only allow override of plugins settings in TWikiPreferences. But this is a complete reversion of the normal order, where TWikiPreferences are overridden by web and topic level. So now a plugin setting has to be "special" - if defined in TWikiPreferences and in a plugin topic, it cannot be overridden at web or topic level. Argh. More horrendous complexity in the midst of already horrendously complex code. And somehow you have to explain it in the docs, as well, remembering the support problems we already have because security settings - which look like preferences - have a different evaluation order to TWikiVariables.

You can change the evaluation order to drop the precedence of plugins below webs and topics. However if you do this, you must at a minimum work with plugins authors to move dangerous settings out of plugins topics, and into LocalSite.cfg. This is why I made the order the way it is - there are many, many plugins out there, and very little cooperation from plugins authors.

As a general observation, I prefer settings in LocalSite.cfg to the plugin topic. My reasons:

  1. "Normal" users can't edit plugin topics, so it is pointless allowing changes there. By all means show the configuration settings, but there is no need to Set them.
  2. There have been several security issues that have arisen from settings in plugin topics, similar to that illustrated above. Why risk it?
  3. Parsing plugin topics at runtime is (I am fairly sure) a performance hog. Let's avoid it if we can.
    • A plugin can easily "say" if the plugin topic can be skipped
  4. Plugins variables are already horrible:
    • Set WURBLE = bleem in a TWiki.GetYourPlugIn topic sets GETYOURPLUGIN_WURBLE - yet another thing that FUDs the unwary.
  5. If settings are in LocalSite.cfg, there is no need to worry about upgrading plugin topics. They are just documentation.

In anticipation, I have already added a lot of support to BuildContrib installers to support settings in LocalSite.cfg. The configure changes I am proposing for 4.1 go even further. Even without the installer script, it is easy to manually edit LocalSite.cfg. Remember, in 99% of sites, only admins can edit plugins topics!

Let's just accept that defining defaults in plugin topics was a good idea at the time, but TWiki has moved beyond that model.

Now, let's consider "settings" - those plugins "variables" that should be overridden by individual webs or topics - and there are many. My view is that "defaults" for these values should be provided by the plugin, and optional overrides managed by the code. For example,

   my $ls_command = $TWiki::cfg{Plugins}{GetMyPlugIn}{LsCommand} || 'ls -l'; # Dangerous command, don't allow override
   my $grumph = TWiki::Func::getPreferencesValue("GRUMPH") || 'default_grumph'; # Support site, web, and topic override
And in the plugin documentation topic:
  • The default GRUMPH value is 'default_grumph'. You can override this default at the site, web or topic level by simply setting the %GRUMPH% TWikiVariable (the current setting of %GRUMPH% in this topic is %GRUMPH%)

Taken together, this avoids the FUD created by the GRUMPH -> GETMYPLUGIN_GRUMPH mapping, it avoids the need to parse the plugin topic for settings, it is totally consistent with the way all other TWikiVariables work, it requires no code changes in the core (in fact it requires less code), and it is more easily understandable by plugins authors.

-- CrawfordCurrie - 14 Aug 2006

Crawford, I understand your reasoning, but the current situation is a defect and a HUGE change compared to what it was in the past. Basically, many plugins now do not work, as they rely on the overriding of the settings in web or topics by giving some illustrative default in the plugin setting.

I have been running now with TWiki.pm modified with the modified order and it works much better (on my internal site). I am all for changing to how you describe above, but

  • we need to do something now, and
  • you need to give a recipe for the plugin authors as to what to do.
I am willing to experiment with my plugins, but I need some guidance.

Otherwise, we need to undo the current situation, security or not...

-- ThomasWeigert - 14 Aug 2006

Some more thoughts...

A plugin can always create a mess, if it wants, so we would think that it should take care of dangerous situations anyway. If a situation such as the one Crawford describe arises, one needs to make such settings FINALIZED.

However the much more common situation is that the settings are innocent and useful to be modified outside of the plugin setting.

-- ThomasWeigert - 14 Aug 2006

Security is important. I shall be the first to ackowledge this.

It seems plugins have at least two types of settings (there are two type of people in the world: those who divide the world in two types of people, and those who don't)

  • Settings that are truely global and which setup things like a path to an executable (ugly - dangerous)
  • Settings that influence how the plugin behaves.

Having settings in the LocalLib.cfg - as things work today - means that the admin will have to hack ASCII files to change settings. That is a step in the wrong direction. The most often spoken complaint about TWiki is how difficult it is to setup. And if you have to hack the funny syntax in LocalSite.cfg then we take a step in the wrong direction. But if the settings could be set in configure - then I would agree with the idea. And I do not see any reason why that could not be made to fly. That is worth its own topic.

However! I would not want the softer settings in Plugins be so difficult to reach. And I want to be able to set many of them in normal topics so it applies locally.

And I also see Crawford's ideas as an opportunity to speed up things.

Maybe we need to see this as short term 4.1 and longer term so we get all the best proposals on the table.

Let is short term say that we follow Thomas's proposal - which plugins have settings that are considered insecure?

How does TablePlugin manage to get its settings to work everywhere? And without the terrible PLUGINNAME_PARAMETER syntax (I am totally with you there Crawford).

-- KennethLavrsen - 14 Aug 2006

To the TablePlugin question: There is some cheating.... the plugin uses two settings TABLEPLUGIN_SORT and TABLEPLUGIN_TABLEATTRIBUTES. These are subject to the constraints discussed above. However, is also uses the setting TABLEATTRIBUTES which is not set in the plugin topic. Therefore, if you use the latter, you have the flexibility desired. If you use the former, you are stuck with the current horrible scenario....

-- ThomasWeigert - 14 Aug 2006

Crawford, with all due respect, I question your assertion that the security leak you describe is "common" in many plugins. The plugins I am using do not have the ability to set programs to be run that way.

The problem I see in plugins with security is that they create files and take filenames from tainted variables. Now rather than protect, some authors remove the -T flag from the command line.

Do you have examples of plugins that would create the problems you outline?

-- ThomasWeigert - 14 Aug 2006

I started walking through all the plugin that have been verified to wort on TWiki4. I am not done yet. I can continue tonight. So far I have found no system compromizing issues. I have found a few where the settings should be FINAL to not compromize the settings in the plugin. The trend so far supports Thomas' view but let us see if I run into some nasty ones later.

Plugin Dangerous Variables
AccessStatsPlugin None
ActionTrackerPlugin None
AliasPlugin None
AntiWikiSpamPlugin None - but variables must be FINAL in either TWikiPreferences or plugin topic
AttachContentPlugin None
BeautifierPlugin None
BibtexPlugin None
BlackListPlugin None - but variables must be FINAL in either TWikiPreferences or plugin topic
BlogPlugin None
BreadCrumbsPlugin None
CacheContentPlugin None
CalendarPlugin None
CaptchaPlugin None - CHARACTERS should probably be final for some applications
ChartPlugin None
ChecklistPlugin None
ChildTopicsTag None
CommentPlugin None
CommonHeaderFooterPlugin None
ControlsPlugin None
DBCachePlugin WEBDB could be abused but it is not even set final or defined today so spec change makes no difference. Should be final in either TWikiPreferences or plugin topic
DBIQueryPlugin None
DateFieldPlugin None
DblClickEditPlugin None
DirectedGraphPlugin LIBRARY would need a check if this could be abused to access protected attachments. If made FINAL problem is resolved.
DirectedGraphWebMapPlugin None
EasyTimelinePlugin None
EditSyntaxPlugin None
EditTablePlugin None
EditTablerowPlugin None
EmailObfuscationPlugin ESCAPELIST should be final to protect the function of the plugin but system cannot be compromized
ExternalLinkPlugin None
FilterPlugin None
FindElsewherePlugin None
FlexWebListPlugin None
ForEachPlugin None
FormFieldListPlugin None
FormQueryPlugin None
FundraisingPlugin None
GaugePlugin None
GenerateSearchPlugin None
GlobalReplacePlugin None
GluePlugin None
GnuPlotPlugin None
GoogleAjaxSearchPlugin None. GOOGLEKEY maybe should be final.
HeadlinesPlugin None. USELWPUSERAGENT is not dangerous as such but should be final
HistoryPlugin None
HolidaylistPlugin None
HtmlMetaPlugin None
IfDefinedPlugin None
ImageGalleryPlugin None
ImagePlugin None
ImgPlugin None
ImmediateNotifyPlugin Server settings should be final
InterwikiPlugin None
JSPopupPlugin None
LatexModePlugin None
LdapNgPlugin None
LdapPlugin LDAP server settings should be final
LinkOptionsPlugin None
LoadTagsPlugin None
LocalCityTimePlugin None
LocalTimePlugin None
MathModePlugin None
MetasearchTag None
MostPopularPlugin None
MultiEditPlugin None
NatSkinPlugin None
NewsPlugin None
PloticusPlugin None
ProjectPlannerPlugin None
PublishWebPlugin None - Maybe protected webs can be published? If so variables must be made final
RandomQuotePlugin None
RecentChangesPlugin None
RedDotPlugin None
RedirectPlugin None
RenderListPlugin None
RevCommentPlugin None
RevisionLinkPlugin None
SectionalEditPlugin None
SignaturePlugin None
SlideShowPlugin None
SlidyPlugin None
SmartEditPlugin None
SmiliesPlugin None
SoapClientPlugin None
SpreadSheetPlugin None
StopWikiWordLinkPlugin None
TWikiDrawPlugin None
TablePlugin None
TagCloudPlugin None
TagMePlugin None
TextSectionPlugin None
TimeSincePlugin None
TimeTablePlugin None
TimelinePlugin None
TitleTag None
TocPlugin None
ToolTipPlugin None
TopicCreatePlugin None
TopicCryptPlugin None
TopicReferencePlugin None
TreeBrowserPlugin None
TreePlugin None
TwistyPlugin None
UpdateInfoPlugin None
UserInfoPlugin None
VarCachePlugin None
VotePlugin None
WebPermissionsPlugin None
WorkflowPlugin None
WysiwygPlugin None
XmlQueryPlugin Deadly. This plugin has a totally insecure setting allowing to specify anywhere on the disk in which xml files are saved.
XpTrackerPlugin None

That is the 136 plugins that currently are reported to work on TWiki 4.

Most are completely safe.

Few have settings that should many will want to keep protected as FINAL. Adding a commented out list of FINALPREFERENCES.

ONE plugin had an awfully bad preference that surely should be moved to LocalSite.cfg.

I did not go through the old plugins that noone has updated yet to limit my search. This may reveal another one or two.

But based on the table above I recommend.

  • That we change the order of precedence as proposed between Main and TWiki TWikiPreferences
  • That we change the XmlQueryPlugin unsafe setting to a config file setting.
  • That we add FINALPREFERENCES to 3-5 of the other plugins - commented out with #-signs so you can set the values in Main.TWikiPreferences and not have these settings deactivated next time you upgrade for example the BlackListPlugin. The 3-5 would be plugins where it is truely important that the settings are FINAL. The commented out FINALPREFERENCES will not protect the settings until the comment # is removed but it is a good way to show the admin at installation time that the preferences may need protection.

I think this is a small price to pay for being able to take advantage of settings all the perfectly safe plugin settings in User Home Pages, in WebPreferences and in individual topics.

-- KennethLavrsen - 15 Aug 2006

Thanks Kenneth for researching the settings of the Plugins. I think we need to distinguish between dangerous settings such as path to executables, problematic settings, and harmless settings.

The dangerous settings should never be put into a preferences settings, they belong in LocalSite.cfg or in another file in the file system (I have been giving feedback accordingly in a number of dev topics in the past.)

The problematic settings need to be in the FINALPREFERENCES as Kenneth points out. We also should alert the Plugin author in the Dev topic to update the Plugin documentation accordingly.

-- PeterThoeny - 16 Aug 2006

Ken, great investigative work. It is always good to base decisions on data...

-- ThomasWeigert - 16 Aug 2006

Yes, good work, thanks Kenneth. My observations about security were based on past history; the command problem was first encountered some time ago, and most occurrences have already been fixed.

Peter is right:

  • dangerous settings need to be in LocalSite.cfg. The new configure supports editing these settings, and BuildContrib installers already handle setting them.
    • We should actively encourage the use of LocalSite.cfg to prevent unilateral proliferation of plugins own configuration strategies (I already fell victim to this with the action tracker plugin)
  • static settings (what Peter calls problematic) are settings that are usually set once for a site and never again (hence their finalisation). I strongly favour moving these into LocalSite.cfg as a point of policy, because it allows plugins to be run without reading the plugin topic.
  • dynamic ( harmless ) settings, i.e. settings that need to be overridden at web and topic level, should be moved to TWiki variables where possible, again so that plugins can be coded to avoid parsing the plugin topic.
And these approaches should be clearly documented in the plugin documents. I remember the confusion I initially had before I finally realised how plugin variables were supposed to work. of course, existing plugins (those not recoded to use standard TWiki variables) should continue to work as normal.

BTW, this is tha approach I recommend by which a plugin can prevent a parse of the plugin topic:

package RubberPlugin;
use vars qw( $NO_PLUGIN_TOPIC );
i.e. if the plugin declares a global variable $RubberPlugin::NO_PLUGIN_TOPIC that will prevent the plugin topic from being parsed for settings. The default is of course to parse the topic.

-- CrawfordCurrie - 16 Aug 2006

Crawford, could you please describe the approach of using the new configure and BuildContrib installers to set the plugin config variables. I would like to experiment on this with my plugins, but have no idea of how to get started.

Actually, all these need clear instructions. I am also not sure on the impact and how to move plugin settings to Twiki variables. Is this as simple as omitting the plugin prefix from the setting? This has a huge impact on the namespace, I think.

-- ThomasWeigert - 16 Aug 2006

Other than your last point on moving plugin variables to twiki variables (which needs more discussion) we should move to the scheme described by you as quickly as possible. Are you now ok with changing the order of precedence of the plugin topic back to how it was before TWiki4 (which was an incompatible change that broke a large number of plugins)?

-- ThomasWeigert - 16 Aug 2006

FWIW, I think the $NO_PLUGIN_TOPIC name is confusing since there is always a plugin topic. Something like $NO_PLUGIN_PREFERENCES or $NO_PREFERENCES_IN_PLUGIN_TOPIC is more descriptive.

Hmm, actually, the SHORTDESCRIPTION needs to be defined, or the plugin will not be listed properly in the TextFormattingRules. If there are no settings in the plugin topic this needs to go into LocalSite.cfg. But then we would require an install script, which I would like to avoid (no longer possible to unzip & play.)

-- PeterThoeny - 16 Aug 2006

Unzip and play is not a reality for most. Usually one has to (i) chmod the scripts in bin and (ii) put the permissions into .htaccess or similar.

-- ThomasWeigert - 16 Aug 2006

I have often run into problems with the installer scripts. They often fail. I will also insist that plugins can still be installed manually. Why make something simple complicated?

But also - why is a one liner description of a plugin a variable in the plugin topic? Why can't it simply be hardcoded in the Plugin code?

When you write a plugin and make a one line description, why should this be something the user can alter?

And if we need the one-liner in LocalSite.cfg then ... in TWiki4 you have to activate the plugin in configure. That process can put the one liner into LocalLib.cfg if this is needed. If we can speed up the loading of Plugins by avoiding having to load the one liner and the debug flag - which for many plugins are the only topic defined variables - then this is an obvious step in the right direction to improve TWiki speedwise.

-- KennethLavrsen - 16 Aug 2006

Argh, that's pretty horrible, but I can see where you are coming from.

-- CrawfordCurrie - 20 Aug 2006

I agree with Ken on the SHORTDESCRIPTION (I assume that is what he means by the oneliner). There is no need for the user to alter this.

I am fine with there being no settings in the plugin topic, if that causes a problem, but these settings all go into the system preference files. Of course, plugin writers have to take care that when they read preferences in the plugin, these are checked for accurracy and a proper default is chosen if unset. (But they should be doing this anyway.)

Here is another idea then: If we don't have settings in plugin topics, why don't we create a tag which just pulls the currently active setting and shows it, and then we replace in the plugin topics the setting with that tag to show what actually is the current setting. That may help the user understand what is going on. Right now, when you look into the plugin topic (which is the documentation for the plugin), the settings do not always match what the user actually experiences. A new user, who does not understand the preference hierarchy, might be confused...

We probably would have to do this for most of the plugins, as plugin writers tend to be touchy when things change... as we saw in some recent postings...

-- ThomasWeigert - 20 Aug 2006

Changing configure as Kenneth suggests to automatically deprecate the plugin topic is a lot of work, and risky. I favour moving preferences out of the plugin topic, but only under plugin author control. While this puts the onus on plugin authors to upgrade to the new approach, I think it is safer than changing the rules under existing plugins. The reason is that plugin topics document their preferences one way, and if we change the rules so that those preferences no longer work as documented, we just cause confusion. It would be better to provide the support for preference both in plugin topics (deprecated) and in LocalSite.cfg. Thomas, your tag to pull in preference settings is a good idea. However I am wary of the security implications. For example,

$TWiki::cfg{Plugins}{DatabasePlugin}{ADMINPASSWORD} = 'oh dear';
and in a topic:
which rather defeats the object of the exercise.

Note that SHORTDESCRIPTION is only used in the code (by PLUGINDESCRIPTIONS); it is not used in any searches so can safely be dropped from plugin topics.

-- CrawfordCurrie - 21 Aug 2006

Regarding your concern of revealing hidden information via the tag, this is not really a problem in my opinion, as

  • if such setting is required today, it is visible in the plugin topic today
  • we could write the PREFERENCE tag in a way that it would refuse to show preferences with certain strings in their name, e.g., password, or show only ****** or something similar

but finally, I did not mean this PREFERENCE tag to bring up the settings in config, but in the preferences. The assumption is that user definable settings are somewhere in the preferences, and we would want to show them in the plugin topic. I don't think we need to show the config variables in the plugin topic.

I am still not clear whether there is today the capability of editing the LocalSite.cfg file via a custom configure script. If so, can you please explain how to or point me to the doco. The existing configure script is rather foreboding...

Also, can one read today's configure variables via the standard plugin API, or does one need to look for the confg variable specifically?

-- ThomasWeigert - 22 Aug 2006

Some definitions for the purposes of this discussion:

  • standard preferences are normal TWiki preferences defined in TWikiPreferences, WebPreferences or the topic, but not including plugin preferences
  • plugin preferences are any preferences defined in plugin topics, that end up being prefixed with PLUGINNAME_
  • configuration of a plugin is customisation that should be editable only by admins.
  • personalization of a plugin is the process of customising the plugin for a user, a web, or a specific topic, using preferences
My view is that we need to ditch plugin preferences completely, as far as possible. configuration should moved to LocalSite.cfg. personalization should be moved to standard preferences. plugin preferences need to be retained for historical reasons, but should only be loaded if absolutely necessary.

In this scenario, the PREFERENCE tag (as I understand it) is not needed, because

  1. configuration should be kept secret anyway
  2. standard preferences used for personalization are already accessible through %VARIABLE%
  3. plugin preferences are also accessible though %PLUGINNAME_VARIABLE% though this usage should be deprecated.
If you enter a type definition in LocalSite.cfg, then configure picks that up and presents it in the configure interface. For example, say LocalSite.cfg contains:
# **STRING 30**
# HexPlugin spell configuration
$TWiki::cfg{Plugins}{HexPlugin}{Spell} = 'eye of frog and toe of newt';
then it will appear in the interface.

-- CrawfordCurrie - 22 Aug 2006

Crawford, while I agree with your suggestion in principle, it might be not workable given the current situation. I think we are stuck with the plugin preferences, but

  • we must restore the previous situation where these could be overridden (where they really were personalizations, and
    • Note that the current problem affects even your own plugins: In DateFieldPlugin, the doco says "The default date format is %d %b %Y (day of month, month name, year). You can change the date format by setting the TWiki variable 'DATEFORMAT' in your TWikiPreferences, your WebPreferences or in a topic." It then gives an example, which, of course, results in the user not being able to do what the doco says.
  • we must get the security sensitive configurations out of the plugin.

Even if we succeed in getting the plugin preferences to disappear, it might still be useful to show the personalizations within the plugin topic, but you are right, %PLUGINNAME_VARIABLE% should do.

Regarding the configurations. I hacked up the configure script to do the following:

  • For each plugin X, look in lib/TWiki/Plugin/X/LocalSite.cfg for plugin settings.
  • Show these in the configure screen below the plugins, taking care to show the settings that exist in LocalSite.cfg for the plugin settings, if any.
  • Save them into LocalSite.cfg.

This will allow a nice way for the plugin writers to define the configurations in the plugin without requiring the user to monkey with LocalSite.cfg as part of the install. They have to use the configure script anyway to activate the plugin, and at this point they can modify the configuration settings also.

The attached patch to configure is against the 4.0.2 release.

If you approve, we are done now with the precedence issue and I shall check these changes into develop...

-- ThomasWeigert - 23 Aug 2006

we must restore the previous situation... I already did that (rev 11354). I also:

  • rewrote EmptyPlugin to discourage use of PLUGIN_ preferences in future plugins
  • added $NO_PREFS_IN_TOPIC for plugins that want to use it
  • recoded a couple of plugins (CommentPlugin, DateFieldPlugin) to the new approach. They are both still compatible with earlier releases, but DateFieldPlugin ignores the plugin topic if it can.

we must get the security sensitive... I think this has been done everywhere. Certainly Steffen has been aware of the need.

Thomas, configure has been totally rewritten for 4.1; I can't do anything with a patch against 4.0.2. But navigating the plugins settings to under the enable flag is something I wanted to do, but never got there. Any chance you could take a look at the configure in Subversion?

-- CrawfordCurrie - 24 Aug 2006

Bummer. OK, I will look at the new configure...

-- ThomasWeigert - 24 Aug 2006

This has been added.

-- ThomasWeigert - 26 Sep 2006

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch_precedence configure.patch_precedence r1 manage 4.3 K 2006-08-23 - 03:40 ThomasWeigert Patch to configure to support editing of plugin settings
Edit | Attach | Watch | Print version | History: r32 < r31 < r30 < r29 < r28 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r32 - 2006-10-01 - ThomasWeigert
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.