I am considering a service of Foswiki hosting, where I will maintain a single Foswiki installation and each customer has its own set of webs, in a way that each customer would have its own Virtual Host. At every request, depending of the hostname used, would expose a different wiki system. In such a setup we'll have things that we'll want to share between all virtual hosts, and will not want to share other things.

Things you'll want to share between virtual hosts:

  • the entire Foswiki infra-structure
  • the System web
  • most of the configuration
Things you won't want to share between virtual hosts:

  • users
  • webs, except System
  • some configuration

Possible implementations

LocalSite.cfg hack

I tried this one as a proof of concept, and it "works" (not tested throughly, though). It consists of two parts:

1) change in the configuration loading

diff --git a/lib/Foswiki/Configure/ b/lib/Foswiki/Configure/
index a331bb0..7070e51 100644
--- a/lib/Foswiki/Configure/
+++ b/lib/Foswiki/Configure/
@@ -16,6 +16,26 @@ package Foswiki::Configure::Load;
 our $TRUE = 1;
+=begin TML
+---++ StaticMethod configFiles()
+Determines which configuration files Foswiki is going to use.
+sub configFiles {
+    my @config = (
+        'LocalSite.cfg'
+    );
+    my $host = 'localhost'; # <= HERE we should determine which virtual host we are in.
+    push @config, "LocalSite-$host.cfg";
+    return @config;
 =begin TML
 ---++ StaticMethod readConfig()
@@ -52,14 +72,16 @@ GOLLYGOSH
     # Read LocalSite.cfg
-    unless ( do 'LocalSite.cfg' ) {
-        die <<GOLLYGOSH;
+    for my $config (configFiles()) {
+        unless ( do($config) ) {
+            die <<GOLLYGOSH;
 Content-type: text/plain
 Perl error when reading LocalSite.cfg: $@
 Please inform the site admin.
-        exit 1;
+            exit 1;
+        }
     # If we got this far without definitions for key variables, then

2) custom config file for each virtual host, overriding the settings I need to override for the given virtual host. What I have here is the following in lib/LocalSite-localhost.cfg:

# vim: ft=perl
$Foswiki::cfg{PubDir} = '/home/terceiro/src/foswiki/core/vhosts/localhost/pub';
$Foswiki::cfg{DataDir} = '/home/terceiro/src/foswiki/core/vhosts/localhost/data';
$Foswiki::cfg{WorkingDir} = '/home/terceiro/src/foswiki/core/vhosts/localhost/working';

This approach has the drawback of only working with the CGI engine, unless we configure different instances of FastCGI/!ModPerl/HTTP Engine for each virtual host. This would probably going to be overkill, i.e. if I have 10 customers running 10 different Foswiki instances I would block a lot of resources (memory, mainly) that will be idle for most of the time.



-- AntonioTerceiro - 05 Aug 2009


I would like to hear from everyone interested on this.

-- AntonioTerceiro - 05 Aug 2009

Sharing System might arise some more problems: Some plugin (most of the old ones) have their configuration on the plugin topic in the System web. Some skins can be customized by editing topics in System. Your virtual foswikis cannot differ in those aspects.

-- OliverKrueger - 05 Aug 2009

This is a very interesting initiative! Many people face this issue: maintain multiple foswiki setups on the same host. It would be wonderful to make this task easier!

-- GilmarSantosJr - 07 Aug 2009

I have also worked on code to do this, though on TmWiki - in my code, the users are stored in a database, and they can invite users into their webs, with a quota management system and other bells. unhappily, the TmWikiNet crap happened and so I stopped work on it.

Wrt shared System web - yes, the topics are shared, but you can enable/disable the plugins on a per-web basis.

I was wondering if we (the Foswiki Community) would like to set up such a system at

-- SvenDowideit - 07 Aug 2009

I like the idea a lot.

Can you explain why your approach fails on fastcgi?

What about plugins? Is there a problem of the sort of harming the stability of all wiki spaces just by enabling one specific plugin for one client? I guess so.

-- MichaelDaum - 07 Aug 2009

Michael: it would only work with CGI because the configuration is loaded during starup/compilation, and with FastCGI this happens only once, when the FastCGI process starts; what we need in such a case is to have a different configuration for each request depending on the hostname that is being accessed.

-- AntonioTerceiro - 07 Aug 2009

Oh I see. So loading the site-specific settings must be moved from compile time to execution time somewhere early in the code. Worth refactoring it as FastCGI or any other persistent perl mode is pretty essential for modern web apps.

-- MichaelDaum - 10 Aug 2009

There's another problem not mentioned yet: Foswiki generates too many full URLs instead of URL paths. If that gets cached (using the new PageCache), users will experience to suddenly have shifted the domain. One of the causes of the problem is Foswiki::Func::getScriptUrl. This generates a full URL. There is also a Foswiki::Func::getScriptUrlPath but that function is deprecated since 28 Nov 2008 for no good reason.

-- MichaelDaum - 12 Aug 2009

Michael, I don't see why the full paths would be a problem: what we want here is to be able to serve different sets of webs from different domains, so this issue should not have negative impact (AFAICT). Could you elaborate?

-- AntonioTerceiro - 16 Aug 2009

Never mind, Antonio. I solved the problem by adding server_name and server_port to the keys of a cached page in the FoswikiCache. That way a topic computed via one domain and thus has got full urls in its markup will never be fetched from cache when the same topic is requested from another domain. That would be the case if part of the webs like the System web is shared among domains.

-- MichaelDaum - 17 Aug 2009

How can I sign up for this service? smile Or become a tester etc?

-- SimonHardyFrancis - 29 Nov 2009

Hello all,

I've just uploaded the first release of VirtualHostingContrib, which implements virtual hosting support for Foswiki.

I'd be happy to receive any feedback about it.

-- AntonioTerceiro - 16 Jul 2010

Yum Yum.

-- MichaelDaum - 20 Jul 2010
Topic revision: r14 - 20 Jul 2010, MichaelDaum
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