edit SideBar

PmWiki • WikiFarms

administrators (intermediate) A WikiFarm is a collection of two or more wikis running on the same web server and sharing a set of common components. The term is based on the computing phrase "server farm".

This page provides some background information about WikiFarms and describes how to turn a "normal" configuration into a farm by adding a wiki. There are many ways to configure wiki farms; this page describes only one, in an effort make it as simple as possible for the administrator who is creating a farm for the first time.

Why use a farm?

The primary motivation for using a wiki farm is to reduce the amount of administrative work involved in managing several wikis. In a farm, most of the PmWiki code is stored in one place and is shared by all the wikis. An administrator can (for example) upgrade to a new version of PmWiki on every wiki in the farm by simply updating the shared components in a single location.

From a reader's point of view, each wiki in a farm is completely independent, and appears as a separate web site. Each wiki in a farm:

  • has its own URL, and the URLs can be in different domains
  • can have its own look and feel by using different skins
  • can have its own add-ons or "recipes" from the Cookbook
  • can have its own administrator responsible for local configuration

Why not to use a farm

Because the wikis in a farm are all independent, it is difficult (but not impossible) to provide services that require access to more than one wiki. For example, the PmWiki search function can only search within one wiki. Using a farm as a way of subdividing related content is generally a bad idea. A much better way to subdivide content is to use WikiGroups.

I still can't decide if I need a farm ...

The good news is that you don't have to decide in advance. In fact, the recommended procedure is to first do a "normal" or single installation of PmWiki. Use it for a while. Create pages and edit them. Get to know how to add recipes. Be sure to try out WikiGroups (they may be all you need).

Once you have decided that you need another wiki, you have two basic choices:

  1. Do a complete installation of PmWiki in a new directory. This gives you two totally independent wikis that are completely self-contained. This is not a wiki farm.
  2. Create a wiki farm using your existing wiki as the "home wiki" where most of the shared PmWiki components will live.

Choice number 1 can be a good choice for several reasons:

  • it is not a wiki farm, and requires no additional administrative knowledge - it's just two installations
  • if you decide to move one of the wikis to another server, you can simply copy the wiki directory structure to the second server, and it will work (assuming there is a web server and PHP in place).
  • you can run different versions of PmWiki on each wiki (good for testing new versions)
  • no matter how badly you mess up one installation, it doesn't affect the other

If you choose to create a wiki farm, then read on ...


Before you create a farm, make sure that:

Creating the home wiki

You do have a working installation of PmWiki at this point, don't you? That's good, because your existing wiki is about to become the home wiki of your farm.

In the directory that contains your existing wiki, create the file local/farmconfig.php. This file is used to hold any customizations that apply across the whole farm. For example, you could assign an admin password in farmconfig.php that will be used by all of the wikis in your farm.

If the URL used to access your existing wiki is http://www.example.com/pmwiki/ then a minimal farmconfig.php file would look like this:

    <?php if (!defined('PmWiki')) exit();
      $FarmPubDirUrl = 'http://www.example.com/pmwiki/pub';

This loads the variable $FarmPubDirUrl with the URL location of your home wiki's pub/ directory. All of the wikis in your farm share this pub/ directory. The pub/ directory holds skin definitions and GUI-edit buttons to be shared by all the wikis in the farm.

Amazing as it may sound, this completes all of the changes you need to make in order to turn your existing wiki into the home wiki of your farm.

Creating an additional wiki in your farm

1. Create a directory to hold the new wiki. This directory must be web-accessible, just like the directory that holds your home wiki.

2. Create a file called index.php in the directory with the following contents:

    <?php include('path/to/pmwiki.php');

This allows your new wiki to share the PmWiki code stored in your home wiki. The path/to/pmwiki.php is the file path to pmwiki.php in your home wiki. Use an absolute file path (/home/username/pmwiki/pmwiki.php) or a relative file path (../pmwiki/pmwiki.php). Do not use a url path - there should not be an 'http://' in it anywhere. For a web server running under Windows, you need to use a complete file path as in C:/Apache Group/Apache2/www/mynewwiki/.

3. Open a web browser and browse the URL of the new wiki. This will be a web address starting with 'http://'. PmWiki will attempt to automatically create a writable wiki.d/ directory where the wiki's pages will be stored. If you see an error message, follow the instructions. If you choose the option for a "slightly more secure installation" be sure to execute both commands.

Your new wiki is now set up, and your farm now contains 2 wikis. To add more wikis, just repeat these 3 steps.


Each wiki in a farm inherits the settings stored in farmconfig.php. Do any customization that you want to apply farm-wide (to all the wikis) in farmconfig.php.

