PmWiki | Profiles / Scott Connard

Hello Fellow PmWikians,

I am using PmWiki for everything I can think of. I've set up a farm on a Mac OS X system at work and use it for two separate work projects and also a Community Theater that I am very active with.

So far I have experimented with farm installation, CleanURLs, setting skins, RSS feeds, user authorization, WikiForms, Pm Calendar and Save Draft. I like PmWiki a lot, but as I've seen mentioned elsewhere, it is wonderfully simple to set up and begin to use, but some of the more in-depth features take some time to research and get used to. All in all, a great product and a helpful group of people using it.

While I am a programmer, I do not (yet) know php, so I'm not contributing anything to the project at this point.

Scott Connard (email: connard (at) dsg-inc (dot) com)

PmWiki scripts I use:

AuthUser
Clean Urls ?
Drafts
Shared Pages ?
Web Feeds

Cookbook recipes I use:

Action Log
Expire Diff
Feed Links
Fox
Http Variables
Inline Diff
Major Changes
Page Table of Contents
Pm Calendar
Recent Uploads Log
Recipe Check
Rename Page
Simple Forum
Site Analyzer
Skin Change
Toggle
Total Counter
Wiki Forms - I describe my testing in PITS/00756

My Farm Implementation (with CleanURLs)

Since there are so many different variants on PmWiki farm implementations, I thought I'd document mine. I'm running a Mac OS X system so I have complete access to all the configuration files.

I created 3 directories in my Sites folder; pmwiki for the main wiki and 2 field wikis. The pmwiki directory is a normal installation except I used the docs/sample-config.php file as the basis for my local/farmconfig.php file. I did add $FarmPubDirUrl and other farm-wide cookbooks and other settings. I test things in the pmwiki wiki.
Each field (including pmwiki) has a local/config.php file with $ScriptUrl, $PubDirUrl, $WikiTitle and any local cookbook and other settings.
Rather than use the URL http://www.example.com/~scott/pmwiki/pmwiki.php?Main/HomePage, I implemented CleanURLs using the two aliases method (see CleanURLs)
- I set $EnablePathInfo = 1; in local/farmconfig.php.
- I added two Aliases for each wiki to /etc/httpd/httpd.conf:
```
Alias /pmwiki /Users/scott/Sites/pmwiki/index.php
Alias /pmfiles /Users/scott/Sites/pmwiki/
```
The first provides the initial URL to the site and the pmwiki.php code and the second provides the link to the directory used for all the files. Remember to restart Apache after any changes to its config file (sudo /System/Library/StartupItems/Apache/Apache restart). I then had to change various config settings to match these URLs:
```
$FarmPubDirUrl = 'http://www.example.com/pmfiles/pub';
$ScriptUrl = 'http://www.example.com/pmwiki';
$PubDirUrl = 'http://www.example.com/pmfiles/pub';
```
Other variables (typically URLs to files or directories, like $PageLogoUrl) had to be changed to use the pmfiles or fieldn-files references.
My final URLs are http://www.example.com/pmwiki/Main/HomePage
I have not used local cookbook directories, I simply place all cookbooks into the farm even if I only include them in one of the wikis.
I have recently set up pub/css directories in some of the wikis to hold group-specific css files (e.g., for PmCal).

Save Draft

I wanted to have Save Draft turned on for a single group ("Test" in the following examples). I needed to allow authorized users perform the draft edits and a small group of special people "publish" the drafts. I used the built-in AuthUser script and its associated Site.AuthUser page to declare users and groups. This feature become much easier to implement after 2.2.0-beta43.

Site.SideBar

I have login/logout links in my Site.SideBar.

(:if ! enabled AuthPw:)
* [[{$FullName}?action=login | Login]]
(:if enabled AuthPw:)
* [[Main/HomePage?action=logout | Logout {$AuthId}]]
(:ifend:)

Test.EditForm (This change is not needed any longer)

This EditForm simply displays different Save buttons depending on your authorization level. Test.EditForm is a copy of Site.EditForm with the normal Save button line replaced with the following lines: (the second line has been wrapped for readability)

(:if auth publish:)
(:input e_savebutton:) (:input e_saveeditbutton:) (:input e_savedraftbutton:) \\
  (:input e_previewbutton:) (:input e_cancelbutton:)
(:if ! auth publish:)
(:input e_savedraftbutton value="Save Draft":) (:input e_previewbutton:) (:input e_cancelbutton:)
(:ifend:)

You can see that users without the publish permission can only use the Save Draft button to save a draft copy, while the privileged publishers can Save or Save Draft. I did not get as fancy as some of the suggested button naming schemes suggest (see PITS/00755). You must create the EditForm page before creating the following Test.php configuration file.

Test.php

The group configuration parameters that would have gone in the local/config.php file were placed in the local/Test.php file instead. These changes enable the Save Draft feature, declare the special edit form that displays different Save buttons depending on your authorization and adds a "publish" password which is used to determine if you are authorized to publish the draft pages. The "publish" password has a default value, grants you edit capability and allows you to set it on an attributes page using ?action=attr.

<?php
# turn on draft edits
$EnableDrafts = 1;
# use special edit form with button swapping
$PageEditForm = 'Test.EditForm';
# create a publish password for Drafts
$DefaultPasswords['publish'] = crypt('publish');
$AuthCascade['publish'] = 'edit';
$PageAttributes['passwdpublish'] = '$[Set new publish password:]';

After 2.2.0-beta43, only the following configuration is necessary.

<?php
# turn on draft edits
$EnableDrafts = 1;
$EnablePublish = 1;
# create a publish password for Drafts
$DefaultPasswords['publish'] = crypt('publish');

Test.GroupAttributes

I created this file using ?action=attr so I could specify a group edit password and allow all registered users to edit (editpassword id:*) and set the publish password (@publishers).

Test.GroupHeader

I placed some conditional code in the group header to let the users know if a draft page existed so that they had the choice of viewing the official page or the draft page. PmWiki automatically selects the draft page (if it exists) for editing if a user decides to edit either page.

(:if exists {$FullName}-Draft:)
%red bgcolor=pink padding=10px border='1px solid black'%[[{$FullName}-Draft]] exists%%

(:ifend:)

With the new PmWiki 2.1.beta, the {$BaseName} variable is available, so I could get a little fancier. The following Test.GroupHeader requires additional lines in Test.php:

# define Basename of draft documents
$BaseNamePatterns['/-Draft$/'] = '';

(:if exists {$FullName}-Draft:)
%red bgcolor=pink padding=10px border='1px solid black'% [[{$FullName}-Draft]] exists %%

(:if ( name {$BaseName}-Draft && exists {$BaseName} ) :)
%red bgcolor=lightblue padding=10px border='1px solid black'% [[{$BaseName} | official {$BaseName}]] %%

(:ifend:)

With PmWiki 2.2 beta, I'm using the following.

(:if exists {*$FullName}-Draft:)
%red bgcolor=pink padding=10px border='1px solid black'% A DRAFT page exists: [[{*$FullName}-Draft]] %%

(:if ( name {*$BaseName}-Draft && exists {*$BaseName} ) :)
%red bgcolor=pink padding=10px border='1px solid black'% This is a DRAFT page of [[{*$BaseName}]] %%

(:if ( name *-Draft && equal {$BaseName} '' ) :)
%red bgcolor=pink padding=10px border='1px solid black'% This is a DRAFT page %%

(:if:)