the topics should have %EDITPREFERENCES% contained in %IF% so that if that plugin isn't installed, users won't see the unexpanded directive.

WN

addendum, 2009: (i had opened Item2672, but just found this old report)

in case the site has it disabled (i disable this particular plugin on all of my installations).

this is also prerequisite work if the plugin is deprecated and/or no longer shipped with the distribution (which i will push for in a RequestProposal)

-- WillNorris - 02 May 2009

i tried replacing

<form method="post" action="http://365847.689093.cn/bin/viewauth/Tasks/Item2672" enctype="multipart/form-data" name="editpreferences"><input name="prefsaction" type="hidden" value="edit" /><input type="submit" name="edit" value="Edit Preferences" class="foswikiRequiresChangePermission foswikiButton" /></form>

with

%IF{ "context PreferencesPluginEnabled" then="<form method="post" action="http://365847.689093.cn/bin/viewauth/Tasks/Item2672" enctype="multipart/form-data" name="editpreferences"><input name="prefsaction" type="hidden" value="edit" /><input type="submit" name="edit" value="Edit Preferences" class="foswikiRequiresChangePermission foswikiButton" /></form>" }%

but got

<form method=
<form method="post" action="http://localhost/foswiki/bin/viewauth/Main/SitePreferences" enctype="multipart/form-data" name="editpreferences" onsubmit="foswikiStrikeOne(this)"><input type='hidden' name='validation_key' value='?5fa5963f8bce1887be3562bb6d2ff54b' /><input value="edit" name="prefsaction" type="hidden" /><input type="submit" name="edit" value="Edit Preferences" class="foswikiButton" /></form> 

so, this approach isn't working because te emitted code has quotes in it. how can i do this?

-- WillNorris - 18 Mar 2010

Are users put off more by a stray %EDITPREFERENCES% in view, or the giant construct to hide it which is revealed in edit mode?

If in your situation it's the former, I suppose one option might be something like

%IF{
   "context PreferencesPluginEnabled" 
   else="<!--"
}% % EDITPREFERENCES% %IF{
   "context PreferencesPluginEnabled"
   else="-->"
}%

Argh! PreferencesPlugin uses beforeCommonTagsHandler, so the %EDITPREFERENCS% is expanded even though it's in a verbatim

-- PaulHarvey - 18 Mar 2010

This plugin is a PITA. I regularly disable it.

-- MichaelDaum - 18 Mar 2010

Set a default value for the macro in DefaultPreferences:

   * Set EDITPREFERENCES =

This expands the directive to an empty string only if the plugin is disabled.

This can work for other macros as well:

   * Set COMMENT =

Of course that makes debugging a lot harder...

-- ArthurClemens - 18 Mar 2010

that is handy, thanks arthur. but can we ship an empty value for EDITPREFERENCES in the release? seems a bit dodgy.

-- WillNorris - 18 Mar 2010

As long as the plugin is enabled, the user won't see a difference.

-- ArthurClemens - 18 Mar 2010

will anyone defend this plugin? should we stop shipping it?

-- WillNorris - 18 Mar 2010

In the current state it promises more than it delivers.

For very simple things it is useful. For instance for having Foswiki as CMS to provide a couple of elementary setting.

-- ArthurClemens - 18 Mar 2010

This plugin has been a default plugin for years and it was introduced when (tm)wiki removed the feature of having settings in the topic form.

Since then people have for sure used it for simple settings. It is probably more useful in many small apps where you want users to adjust 2-3 small settings then in DefaultPreferences.

We should not remove the plugin. It makes no harm. The only small annoyance is that you see its macro when you disable the plugin.

I do not see this as a huge issue. DefaultPreferences is an admin topic - not a generic user interface. Trying to hide it behind something very complicated makes no sense. That confuses more. The situation where preference topics should be easy to handle is when you edit them. Noone looks at preference topics without having an intend to change something.

I'd rather consider improving the plugin with time to make it more useful. But I would not do that in a 1.1 scope. I think this is a small cosmetic detail.

-- KennethLavrsen - 19 Mar 2010

removal of EDITPREFERENCES tag when this plugin is not enabled was completed as part of "cleanup WebPreferences" (Item8746); closing, but marking as "waiting for release" so that it appears in the release notes.

-- WillNorris - 22 Mar 2010