[Pmwiki-users] Multiple Wiki's

John Rankin john.rankin
Mon Apr 19 17:46:55 CDT 2004


On Tuesday, 20 April 2004 10:30 AM, Steven Leite <steven_leite at kitimat.net> wrote:
>Just had a few ideas pop in to my head about the multiple wiki's discussion
>from a few weeks back.  I've started to gather quite a little collection of
>(Pm)Wiki's on my localhost now.  I was looking at the directories and
>thinking how many times I have to perform an upgrade if I wanted to update
>them all at the same time.

Sounds as if you might be a candidate for the wikifarm recipe, which is
almost ready for a brave alpha tester. It works for us, but others
might have problems with it, depending on their configuration.

Its model is that a wikifarm is a collection of wikifields, arranged around
a 'home' field.

>
>Here's my thoughts.
>
>1.  Each "wiki" should be contained in it's own folder (within the pmwiki/
>folder).  You could go one better and have a folder called pmwiki/wikis/,
>and store all the wiki's there.  Example:
>pmwiki/wikis/Wiki1
>pmwiki/wikis/Wiki2
>etc..

we use the directories:
pmwiki/wikifarm/fieldname.wiki.d
pmwiki/wikifarm/fieldname.uploads

>
>2.  The current (location of) wiki.d and wikilib.d would remain (as
>"defaults").

yes

>
>3.  Additional Wiki's would have their own wiki.d and (possibly) wikilib.d
>folder to draw upon.  If they don't exist, then see point #2.

we share wikilib.d; we also share a (configurable) list of groups in wiki.d,
by default Profiles and PmWiki pages always refer to the 'home' area

>
>4.  All templates/css would be store in either:
>  (a) pmwiki/pub/skins  (unchanged from where they're being stored right
>now)

yes

>  (b) pmwiki/wikis/Wiki1/pub/skins  (an alternate location to store
>templates specific to that Wiki.
>
>...
>
>5.  I haven't thought as far ahead of config options yet, but I think the
>same naming scheme could/should be applied as above.  Eg.  Having option (a)
>putting the config files in the one existing /local/config.php format, and
>prefixing config files that belong to a separate wiki with the wiki name,
>like /local/Wiki1.config.php, or /local/wiki2.config.php.  Again, this makes
>it really easy to change config files for different Wiki's, without having
>to go searching through different wiki folders.  All config files for all
>wiki's are right there, easy to edit/update.  Also having option (b)
>available,  where PmWiki would check the
>/pmwiki/wikis/Wiki1/local/config.php or /pmwiki/wikis/Wiki2/local/config.php
>files to see if they exist will make other users who want their config.php
>files to be seperated in to their respective wiki's happy too

yes, we look for local/wikifarm/field.config.php and if it exists, load it;
we also look for local/wikifarm/field.$Group.php and 
local/wikifarm/field.$Group.$Title.php -- just like pmwiki's pgcust.php

>
>6.  The main thing is that one version of PmWiki is running all the sites,
>and all the (core) files are in once place (same place they are at right
>now).

yes and the wikifarm scripts require *no* changes to pmwiki itself

>
>Okay, that's about it.  Just a few quick ideas, thought I would share.  I
>hope to see some working proto-types soon.
>
>Okay, one more last thought...
>
>7.  I'm not sure, but I think this would have to be built-in to PmWiki.php,
>otherwise, if you include as an add-on (using
>include_once(multiwiki.php); ), which config.php file do you put it in?  If
>it's in Pmwiki.php core, then all wiki's will have access to it without any
>special fooling-around.

well, we just load it in local/config.php -- sequencing is a bit tricky:
for example, we have the wikilogo always return to the main home page,
plus have a link to the current field's home page; also, one might set
$EnableUploads = 1; in config.php and then set $EnableUploads = 0; in 
SomeField.config.php

>
>8.  Okay, very last one.  I think the "default" wiki (eg.
>pmwiki/local/config.php) could share the config.php options with ALL wikis.
>So if you want ALL wiki's to have the SAME title (just a dumb example), then
>you could set the $WikiTitle in the config.php file.  Or, a better example,
>if you wanted to change the height/width of the EDIT form to be the same
>size accross ALL your wikis, why do it 10 times .. just do it once in the
>main config.php file, and all Wiki's inherit that config.  In addition to
>the default config.php file that currently exists, the Wiki1.config.php, or
>Wiki2.config.php files could/should also be read (and probably over-ride
>options set in config.php).

yes, except that it's up to the administrator whether farm-wide options
override field-specific options, or vice versa -- for example, you can
(if you want) shut down uploads across all fields by setting
$EnableUploads = 0; after any local/wikifarm/$Field.config.php files load

>
>Okay, that's it.

A couple more features: use intermap syntax to link to pages in another
field: SomeField:/AGroup/APage -- and it behaves like a normal reference,
so that if it exists, it's a link; if not, a ? links to the edit view

and the fields form a trail, so you can give peple links to the 'next'
and 'previous' field's home page

Biggest benefits:
- one copy of pmwiki and any local customisations

- field-wide passwords (ie you can set a farm-wide password, a 
field-wide password, a group password or a page password)

Biggest hassles:
- supporting shared groups without changing pmwiki itself, which
we are still debugging (example: ThisField is a PmWiki/WikiWikiWeb
has to render the first as a link to ThisField in the current 
group of the current field, whereas the second is a link to a page
in the home field)

- getting the 'mental model' right -- there are a lot of options
for how things 'should' work and, having made a design decision,
working through the ramifications to provide a consistent result
(example: Edit Page, Page History and Recent Changes link to the
current field, but Wiki Help links to the 'home' (shared) field)

>
>--Steven Leite
>
>
>-- 
>Pmwiki-users mailing list
>Pmwiki-users at pmichaud.com
>http://pmichaud.com/mailman/listinfo/pmwiki-users_pmichaud.com
>


-- 
JR
--
John Rankin





More information about the pmwiki-users mailing list