Pmwiki uses a series of cascades in declaring stuff. Knowing these can be useful to people debugging problems or writing new recipes.
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').
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.
CSS
The look and feel of a wiki page is shaped initially by the page template file.
Cascading style sheets (CSS) then provide the formatting.
The style sheet cascade works as follows (a simplified explanation)[1].
Where there are multiple CSS rules the one that comes last will be used
CSS files are thus more important the later they are included.
However inline CSS in general is considered to be the most specific and has the final say.
This is what CSS for recipes should be provided in style sheet files, rather than inline, to allow webmasters to easily customise it.
The following list indicates the 'importance' of the CSS source, but it should be noted that the CSS source is in fact processed from the bottom up
- inline CSS (eg generated in the header, or from wiki styles)
- pmwiki.css (found in the same directory as the template
.tmpl file)
- groupname.pagename.css (found in
/pub/css/) where pagename refers to a specific page in a specifi group named groupname
- groupname.css (found in
/pub/css/) where groupname applies to all pages in a specific group, see group customizations
- local.css (found in
/pub/css/) see initial setup tasks
