One of my activities these months is setting up a community-oriented wiki for the improvisational theater group Preparee (which I'll be captaining next academic year. Oh, the suspense !). I went for the PmWiki distribution, developed by Patrick Michaud. Since quite a lot of customization went into converting the base installation to a user-oriented / CMS-like system I thought I'd better share some of the tricks and snippets I've been writing.
Always check the PmWiki cookbook before you start hacking away yourself: there are tons of available recipes which might already offer the functionality you wish.
Installation is a piece of cake, it's a matter of unpacking the source files and making the right directories writable by the webserver process (by using chmod on the wiki.d directory). I installed pmwiki on a Linux box. All the further customization is done in the local/config.php file, in separate skins or on the wiki pages themselves. Make sure not to touch the files that came with the core distribution (scripts, default skin ...), it makes upgrading a lot easier. I learned it the hard way :)
Users
The first part consisted of converting the wiki into a private one with several accounts which had different permissions. Setting the site-wide privacy settings (which can be finetuned per page or group by using ?action=attr in the URL) is done in the config.php file:
$DefaultPasswords['read'] = 'id:*';
$DefaultPasswords['edit'] = 'id:*';
This only allows logged-in users to read and edit pages. The site-wide admin password is bound to one account name (mine, in this case), but can be bound to a group too.
The accounts themselves can be defined in the SiteAdmin/Authuser page, in the config file, ... I soon realised that this was cumbersome, since I had to create all of the accounts by hand. By moving the accounts to a .htpasswd file and the group definitions to a .htgroup file I was able to automate the registration process :
- Install the excellent htpasswdform recipe. It shows regular users a change password form, unregistered users a new user form and admin users a group/user management tool. Prevent account spam by installing the Captcha recipe too.
- New users get added to a unchecked group. They get restricted privileges. Authorizing them is simply transferring them to the users group. This allows admin to check user accounts first.
- The next part is letting pages display different links for each group. This is done by adding some custom Conditional Markup to the config file: $Conditions['authgroup'] = '$GLOBALS["AuthList"][$condparm] > 0';
This allows you to check a current users group by using (:if authgroup=groupname:) and thus showing different content. I managed to write a quite complicated sidebar / AuthForm chock-full of checks. Dirty, but it works wonderfully well. Other interesting checks: (:if enabled AuthId:) (:if auth admin:) (:if auth read:)
UsabilityThe next step was to add functionality. It's pretty easy to edit the standard edit-form GUI buttons:
$GUIButtons ['textred'] = array($ArrayCount++, '%25red%25', '%25%25', '$[Red Text]','$GUIButtonDirUrlFmt/hightextred.gif"$[Red Text]"');
Adds an extra button which allows the user to color text. Check this page for more info.
Another thing I wrote was a simple shoutbox using Fox forms. This allows people, just by using standard button interaction, to post content to a page (in this case: a shoutbox). I wrote several fox scripts to allow users with no wiki knowledge whatsoever to perform basic tasks (shoutbox, adding themselves to an event, ...) by just using buttons and standard forms. It doesn't always result in pretty code, though ...
Shoutbox
I submitted this to the PmWiki cookbook. You can find the code
here. This block was implemented as a page in a permanent div block I added to my custom skin. It's pretty straightforward from there. Don't forget: do not edit the default pmwiki skin, it will get replaced by a new version on the next upgrade.
Event attending/not attending list
This one's a bit uglier:
%comment% Start enroll/disroll code '''Attending''' %comment% enrolllist '''Not attending''' %comment% disrolllist (:fox enroll:) (:foxreplace template=Site.EnrollRemove target={$FullName} put=all mark="* [[Profiles/{$$author}]]" foxsuccess='[[<<]]' foxfailure='[[<<]]':) (:foxadd template=Site.EnrollAdd target='{$FullName}' put=below mark=enrolllist foxsuccess='Attending!' foxfailure='Probleem !':) (:input hidden author value='{$Author}' :) (:input hidden csum value='is attending':) %center%(:input submit post 'Im attending':) (:foxend enroll:) (:fox disroll:) (:foxreplace template=Site.EnrollRemove target='{$FullName}' put=all mark="* [[Profiles/{$$author}]]" foxsuccess='[[<<]]' foxfailure='[[<<]]':) (:foxadd template=Site.EnrollAdd target='{$FullName}' put=below mark=disrolllist foxsuccess='Not attending' foxfailure='Problem !':) (:input hidden author value='{$Author}' :) (:input hidden csum value='is not attending':) %center%(:input submit post 'Im not attending':) (:foxend disroll:) (:foxmessage enroll:)
(:foxmessage disroll:)
As you can see, both of the buttons are in a different fox form, each with two actions: replace the current occurences of the author name on the page, and add it to the right list. Disadvantage: you can't use more than one of these on the same page, only the first will get updated. Makes you wonder ... what if people were actually good enough to simply use the edit button and add their name ? :)
