Configure Requirements For Deployment

This topic is to try to capture the environments where configure needs to be functional, and the specific quirks and restrictions that each environment applies as constraints on configure. Over the years Foswiki has been installed in many unusual hosting an deployment scenarios. We need to document them so that we don't undo hard fought "features" because the need for them didn't continue to be passed along.

Note: Some of these might not work today without effort. This is trying to capture what exists and what we should be attempting to support

Server platforms


Please attach "unusual" Apache configurations for testing.
  • Apache with default http.conf configuration shipped with Foswiki
  • Apache using .htaccess files
  • Apache with ApacheConfigGenerator configuration
  • Apache - tarball installed into cgi-bin directory (outside of server root)
  • Apache - installed into ~/user/Dir type configurations
  • ...



Microsoft IIS

Plack - PSGI

command line access

  • lots of admins want it, but its never been implemented

Installation method

  • Download tarball from
  • deb / rpm / usbstick / Mac package (if these could be auto-built - maybe they are already?)

Client Platforms

Degraded browser

Needed in some cases where limited bandwidth or access restrictions require plain text / non-javascript, non-css supported access.
  • Degrade to basic login with web form instead of javascript login.
  • Basic ability to set and save config variables without javascript
  • Only require validations performed on refresh of the page. Ajax, on-demand and extended checks not required.
  • Ability to request the extended checks via a URL-param is desirable.

Screen Size

Configure should be usable in a restricted size screen found on netbooks, and tablets. Test with dimensions of TBD

Browsers that need to be tested

Browsers that should be tested for some basic compatibility for feature changes. If possible, these should be added to the TestCases list of sanity checks. Since not everyone has all platforms available, please volunteer to test trunk configure.

Platform Versions Comments who
reduced function, limited "emergency access"
Older versions of IE.
6 and newer
iPad / iPhone
Firefox / Iceweasel
3.5, 10 and newer
Debian squeeze has 3.5.x, wheezy has 10.x

This is long overdue - thanks!

With respect to browser versions - IE6 seems a bit old. Even the corporate environments that I know of (that held on for years) have upgraded to IE7 or 8. 9 is current, 10 is coming. 6 has a lot of security issues...

Safari - comes in Mac, Windows, iPad and iPhone versions. I don't think the Windows version is particularly popular (not having any of the other platforms, I do use it once in a while.)

I'm particularly interested in the restrictions of webservers other than Apache and of hosted environments. I get snippets like 'can only run scripts' - but while wiki pages can get images directly, configure has to have its own webserver. And path-info is required to run the wiki, but configure can't use it to serve resources in some environments.

This confuses me no end. (It would be more credible that configure takes less webserver configuration this way.)

In any case, it would be helpful to collect the folklore/knowledge so that we can make informed decisions about what to continue, deprecated and/or add.

It would also be helpful (and not just for configure) to get some data on how many customers use these environments, why they're important, and who signs up to test in each.

Development time is limited, and if we're ever to ship a release, we need to know what we are supporting, and a way to test what we claim to support - before the last second.

-- TimotheLitt - 23 Jan 2013

'can only run scripts' - is a setup where the viewfile script is used to access images. Script access can be the only way in for some.

this wasn't however what was the problem with only supporting /bin/configure/resource/favicon.ico - that url setup requires a webserver specific webserver configuration. I know there were users for which this didn't work on apache, though i don't recal what the cfg was, and I'm almost sure that its a url structure that was complicated on IIS.

So the long term lesson we gained from it, is that there needs to be a urlparam way to get resources - and in configure, as its important for it to 'just work' we chose to maximise compatibility to avoid reducing the compatibility set to things we knew a priori.

-- SvenDowideit - 24 Jan 2013

Configure was vast even before these latest improvements, so "testing on a platform" needs to be scoped - otherwise testing could consume many hours for each release on each platform. There are some unit tests I know; the existence of these should eliminate the need for some types of browser testing. Beyond that, what protocol should testers follow? "See if it works" is not really an adequate request and will just alienate testers.

-- CrawfordCurrie - 24 Jan 2013

At this point, I'm not sure even what platforms to test. And what configurations. I'm hoping that if anyone is doing something unusual in their apache or ??? configuration beyond our basic defaults, we can get a copy of it to better understand what the requirements are. It's really hard to solve vague descriptions from years ago.

But at a minimum, I'd like to be assured that the "normal installation flow" of foswiki works without requiring rocket science. And that the "new user" can follow the short list of configuration steps and end up with a fully functional system. A lot of the focus of the changes in configure were trying to actually improve the "out of box" experience, detecting and fixing common "problem areas" like getting email working, and dealing with the path settings.

So for a testing script, how about we add a script to the TestCases something like:
  • Install foswiki distribution file to your normal location
  • Activate __ server with default foswiki configuration
  • Run bin/configure
    1. Did the css, javascript and images all load and do things "look right"
    2. Were the path guesses all correct, any unexpected errors?
    3. Save the initial configuration, and then refresh the screen
    4. Did the configuration get saved correctly,
    5. Examine errors, anything specific for the platform that is unexpected.
    6. Fill in the admin email address, then click the "autoconfigure email" button.
      • Did it detect a valid "sendmail" or equivalent on the platform?
      • If yes, click the button to send a test message and confirm that it worked.
    7. Click the reset button to reset the email settings, fill in the server name, and rerun autoconfigure
      • Did it find a secure connection to the server.
      • If it made a STARTTLS or SSL connection, was it able to validate the certificate path
      • Did it report correctly that a userid/password are required?
      • If needed, fill in a userid/password and autoconfigure again, verify that authentication was successful
      • Test sending an email again.
    8. Test the SSL certificates ...
    9. Visit Configuration Audit tab
      1. Run each audit in sequence. Cursory, Extended, Web Server, Foswiki, Extensions and Analysis
      2. Verify the results after each audit.
        • Reported information expected
        • Any errors reported
        • Dependencies all verified
        • Pathinfo test results valid
        • ...
  • Go to the configured site
    1. Is css, javascript, etc. all delivered correctly
    2. Register a user and verify that registration worked, email received, etc.
    3. Login with that user
  • Return to configure
    1. Run the Extensions installer, and install an extensions
    2. Visit the Log Viewer page and examine the logs
    3. ... I'm sure there are a lot more ... what else
  • Continue with TestCases.TestCaseAmISane

-- GeorgeClark - 24 Jan 2013

BasicForm edit

TopicClassification BrainStorming
TopicSummary Document the special requiremments where configure needs to be functional.
InterestedParties SvenDowideit, TimotheLitt, GeorgeClark
Topic revision: r7 - 25 Jan 2013, MichaelTempest
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