Feature Proposal: Foswiki should with no or very minimal configuration


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.



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



  • 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
    • 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


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
  • ...

Topic revision: r3 - 05 Jul 2015, GeorgeClark - This page was cached on 04 Jun 2020 - 11:15.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy