version=pmwiki-2.2.5 ordered=1 urlencoded=1
agent=Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.43 Safari/530.5
author=Simon
charset=ISO-8859-1
csum=GroupCustomizations 
host=202.37.32.2
name=PmWiki.WikiCascades
rev=9
targets=PmWiki.LocalCustomizations,PmWiki.Passwords,PmWiki.SkinTemplates,PmWiki.WikiStyles,PmWiki.GroupCustomizations,PmWiki.InitialSetupTasks
text=(:Summary: The order of usage or selection of settings and files:)%0aPmwiki uses a series of "cascades"'^[[http://w3.org/TR/REC-CSS2/cascade.html|#]]^' in declaring stuff. Knowing these can be useful to people debugging problems or writing new recipes. %0a%0a!! [[Local customizations]]%0a%0aWhen 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:%0a%0a->[@%0apmwiki.php%0a  $FarmD/local/farmconfig.php        # farm-wide settings%0a  local/config.php                   # field/wiki settings%0a  local/$Group.$Name.php             # per-page settings%0a  local/$Group.php                   # per-group settings%0a@]%0a%0aIt may seem odd that per-page settings are loaded before per-group settings. %0aHowever, 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.%0a%0aIf 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')@].%0a%0a!! [[Passwords]]%0a%0aThere 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.  %0a%0aFirst, there are five authorization levels in the PmWiki standard distribution: read, edit, attr, upload, and admin.%0a%0aWhen looking to authorize a specific level (e.g., 'edit'), PmWiki uses the first (and only the first) associated password setting it finds from:%0a%0a    per-page passwords              # set via ?action=attr on a page%0a    per-group passwords             # set via ?action=attr on `GroupAttributes%0a    default passwords               # set via $DefaultPasswords[...]%0a%0aThus page passwords override group passwords, and group passwords override site-wide (default) passwords.%0a%0aIf the above cascade doesn't produce a password setting for the required level, then PmWiki will cascade among authorization levels (set via $AuthCascade):%0a%0a->[@%0aedit %3c= read%0aupload %3c= read%0aattr %3c= edit%0a@]%0a%0aThis 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.%0a%0aThe admin password doesn't really participate in the password cascade -- the admin password simply grants access regardless of any password settings.%0a%0a!! CSS%0aThe look and feel of a wiki page is shaped initially by the [[PmWiki/SkinTemplates | page template]] file.%0aCascading style sheets (CSS) then provide the formatting.%0a%0aThe style sheet cascade works as follows (a simplified explanation)'^[[http://www.devarticles.com/c/a/Web-Style-Sheets/Learn-CSS-Introduction-to-Inheritance-Specificity-and-Cascade/|#]]^'.%0aWhere there are multiple CSS rules the one that comes last will be used%0aCSS files are thus more important the later they are included.%0aHowever inline CSS in general is considered to be the most specific and has the final say.%0aThis is what CSS for recipes should be provided in style sheet files, rather than inline, to allow webmasters to easily customise it.%0a%0aThe following list indicates the 'importance' of the CSS source, but is should be noted that the CSS source is in fact processed from the bottom up%0a# inline CSS (eg generated in the header, or from [[wiki styles]])%0a# pmwiki.css (found in the same directory as the template @@.tmpl@@ file)%0a# ''groupname''.''pagename''.css (found in @@/pub/css/@@) where pagename refers to a specific page in a specifi group named groupname%0a# ''groupname''.css (found in @@/pub/css/@@) where groupname applies to all pages in a specific group, see [[PmWiki/group customizations]]%0a# local.css (found in @@/pub/css/@@) see [[PmWiki/initial setup tasks]]
time=1251406765