Item780: we should not ship Main SitePreferences and other topics that must be customised - we should do it like we do with WikiUsers

we should leverage template topics more to totally avoid distributing topics that need to be modified for configuration.

it isn't that hard to write some code that will give the admin more info when they goto a non-existant SitePref topic

-- SvenDowideit - 16 Jan 2009

Damn right. I feel strongly enough about this that I'm pushing the priority up to Normal i.e. I regard it as a bug for any file in the released set to have to be overwritten in the installation.

-- CrawfordCurrie - 08 Mar 2009

I had been thinking about changing the upgrade package from being incremental to being a full package MINUS a list of topics / files people do not want overwritten.

We are dammed close now. With Foswiki 1.0 the pattern skin no longer ships with top, bottom and side bars that are overwritten. It now has some default topics that are used unless the admin has created his own. This is brilliant.

I think Main.SitePreferences, WebPreferences for the Main, System, and Sandbox webs, and the registration page are the few topics left that people will find annoying or very harmful to have overwritten.

Getting these last obstacles resolved will almost eliminate the need for upgrade packages.

Downloading the 4 MB vs 1 MB is not the issue when upgrading. It is a matter of a few extra seconds for most. And the upgrade packages must be applied one by one. You cannot jump versions. With a full release package you may have some old redundant files after an upgrade but all will work.

It is the overwriting of important topics that bombs your installation to pieces that is the issue.

So I would love to see this fixed for 1.1. We will need different solutions for the different topics I am sure.

I will begin a list here

• Main.SitePreferences - obvious why
• Main.UserRegistration - often tailored when you have added or removed fields from the user form
• Main.WebPreferences - In my example I add a DENY setting for WikiGuest to force authentication for all reading.
• System.WebPreferences - In my example I add a DENY setting for WikiGuest to force authentication for all reading.
• System.InterWikis - People have their own additional settings added here. Today we hide pretty well that you can define your own topic as a setting in Main.SitePreferences.
• Main.WebHome - the default landing page is often altered to something useful for the organisation using Foswiki. We overwrite it today.

-- KennethLavrsen - 08 Mar 2009

Pattern skin's left bar and top bar topics still need some work - though its easy to do - basically a couple more If's - In most cases, what I'd like to see is a set of template topics that the admin can use to create the customised ones - I've made such a thing in YuiMenuContrib and others.

-- SvenDowideit - 09 Mar 2009

For 1.0.4 RC1 I used this manual process.

In root directory do not include

• index.html

In webs Main, Sandbox and Trash only include topics that actually changed. But Never include

• Main/SitePreferences.txt
• WebHome and WebPreferences in any of the Main, Sandbox and Trash webs

In System web include all topics except

• System/ChangePassword.txt
• System/InterWikis.txt
• System/NewUserTemplate.txt
• System/ResetPassword.txt
• System/WebPreferences.txt
• System/UserRegistration.txt

In _default web include all topics except

• _default/WebHome
• _default/WebPreferences
• _default/WebLeftBar

In (tm)wiki web all topics except

• WebPreferences

In other directories include everything

-- KennethLavrsen - 18 Mar 2009

How about if the "Checker" for the dataDir path in bin/configure also verified that a list of required topics were present, and could copy them from a skeleton if missing. Either copy from an Example topic, or include a copy in the Configure/Resources path to copy.

• SitePreferencesExample -> SitePreferences
• WebPreferencesExample -> WebPreferences
• WebPreferencesExample -> WebPreferences
• Sandbox.webPreferencesExample -> WebPreferences

I know it's feature creep but this would be pretty trivial to implement in a 1.1 checker, and would only impact sites with these topics missing.

Actually having the checker verify WebPreferences regardless of the copy step might make sense and would find trash directories that were created in some cases by previous bugs.

-- GeorgeClark - 28 Aug 2010

So for a possible solution, we could add a new directory, Foswiki/Configure/Resources/Tailored - containing the topics that would normally be tailored by a local installation. That directory would contain copies of the normally tailored files, and remove them from their normal locations.

• Main_SitePreferences.txt
• Main_WebHome
• Main_WebPreferences
• Sandbox_WebHome
• Sandbox_WebPreferences
• Trash_WebHome
• Trash_WebPreferences
• Trash_TrashAttachments
• System_ChangePassword.txt
• System_InterWikis.txt
• System_NewUserTemplate.txt
• System_ResetPassword.txt
• System_WebPreferences.txt
• System_UserRegistration.txt
• _default_WebHome
• _default_WebPreferences
• _default_WebLeftBar
• TWiki_WebPreferences

bin/configure checks each of these for existence in the configured target webname, and copies them in if they are missing. Maybe with some adjustments we could reuse the code already written & tested in the extension installer that can copy & rename files per their configured web names.

If we ever ship a default "empty the trash" script, it could also use the Trash_TrashAttachment to restore that topic to it's original state.

-- GeorgeClark - 29 Aug 2010

Since the original bug item the Change and reset password as well as change email address have been changed so tailoring should not be needed

UserRegistration has also been changed so it does not get overwritten

Interwikis should be fixed in a different way so you can include a topic with user settings. The plugin page for any plugin should be overwritten when upgrading so you have the right version and change history and documentation. For this plugin we need a solution for user defined interwikies similar to how we handle user templates in comment plugin.

This needs more careful thinking and planning. Do not squeeze this into 1.1 or we end up with solutions we will regret because we did not think carefully.

There are many open questions to think about. I would like some time to discuss and get the best ideas. We all want the same end result.

-- KennethLavrsen 29 Aug 2010

Now that 1.2 has the Bootstrap process, we could probably use bootstrap code to copy over missing topics during initial installation. Probably too risky for 1.2 though.

-- GeorgeClark - 30 Dec 2014

Commenting is disabled while not logged in