• View
• Edit
• History
• Print
• Backlinks

WikiCascades

Pmwiki uses a series of "cascades" in declaring stuff. Knowing these can be useful to people debugging problems or writing new recipes.

Local customizations

When pmwiki.php is executed, it does some variable initialization and then loads (via include_once()) a sequence of PHP scripts that can perform local customization. Here is the basic sequence in which local customizations are loaded:

    pmwiki.php
      $FarmD/local/farmconfig.php        # farm-wide settings
      local/config.php                   # field/wiki settings
      local/$Group.$Name.php             # per-page settings
      local/$Group.php                   # per-group settings

It may seem odd that per-page settings are loaded before per-group settings. However, per-page settings should be given more weight than per-group settings, and it's much easier for the per-page file to prevent the per-group file from loading altogether (by setting $EnablePGCust=0) than it is to have the per-group file load first and try to have the per-page file "undo" the settings of the per-group file.

If the per-page file wants the per-group settings loaded before doing its own customizations, it can trivially do so with include_once('local/Group.php').

Passwords

There are many different models for page authorization, and PmWiki's built-in tries to accommodate as many as it can. As a result, there are a couple of cascades evident in authorizing access to a page.

First, there are five authorization levels in the PmWiki standard distribution: read, edit, attr, upload, and admin.

When looking to authorize a specific level (e.g., 'edit'), PmWiki uses the first (and only the first) associated password setting it finds from:

    per-page passwords              # set via ?action=attr on a page
    per-group passwords             # set via ?action=attr on GroupAttributes
    default passwords               # set via $DefaultPasswords[...]

Thus page passwords override group passwords, and group passwords override site-wide (default) passwords.

If the above cascade doesn't produce a password setting for the required level, then PmWiki will cascade among authorization levels (set via $AuthCascade):

    edit <= read
    upload <= read
    attr <= edit

This cascade indicates that a page without an explicit edit password uses any read password that may be present. Similarly, a page without an explicit attr password uses the edit password instead. The end result of this cascade is that any read password is implicitly used when an edit or upload password is absent, and the edit password is used when an attr password is absent.

The admin password doesn't really participate in the password cascade -- the admin password simply grants access regardless of any password settings.