[pmwiki-users] General Farming Questions

Patrick R. Michaud pmichaud at pobox.com
Wed Sep 28 21:47:46 CDT 2005


Some more quick answers, with a longer detailed description to
follow if needed...

> so,
> 1) what is the easiest way to have different groups not see each other ?

By default, wiki groups aren't normally aware of other groups unless authors
or admins create links to them.  This is why each group has its own 
RecentChanges page separate from Site.AllRecentChanges, and the default 
PmWiki skin doesn't have a link to Site.AllRecentChanges.  Someone coming
into a PmWiki group won't typically know anything about other groups 
unless an author or admin makes explicit references to them somehow.

> 2) While, I'm content to let everyone run under Gemini, for "each  
> client could look substantially different." are you applying a  
> different skin to a different group? If so,  how?

Each group is able to have a custom configuration file, in 
local/<Group>.php -- settings here typically override settings made
in the config.php file.  So, to change skins for the XYZ group,
simply set local/XYZ.php to contain:

      $Skin = 'otherskin';

Beyond that, pages are allowed to contain (:noheader:), (:nofooter:),
etc., so authors can use XYZ.GroupHeader and XYZ.GroupFooter to design
custom "skins" of a sort by turning off the default headers and
footers.

> 3) easy of navigation is an issue. I have one side bar for the whole  
> wiki. It's getting pretty long. 

Each group can have its own sidebar, at XYZ.SideBar.  This replaces
the site-wide default.

> If you want the "super naive" user/ 
> client to come in, just see their own project-wiki, you want also  
> their side bar to have links just within that group with a "home"  
> link for "super users" to jump out to the main site as needed (but  
> would have to have logged in originally as a "super" user: i.e. one  
> who can read and edit any page anywhere...)

Inside of a group's SideBar, you can do a simple

    (:include Main.SuperUserBar:)

If the currently logged in person doesn't have read permissions for
Main.SuperUserBar (i.e., aren't logged in as a "super" user), then
they won't see any of the contents of that page.

> 4) what is the most facile method to manage the access users, passwords

Well, you're already setting up .htaccess files, so I'd continue to
use that.  However, instead of having separate .htaccess files for
each wiki field, I'd set up a single .htaccess file that protects
the entire wiki (all groups).  

In the local/config.php, add the line:

    if (@$_SERVER['REMOTE_USER']) $AuthId = $_SERVER['REMOTE_USER'];

This tells PmWiki to honor any authentication performed by the 
webserver, and we continue to allow Apache to perform the authentication
(and you continue to use your web admin GUI and maintain passwords
there).

Then, to limit access to a group XYZ to users alice, bob, and carol,
simply set the read password of XYZ.GroupAttributes to

    id:alice,bob,carol

Anyone who isn't logged in as alice, bob, or carol won't be able
to read the pages in that group.  

Further, if you set $EnablePageListProtect=1, then even searches
and pagelists will only show those pages for which the currently
logged in user has read access.

Does this help give a few ideas...?  Feel free to ask more questions
or for more details.  :-)

Pm

> On Sep 27, 2005, at 10:23 AM, Patrick R. Michaud wrote:
> >However, it's worth noting that my original intent for wikigroups
> >was to be able to easily support multiple clients under a single wiki,
> >where each client could look substantially different from the others.
> >(In my case, I needed the "clients" to be able to create their own
> >sections of the wiki without needing to bug me to do it for them. :-)




More information about the pmwiki-users mailing list