Item1885: Refactor configuration options for ease of use

Some of the configuration options have been added without due care being given to their usability. This task seeks to address this problem. It will cover:

1. Improvement and correction of documentation
2. Reorganisation of configuration options for the new configure structure
3. Cleaning up Config.spec in extensions to use the new configure UI

I'm hoping the Kenneth will deliver on his promised review of configure, so I'm putting him in the WaitingFor field. Anyone else is very welcome to pitch in and help, of course.

-- CrawfordCurrie - 05 Aug 2009

I did actually give feedback before Arthur went on vacation.

I raised 3 or 4 bug reports and he addressed them all to my great satisfaction.

I will give it another round as I have not tested it the last 2 weeks.

-- KennethLavrsen - 05 Aug 2009

I was hoping for more than testing. I have made unilateral decisions on:

1. Which options to pull into configure, and which to leave in preferences
2. Which options to make expert
3. How to explain those options
4. How to group and present those options

all of which are subject to review and change. There are also a number of configuration options in default preferences that need work. For example, the HTTP-EQUIV settings are appallingly badly explained.

-- CrawfordCurrie - 06 Aug 2009

The description of the General Path Settings could be improved. The number of required fields has grown, so that the text "once you have set up the eight paths below" (which I think used to say six paths) is no longer accurate, and I think the number should be removed. I suggest "once you have set up the required paths below".

I would prefer to have the "show info texts" twisty at the top.

I suggest that {AuthScripts} should be an expert setting.

I suggest that {Store}{SearchAlgorithm} and {Store}{QueryAlgorithm} should not be expert settings. If alternative algorithms are available, then this is probably because the admin has installed an Extension that provides one.

I suggest that {ReplaceIfEditedAgainWithin} should not be an expert setting, because the default value is not appropriate for a common intended use of Foswiki i.e. in the context of a formal development process. Perhaps this setting should be split into two: a time setting, which could remain an expert setting, and a boolean "allow edit to replace revision" setting, corresponding to {ReplaceIfEditedAgainWithin} == 0, which should not be an expert setting.

• After reading your comment on {ReplaceIfEditedAgainWithin}, Kenneth, I withdraw this comment. (I am familiar with the behaviour you describe.) -- MichaelTempest - 09 Aug 2009

I suggest that the TWikiCompatibilityPlugin options be expert options. Most of the time, they should not need adjustment.

Just my 2c.

-- MichaelTempest - 08 Aug 2009

{ReplaceIfEditedAgainWithin}

I have to completely disagree on the {ReplaceIfEditedAgainWithin} opinion.

• I do not think it should be an expert setting. It is very likely that different organisations will want different time for this this feature. The default of 1 hour is a good default though as it matches the time of a typical meeting so a topic with meeting minutes does not end up with many versions just because the author was wise enough to save a couple of times and not loose all his work when/if the browser crashes.
• I think you are not at all in sync with how most of us use Foswiki and this feature. Your statement "not appropriate for a common intended use of Foswiki" is wrong. It is a brilliant and I would even say necessary feature for a business wiki. It would be horrible if
  • You end up with 5-10 versions each time you edit a topic with just a little more content than a few lines. You need to be able to save multiple times during an edit session without creating stupid revisions.
  • You need to be able to correct spelling mistakes or plain wrong text which you do not see while editing in TML but see the minute you see the topic in view mode. We all know this situation where you save - see something wrong - edit again and fix it - and save. You do not want all these silly revisions saved.
  • You need to be able to save sometimes 20 or 50 times while developing an application with a complex SEARCH or CALC etc without leaving behind 50 useless revisions of the topic.
• There is no ISO 9000 requirement or process requirement in any sain company that says that each time you save an MS Word document or a MS Excel spreadsheet on the harddisk you must give it a new name. You have to save each revision of a document. But you do not need to create new revisions each time you save the file on the harddisk while you edit it. See the {ReplaceIfEditedAgainWithin} as the wiki way to save document while you are working.
• We should not add another setting to disabled the feature. Setting the value to 0 disables it. That is fine.

Remember that this feature does not replace without creating a new revision IF the topic is edited and saved by anyone else than the last author. The minute someone else saves the topic a new version is created.

And the minute {ReplaceIfEditedAgainWithin} expires a new version is saved even if the author is the same.

And finally - if the user wants a new revision - maybe because he wants to be able to go back to a previous version while trying something new - he can force a new revision as often he wants in the user interface.

{ReplaceIfEditedAgainWithin} is a necessary and good feature and you should never ever turn this off in a normal wiki. NEVER. You can reduce the setting to 10 or 15 minutes if you are very picky. But never disable it. You will create a lot of noise in the organisation and make topic histories almost useless and you create a lot of discomfort among the users when they cannot silently fix spelling errors.

Also think about how you work in SVN. You do not create a new SVN rev each time you save a file. You can save and test your fixes. And when you are happy you svn commit. That is how a "formal development process" works. The {ReplaceIfEditedAgainWithin} is a good way to implement something similar on a webbased application.

I want this feature left as it is, and not as an expert setting. It is a wonderful well working feature. I wonder if you were aware of the fact that a new revision is stored if the author is someone else even within the {ReplaceIfEditedAgainWithin} time?

TWikiCompatibilityPlugin

No we should not hide if plugins are enabled or disabled. TWikiCompatibilityPlugin is a plugin and not just a core feature. If you start from fresh and not upgrading from TWiki you want this turned off.

If you upgrade from TWiki you want it on. This is not an expert feature.

{AuthScripts}

Agree this should be expert.

-- KennethLavrsen - 09 Aug 2009

I am in the process of reviewing expert vs non-expert.

• {Htpasswd}{Encoding} has been set to expert. I disagree. When you install on Windows you MUST set this one to sha1 or nothing will work. I do not even know how I would run anything else than sha1 on Windows. I will un-expert that setting.

• {Plugins}{TWikiCompatibilityPlugin}{Enabled} should not be hidden as I said above. But its setting could be hidden.
• {SwitchBoard}{compare} could also be hidden. This is true for all this type of plugins. This setting is more a hack IMHO than a setting any user should need to see and I am quite frankly not happy that the FSA feature meant that we had to see this type of stuff in configure. It is not elegant seen from the end user. It should not even need to be an expert setting. It should be totally hidden. There is nothing for anyone to ever change.

I am happy with everything else you have done Crawford. Good work. It is only the {Htpasswd}{Encoding} that I will re-enable which I willæ do myself now.

-- KennethLavrsen - 09 Aug 2009

Sven is going to do some of this as well.

-- CrawfordCurrie - 10 Sep 2009

I'm finished, I reckon. Sven, please close this when you are done.

-- CrawfordCurrie - 17 Nov 2009

I've forgotten what i was going to do, so closing

-- SvenDowideit - 30 Apr 2010