Feedback on PreferencesPlugin

This plugin requires the TWiki Cairo release! But don't be alarmed, it will be updated to Dakar.

As background, I did not like where the preference handling was going on Dakar by stuffing everything into the standard TWikiForms. I find the current way, where documentation is interspersed with preference settings, much better. But I do see the added convenience of having preferences defined in input fields (leveraging predefined values, etc.) So I wrote this plugin which allows the editing of each preference in a predefined input field (drop down menus, radios, etc.) yet intersperses this with the documentation. This, I believe, gives the best of both worlds. Please let me know if you agree, and how this can be improved.

P.S. An obvious improvement is to capture all the preferences in the defining form (this form was taken from the Dakar release).

P.P.S. Thanks to PeterThoeny, as some code has been cribbed from EditTablePlugin.

-- ThomasWeigert - 07 May 2005

Thomas - I agree, this seems like a very nice compromise! I just did a quick install and haven't tested it extensively yet but seems like a very nice improvement for handling preferences.

-- LynnwoodBrown - 07 May 2005

Lynwood, please be aware that in TWikiPreferences the preference setting for ATTACHEDIMAGEFORMAT needs to be changed to a single line to match the TWiki spec. Otherwise, this plugin cannot edit it, currently.

-- ThomasWeigert - 07 May 2005

Thomas, you are the Tausendsassa of TWiki Plugins! Can't wait to try it out! Thanks for contributing so many useful Plugins

Agreed, editing the settings in place is much nicer then settings in an attached form. We could promote this Plugin to one of the PreinstalledTWikiPlugins and retire UsingFormsForSettings.

I made some minor changes to the Plugins topic, e.g. change hard coded TWiki web name to %TWIKIWEB%.

-- PeterThoeny - 07 May 2005

Thanks. But really this is just an idea by PeterThoeny, then 1/3 EditTablePlugin, 1/3 FormDotPm, and 1/3 PrefsDotPm, and in addition I cheated and used a core function...

-- ThomasWeigert - 08 May 2005

We need to think about whether we need to handle multi-line settings. They are supported by the preference parser in PrefsDotPm, but not by this plugin or the merge mechanism in DakarRelease. The spec is somewhat ambiguous, but I read it as specifying setting definitions to be restricted as to one line.

-- ThomasWeigert - 08 May 2005

The provided form should be

• enhanced to include all preference settings defined in TWiki, and
• reviewed to choose the "best" editing input type for each preference.

-- ThomasWeigert - 09 May 2005

This is now also available for DakarRelease....

-- ThomasWeigert - 09 May 2005

I just noticed today on a site where I installed PreferencesPlugin that WikiWord links in FormattedSearches were no longer links.

I rolled TWikiPreference back to version before I turned on PreferencesPlugin and everything's back to normal.

Sorry I don't have more time right now to try figure out what's going on - just thought I'd post this report. If you have any suggestions for further testing, I'll be glad to give it a go later.

-- LynnwoodBrown - 12 May 2005

Just made a new installation of yesterday's version of develop branch and am getting this error message in Apache log file:
view: Possible unintended interpolation of @fld in string at /home/user/domain.com/lib/TWiki/Plugins/PreferencesPlugin.pm line 254.

Also, this warming is showing up repeatedly in data/warn200505.txt:
PreferencesPlugin defines deprecated endRenderingHandler

No visible problems with display but throught I'd pass on this info.

-- LynnwoodBrown - 13 May 2005

Regarding the endRenderingHandler, this affects a number of other plugins, such as EditTablePlugin. I think the postRenderingHandler can be used instead.

-- ThomasWeigert - 13 May 2005

I checked into Lynnwood's problem... this is actually due to a bug in Cairo which has been fixed in Dakar (that's why this does not show up in Dakar).

What is happening is that in Cairo setting noautolink=off does not actually turn it off, but it turns it on (somehow unintuitively). In fact, setting this preference to anything but blank turns it on. In Dakar, setting the preference to off actually turns it off. The TWikiPreferencesForm defined the two possible options for this preference where on and off which basically meant that whatever you did you turned autolinking off, which is what you observed.

I have implemented a work around in the Cairo version of this plugin. I have provided a third option (blank) to all binary flags. However, I think the real solution is to fix the preference handling in PrefsDotPm.

I also fixed some of the warning messages... Please download the new version.

-- ThomasWeigert - 13 May 2005

While most preferences are in the "Preference" topics, is there any reason this can't be used, for example, in the user's home topics in the Main web to edit the personal preferences in a structured manner?

-- AntonAylward - 09 Jun 2005

Anton, this should work to edit your personal preferences also. You would just have to put the tag on your home page and also add the appropriate definitions to the form so that the right editing capability is invoked.

-- ThomasWeigert - 29 Jun 2005

checked .zip into CVS

-- WillNorris - 19 Jul 2005

I recently filed Item1297 on PreferencesPlugin substituting variables. I am told that this apparently is pr. spec.

But this ruins the meaning of some variables, i.e. MAILTHISTOPIC in TWikiPreferences becomes hardcoded to mailing only the TWikiPreferences topic and multihomed installations are affected by default domain being hardcoded into variables after edit/save cycle. Is it possible that it would be a nicer spec if output were somewhat more similar to input?

-- SteffenPoulsen - 04 Jan 2006

I have suggested a patch in the bug report.

-- SteffenPoulsen - 07 Jan 2006

Would it be possible to let PreferencesPlugin work with AttachContentPlugin?

Would it be possible to pass a css state to the editable version of the page? That would give more control over the display of settings and form fields.

-- ArthurClemens - 27 Sep 2006

Arthur, can you please explain in more detail what you need?

-- ThomasWeigert - 04 Dec 2006

The plugin does not allow i18n for buttons Edit, Save... and Cancel. That is necessary for some uses.

-- CarlinhosCecconi - 27 Mar 2007

Anyone have a problem with the latest version? When I use it, it seems to work normally, except no changes are saved. Not sure where to start digging on this one.

-- EricHanson - 22 Aug 2007

See new proposal PointAndClickAccessControl related to this plugin.

-- PeterThoeny - 2011-06-10

I'm using the 2011-02 version at the moment. I want to use a select+multi option, but it doesn't seem to work. The form pops up ok, but when it saves it only saves the first item you selected. My goal: use this in some Group topics to make it easier for non-technical people to add/remove people from a group. I'll try getting the latest copy and see if that works.

-- AaronLWalker - 2012-02-17

Breaks with the current version as well. I also tried setting it up as a checkbox, and that breaks in a different fashion (attempting checkbox):

 Can't use string ("UserID01, UserID02, UserID03") as an ARRAY ref while "strict refs" in use at /twiki/current/lib/TWiki/Plugins/PreferencesPlugin.pm line 251.

Definitions attempted:

| GROUP | select+multi | 20 | %SEARCH{"%META:FORM.*[U]serForm" nosearch="on" web="Main" type="regex" separator="," format=" $topic" excludetopic="Web*" nototal="on"}% | List of users for this group | S |
| GROUP | checkbox | 4 | %SEARCH{"%META:FORM.*[U]serForm" nosearch="on" web="Main" type="regex" separator="," format=" $topic" excludetopic="Web*" nototal="on"}% | List of users for this group | S |

-- AaronLWalker - 2012-02-20

This looks like a bug. Could you file a report at TWikibug:WebHome?

-- PeterThoeny - 2012-02-23

I have the same problem with select+multi and several entries. Has this problem been solved?

-- Rostislav Chudoba - 2015-02-27