Item780: we should not ship Main SitePreferences and other topics that must be customised - we should do it like we do with WikiUsers
Current State: Confirmed
Released In: n/a
Target Release: major
Applies To: Engine
Component: Configure, Documentation
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
- 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.
- 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.
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.WebHome - the default landing page is often altered to something useful for the organisation using Foswiki. We overwrite it today.
- 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
- 09 Mar 2009
For 1.0.4 RC1 I used this manual process.
In root directory do not include
In webs Main, Sandbox and Trash only include topics that actually changed. But Never include
In System web include all topics except
In _default web include all topics except
In (tm)wiki web all topics except
In other directories include everything
- 18 Mar 2009
How about if the "Checker" for the dataDir path in
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
path to copy.
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.
- 28 Aug 2010
So for a possible solution, we could add a new directory,
- 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.
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.
- 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
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.
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.
- 30 Dec 2014