Create a local/ directory within each wiki's directory to hold local customization that apply only to that wiki. Farm-wide customizations are processed before the individual wiki local customizations.

The PmWiki variable $FarmD points to the directory in which pmwiki.php is installed, and your home wiki, and it is used as a prefix to allow the other wikis to share PmWiki components. For example:

  • $FarmD/scripts/ points to the shared scripts/ directory
  • $FarmD/pub/ points to the shared pub/ directory
  • $FarmD/cookbook/ points to the shared cookbook/ directory


  • The terminology used to describe wiki farms is not used consistently. See WikiFarmTerminology for more info.
  • It is important to remember that not all of the recipes in the Cookbook have been written for or tested with farms. Be sure to look for instructions on how to use a recipe on a farm.
  • There are many, many more things you can do with farms. Some are described on WikiFarmsAdvanced? which also contains links to step-by-step examples of setting up a farm.

July 2014:
Yate 5.4 and YateBTS 4 launched. Added JSON and DNS support in Javascript, Handover support in YateBTS.

March 2014:
YateBTS 2.0 launched. Added authentication and WebGUI. Added USSD support in commercial version.

March 2014:
Yate 5.2 launched. Better JavaScript support and a fixed memory leak.

Jan 2014:
YateBTS 1.0 launched. The first GSM Basestation which works with an IMS/VoLTE core network.

Jan 2014:
Yate 5.1 launched. Better JavaScript support and added libygsm. Elisa chatbot added in RManager

Oct 2013:
OpenHSS is the Yate based HLR/HSS solution for MVNO and LTE carriers.

Oct 2013:
Yate 5 released. Added IPv6 support in SIP for LTE. Improved JavaScript support. Download NOW

Jan 2013:
Yate 4.3 released: Added XML support in Javascript. SCCP - GTT routing between different networks. Stability improvements.
Download NOW

Aug 2012:
Yate 4.2 released: SIP flood protection. Better Jabber/Google Voice support. Usable Javascript. Fixed SIGTRAN links fluctuations.
Download NOW

Apr 2012:
YateClient was accepted in the Mac Store.

Yate 4.1 released: better Gvoice support, iSAC codec, support for new Wanpipe drivers. Fixes T.38 and Mac client issues.

Mar 2012:
SS7Cloud is launched today, 1st March, 2012, by NullTeam, Yate creators. Having all you need to be a US CLEC, it brings SS7 services in a cloud.

Feb 2012:
Yate 4.0 released.
SCCP, TCAP, MAP and CAMEL, TCP and TLS in SIP, Javascript fast prototyping of telephony applications and brand new face for YateClient.

Nov 2011:
Here is a video that, quote "demonstrates the truly awesome power of the YATE engine, as it easily handles 3 simultaneous calls to an audio player application including dtmf (button press) handling "(from PaintedRockComm).

Nov 2011:
Yate will attend ORR - OPENRHEINRUHR (November 12 - 13).

04 May 2011:
sipgate chooses open source project Yate for core infrastructure.

12 Apr 2011:
Yate 3.3.2 released.
Fix for Jingle calls to Google Voice dropping after 5 minutes.
4 Apr 2011:
Yate 3.3 released.
Support for GMail chat conference, fixes for internal microphone in MacOS. Minor fixes in SS7 M2PA and ANSI. Fixes in H.323, SIP and RTP.

9 Mar 2011:
Yate 3.2 released.
Bug fixes in SIGTRAN/MGCP/SS7 and added support for CNAM/LNP lookup by SIP INVITE/3xx.

Feb 2011:
Yate will attend FOSDEM and XMPP summit.

31 Jan 2011:
Yate 3.1 released.
Yate client support for Google Voice. Support for any country tones in tonegen.

20 Dec 2010:
Yate 3.0 released.
SS7 ITU certified. SS7 STP added. Client supports Jabber IM (Google Talk + Facebook).

3 May 2010:
Yate 3.0.0 alpha 3 released. Featuring the new Jabber server and wideband audio.

8 March 2010:
Yate 2.2 released. Mostly bug fixes. Dahdi compatible. Latest 2 release before 3.0.

6-7 February 2010:
Yate booth at FOSDEM 2010. Free CD with Freesentral available.

2 Nov 2009:
Yate 2.1 launched. Can replace a Cisco PGW2200 to control a Cisco AS54xx.

6 Aug 2008:
Yate and OpenSIPS (former OpenSER) join to build IP based clusters.

4 Aug 2008:
Yate 2 launched.

EditHistoryBacklinksRecent ChangesSearch