Feature Proposal: Foswiki should with no or very minimal configuration

Motivation

Configure has gotten way too heavy, and the code is so complex to be almost unmaintainable. It is also daunting for the new user / installation and uses too much bandwidth.

If at all possible, Foswiki should 'just work'. The new user expands the distribution into the server directory, and bin/view should be functional. Configure should be needed for tuning, optional features, and post-installation defaults.

Description and Documentation

There is a REST / JSON based ConfigurePlugin which allows topics to configure plugin. Configure should be completely restructured:

• Eliminate the large monolithic configuration tool
• Foswiki should be basically functional by default with no configuration.
• Configuration should be topic based, divided into focused, task-related topics and wizards.

Examples

Impact

Make it much simpler for the new user. Eliminate / simplify a large amount of highly complex code.

WhatDoesItAffect:

Implementation

• Ensure that foswiki is functional without a LocalSite.cfgon most typical installations
  • If needed, build a simple bootstrap script that can set sane defaults and warn about missing dependencies.
  • Any bin/bootstrap script should able to be deleted once foswiki is operational
• Make the new ConfigurePlugin a default plugin
• Create a System/Configuration web, containing:
  
  • Task oriented configuration pages. (one per current configure's tab or sub-tab)
  • More complex tasks like email configuration, authentication methods should use a "Wizard" page
  • Audit pages, Log viewer pages, etc.
• Implementation phasing:
  • Objective: Any new release of foswiki should be basically functional without a LocalSite.cfg
    • Consider a link on WebHome pointing to configure if LocalSite.cfg is missing
  • 1.2.0 continues to use existing configuration tool
  • Make ConfigurePlugin a default extension in a patch release once it is functional
  • Expand ConfigurationPlugin over time, and deprecate bin/configure once it provides complete coverage

-- Contributors: GeorgeClark - 15 Mar 2014

Discussion

Lots of stuff to figure out:

• Should configuration be in the System web, or separate possibly sensitive config information into a subweb or completely different web
• How do we handle extension settings. System/Configuration/SomeExtension with the settings? Or an admin-specific View Template for System/SomeExtension that adds access to the Config settings.
• How to deal with the special admin user/password.
• Shell based configuration when web access not possible / practical
• ...

Commenting is disabled while not logged in