Wiki-Kaskaden

für die Liste aller Seiten

PmWiki nutzt eine Reihe von "Kaskaden"^[1] im Zusammenhang mit den Deklarationen. Kenntnisse darüber können nützlich sein für Jemanden, der Probleme durch Entwanzen (debugging) einkreist oder neue Rezepte schreibt.

Lokale Anpassungen

Wenn pmwiki.php ausgeführt wird, initialisiert es einige Variablen und lädt dann (via include_once()) eine Sequenz von PHP-Skripten, die lokale Anpassungen ausführen können. Hier ist die Basis-Sequenz, in der die lokalen Anpassungen geladen werden:

pmwiki.php
  $FarmD/local/farmconfig.php        # farm-weite Einstellungen
  local/config.php                   # Wiki-Einstellungen
  local/$Group.$Name.php             # seitenbezogene Einstellungen
  local/$Group.php                   # gruppenbezogene Einstellungen

Es scheint eigenartig zu sein, dass die seitenbezogenen Einstellungen vor den gruppenbezogenen Einstellungen geladen werden. Jedenfalls sollten die seitenbezogenen Einstellungen mehr Gewicht haben als gruppenbezogene Einstellungen, und es ist viel leichter für die seitenbezogene Datei, die gruppenbezogene Datei am Laden zu hindern (indem $EnablePGCust = 0 gesetzt wird), als die gruppenbezogene Datei zuerst zu laden und in der seitenbezogenen Datei zu versuchen, diese Einstellungen rückgängig zu machen.

Wenn die seitenbezogene Datei die gruppenbezogenen Einstellungen zuerst laden möchte, kann sie es mit Hilfe von include_once('local/Group.php') tun.

Passwörter

Es gibt viele verschiedene Modelle für die Seitenautorisierung und PmWikis eingebaute Autorisierung versucht möglichst viele von ihnen zusammenzufassen. Im Ergebnis gibt es eine Reihe von Kaskaden im Zusammenhang mit der Autorisierung des Zugriffs auf eine Seite.

Zunächst sind da fünf Autorisierungsebenen in PmWikis Standardauslieferung: read, edit, attr, upload, und admin.

Wenn PmWiki eine bestimmte Ebene (z. B. 'edit') zu autorisieren versucht, nutzt es die erste (und nur die erste) assoziierte Passworteinstellung, die es findet, von:

    seitenbezogenen Passwörtern       # gesetzt durch ?action=attr in einer Seite
    gruppenbezogenen Passwörtern      # gesetzt durch ?action=attr in GroupAttributes
    voreingestellten Passwörtern      # gesetzt durch $DefaultPasswords[...]

So überschreibt das Seitenpasswort das Gruppenpasswort und das Gruppenpasswort überschreibt die site-weiten (Standard-)Passwörter.

Wenn die obige Kaskade keine Passworteinstellung für die erforderliche Ebene ergibt, wird PmWiki durch die Autorisierungsebenen (wie sie durch $AuthCascade gesetzt sind) kaskadieren:

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

Diese Kaskade zeigt an, dass eine Seite ohne ein ausdrückliches Passwort das erstbeste vorhandene read-Passwort benutzt. Ähnlich benutzt eine Seite ohne attr-Passwort stattdessen das edit-Passwort. Das Endergebnis dieser Kaskade ist, dass stillschweigend das erstbeste read-Passwort benutzt wird, wenn kein edit- oder upload-Password vorhanden ist, und das edit-Passwort wird benutzt, wenn kein attr-Passwort vorhanden ist.

Das admin-Passwort nimmt an dieser Kaskade nicht wirklich teil – das admin-Passwort gewährt den Zugriff unabhängig von jeglichem gesetzten Passwort.

CSS

Das Look-and-feel einer Wikiseite wird zunächst durch die Skinvorlagen-Datei bestimmt. Cascading Style Sheets (CSS) liefern dann die Formatierungen.

Die Style-Sheet-Kaskade arbeitet wie folgt (eine vereinfachte Erklärung))^[2]. Wo es mehrere CSS-Regeln gibt, wird die benutzt, die zuletzt kommt. CSS-Dateien sind also umso wichtiger, je später sie geladen werden. Allerdings werden die Inline-Styles generell als die wichtigsten angesehen und haben letztendlich das Sagen. Deshalb sollten CSS-Anweisungen für Rezepte grundsätzlich in Dateien ausgeliefert werden anstatt inline, damit Webmaster sie einfacher anpassen können.

Die folgende Liste zeigt die 'Wichtigkeit' von CSS-Quellen auf, aber es sollte angemerkt werden, dass die CSS-Quellen tatsächlich von unten nach oben abgearbeitet werden.

1. inline-CSS (z. B. im Header oder durch Wikistile erzeugt)
2. pmwiki.css (gefunden im gleichen Verzeichnis wie die Vorlagen-Datei .tmpl)
3. gruppenname.seitenname.css (gefunden in /pub/css), wobei sich seitenname auf eine bestimmte Seite in einer bestimmten Gruppe gruppenname bezieht
4. gruppenname.css (gefunden in /pub/css), wobei gruppenname auf alle Seiten in einer bestimmten Gruppe passt, siehe Individuelle Einstellungen pro Gruppe
5. local.css (gefunden in /pub/css), siehe Erste Einstellungen

für die Liste aller Seiten