[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