Feature Proposal: Clean up WebPreferences

Motivation

_default.WebPreferences is a total mess, full of cruft

Description and Documentation

1. deprecate WEBTOPICLIST ... once upon a time there was a skin that used it, called DefaultSkin
2. deprecate NOSEARCHALL ... irritating for users, hard to manage, i.e. if mentioned in FINALPREFERENCES
3. deprecate SITEMAPWHAT and SITEMAPTO ... and replace it with WEBSUMMARY
4. remove FINALPREFERENCES from _default.WebPreferences ... users regularly do more harm than make use of it
5. put the %INCLUDE{WebPreferenecsHelp into a twisty to hide it by default
6. create proper headlines and group preferences, adding a %TOC at the top
7. clearly separate documentation from variables ... this gets in the way most of the time

Examples

Impact

%EDITTABLE{format="|label,1|text,70|" changerows="off"}%

WhatDoesItAffect:

%WHATDOESITAFFECT%

Implementation

-- Contributors: MichaelDaum - 25 Nov 2009

Discussion

I support this.

-- ArthurClemens - 25 Nov 2009

me too those sites are such a PITA...

-- CarloSchulz - 25 Nov 2009

My site uses NOSEARCHALL to disable searching for a handful of webs that have thousands of topics which we seldom want to search. If we want to search them, we go to those webs and search there. This way, we speed up the majority of searches. I don't mind if we deprecate NOSEARCHALL, provided that we still provide a way to exclude specific web(s) from "all webs" searches. I do not see any proposal to retain this functionality so I have raised a concern.

-- MichaelTempest - 25 Nov 2009

I agree with the concern about deprecating NOSEARCHALL. I'm aware of sites that need this as well. However as currently implemented, it is very confusing. Also the Web Creator UI was setting it backwards - setting it to ON to make the web visible. This is fixed in Tasks.Item2411

Also SvenDowideit suggested in http://irclogs.foswiki.org/bin/irclogger_log/foswiki?date=2009-11-24,Tue&sel=655#l651 that the ManagingWebs topic be expanded to be a UI for the WebPreferences settings, and requested that I raise this as an enhancement for the UI in trunk.

-- GeorgeClark - 25 Nov 2009

wow, George has taken my suggestion a little further than i meant, and its consequense is similar to an idea i just had.

What if we change WebPreferences to be entirely META:PREFERENCES based, and then editing it gives a viewtemplate that has a cfg UI like the new trunk configure one. similarly, this 'view' can be used on the ManagingWebs topic..

we gain alot by making on/off/true/false's a checkbox UI etc - much like the UI I started on in my System Administration demo

-- SvenDowideit - 26 Nov 2009

Sounds good, but that's another topic which should be followed up in another feature request. Michael's proposal here is to garden WebPreferences. Assuming this proposal stands on it's own without that extended proposal, my comments:

1. deprecate WEBTOPICLIST ...
   • I see WEBTOPICLIST all over the place; what replaces it?
2. deprecate NOSEARCHALL ...
   • Reflecting the comments above, this is widely used; what replaces it?
3. deprecate SITEMAPWHAT and SITEMAPTO ...
   • Agreed.
4. remove FINALPREFERENCES from _default.WebPreferences ...
   • Agreed.
5. put the %INCLUDE{WebPreferenecsHelp into a twisty to hide it by default
   • Agreed.
6. create proper headlines and group preferences, adding a %TOC at the top
   • Agreed, though moving stuff into META:PREFERENCE might make this moot.
7. clearly separate documentation from variables ...
   • Agreed. Aside: How does documentation get linked in the META:PREFERENCE proposal?

-- CrawfordCurrie - 26 Nov 2009

+1 from my side too.

Crawford: You mention WEBTOPICLIST is all over the place. Where? I haven't used it at all.

-- GuruprasadIyer - 26 Nov 2009

Okay, I see that NOSEARCHALL is needed for standard %SEARCH for performance reasons. Removed the proposal to deprecate it.

I tried to find out where WEBTOPICLIST is actually used. It seems PatternSkin overrides webactions (that's where it is in the tmpls) with something else in all cases. Not sure. Which other skins do use WEBTOPICLIST? Are there any users that reconfigure WEBTOPICLIST on a web-by-web base?

For now I'd prefer to address low-hanging fruits here: reorganize and cleanup.

-- MichaelDaum - 26 Nov 2009

NOSEARCHALL is no longer affected by this proposal, so I withdraw my concern.

-- MichaelTempest - 26 Nov 2009

ok, low hanging fruits are fine, as they will reduce the docco and confusion, shame to have such a low expection tho

presumably the default skin still uses WEBTOPICLIST and similarly legacy things.

-- SvenDowideit - 03 Dec 2009

What we are talking about is this :

Let's change all calls to %WEBTOPICLIST% in the templates to

%IF{"defined 'WEBTOPICLIST'" 
  then="$percntWEBTOPICLIST$percnt" 
  else="$percntTMPL:P{\"defaultwebtopiclist\"}$percnt"
}%

with a

%TMPL:DEF{"defaultwebtopiclist"}%[[WebChanges][Changes]] %SEP% [[WebIndex][Index]] %SEP% [[WebSearch][Search]] %SEP% Go <input type='text' name='topic' size='16' />%TMPL:END%

in foswiki.tmpl

That way we don't deprecate the WEBTOPICLIST but unclutter WebPreferences and DefaultPreferences.

-- MichaelDaum - 03 Dec 2009

George, do you still have concerns wrt this proposal? See the NOSEARCHALL discussion above.

-- MichaelDaum - 09 Dec 2009

George, anybody home?

-- MichaelDaum - 16 Dec 2009

George are you still there? Could you please check if your concerns still hold since the proposal has been changed? This one is really a low hanging fruit that directly results in happier users.

-- MichaelDaum - 12 Jan 2010

Oops... sorry for the delay. No problem at all with the proposal as long as we still have NOSEARCHALL or equivalent functionality. I removed my name from the ConcernRaisedBy field.

-- GeorgeClark

I cannot see what we get out of hiding the help text behind a twisty.

The WebPreferences is a topic which is mainly confusing while editing it. No when viewing it.

But if you want to .... I just cannot see who it helps. Normal users do not care. They do not look at WebPreferences.

-- KennethLavrsen - 12 Jan 2010

Ya. I will try to find the right ballance between not confusing people trying to cope editing WebPreferences and providing hints where to get help on the specific settings.

I will give this some more time for people to comment before marking this proposal "consensus reached" and starting work on trunk.

-- MichaelDaum - 13 Jan 2010

I am thinking about the removal of FINALPREFERENCES

If we remove it - like in deleting - people will have a hard time knowing it exists. It's presense has an important as a documentation. People will have a hard time finding that this is an option. It may be documented in a topic in System web but the likelyhood that people find it is minimal.

Maybe it is better to keep it and just remove the parts that causes trouble. Like access control where making these final means they do not work in subwebs. I think this is what Michael was thinking about. And it is true that in most cases people will want the possibility to set these in sub webs and get caught by having these settings made final in the parent. As long as WebPreferences is not open to editing making the ALLOWWEB and DENYWEB settings final does not really add any significant security.

But removing FINALPREFERENCES means many people will not know this feature exists and it is of good use in many cases.

-- KennethLavrsen - 19 Jan 2010

Okay. I will try to find a balance of

1. things being documented elsewhere
2. useful example settings
3. good defaults that don't harm more than they help and last but not least
4. manageability

-- MichaelDaum - 19 Jan 2010

Tasks.Item8746

-- MichaelDaum - 22 Mar 2010

The "managing webs" links are now too hidden. You would not expect action links to be in a help twisty.

-- ArthurClemens - 28 Mar 2010

True. However, they never were at the right place down there anyway, as they belong into some "Admin" menu.

-- MichaelDaum - 29 Mar 2010

"Admin functions" would be a good header.

-- ArthurClemens - 29 Mar 2010

One of the FAQ's that comes up time and time again - is "My web doesn't show up in the Weblist". I had added a note to the WebPreferences topic back in r5620 and Tasks.Item2411 to try to clarify this. This cleanup removes very useful information from the settings. And NOSEARCHALL is confusing because setting it to "off" has the same results as setting it to "on" or "blah". If it is "set" - to anything, the search is avoided, AND the WEBLIST in the leftbar which uses search will be empty. It's also not clear that the SITEMAPLIST is NOT the list in the WEBLEFTBAR.

"clean" is not helpful if the user has to go searching through other docs for simple answers to very non-obvious confusing settings. So they ask again on IRC and we answer again. and again.

-- GeorgeClark - 29 Mar 2010

NOSEARCHALL plus FINALPREFERENCES where a PITA for users all the time. People easily activated NOSEARCHALL not knowing what it is and then got lost in hunting down why their web does not show up as exepcted. Even for first level support, it is much too hard to track down what is going on, given other parameters that come into play regularly (for one ldap being misconfigured).

These two options are real expert settings and should not used by default. Hiding a web is best done using access control rights.

-- MichaelDaum - 29 Mar 2010