[Pmwiki-users] How best to develop a wiki farm

[John Rankin]

On Wednesday, 17 March 2004 6:21 AM, Patrick R. Michaud <pmichaud at pobox.com> wrote:
>On Fri, Mar 12, 2004 at 01:25:21PM +1300, John Rankin wrote:
>> We are starting to make a way to develop a collection of related 
>> wikis (a farm as a collection of fields), all sharing the same 
>> code and core pages, but able to act independently. 
>> [...]
>> pmwiki/
>>     pmwiki.php
>>     scripts/
>>     wikilib.d/
>>     pub/
>>     local/
>>     wiki.d/    #maybe, maybe not
>>     uploads/   #maybe, maybe not
>>     field.a/
>>         wiki.d/
>>         pub/
>>         local/
>>         uploads/
>
>In this case I think I would've taken a slightly different approach
>to the directory structure---choosing instead:
>
>pmwiki/
>    pmwiki.php
>    scripts/
>    wikilib.d/
>    pub/
>      field/     
>    local/
>      field/     
>    wiki.d/    
>      field/
>    uploads/ 
>      field.Group/  or field/Group/
>
>My thinking on this is that there may not be a lot of need for separate
>field.a/ directories in pub/ and local/, and we probably don't want a
>field's pub and local directories automatically created or owned by the
>webserver process anyway.  Plus in this approach we don't have to keep 
>global write permissions on the pmwiki/ directory to be able to 
>create the field/ subdirectories.

The reason we initially didn't go this route (which is certainly a
reasonable one) is that it makes it slightly tricky to remove a
field at a later date. The other option we more recently thought 
about is

pmwiki/
    wiki.d/
    wikilib.d/
    scripts/
    local/
    pub/
    uploads/
    wikifarm.d/
        field.a/
            wiki.d/
            local/
            pub/
            uploads/
        field.b/

and so on. This removes the need for global write permissions
on pmwiki/ and wikifarm.d/ gets created in the same way as
wiki.d/ and uploads/.

>
>The basic logic would go as follows:  If we detect that we're in
>a field of the farm, defined by the $Field variable being somehow
>set in config.php, then
>
>1. $WikiDir is set to 'wiki.d/$Field' 
>      (automatically created if wiki.d/ exists and is writable)
>2. $UploadDirFmt is set to 'uploads/$Field'
>     -or-
>   $UploadPrefixFmt is set to '/$Field.$Group/'
>   (both with corresponding changes to $UploadUrlFmt)
>3. A local pgcust.php algorithm is used to read local customizations 
>   from the local/field directories in addition to the default local/ 
>   scripts.  Or, it can be made "instead of the default local/ scripts" by
>   setting $EnablePerGroupCust=0.
>
>How a field is chosen (based on URL, domain name, cookie, or some other 
>criteria) can be left to the wiki administrator to decide in
>local/config.php.

We are thinking of a Main.WikiFarm (and a $WikiFarm variable to set
the page to use) that lists the available fields -- to create a new
field, add it to the list and the local customisation takes over.

This also allows the fields' home pages to form a ring or trail,
using the list on Main.WikiFarm to determine next and previous.
Since there is only one farm trail, a [[$Farmtrail]] variable
is probalby the way to go, I think -- this looks for Main.WikiFarm
in the home field and builds a trail from it.

>
>Overall, I like it.  I can envision a wikifarm script along these
>lines becoming part of the standard PmWiki distribution.
>
>Pm
>


-- 
JR
--
John Rankin