|
Englisch: |
PmWikiDe /
Wiki-Kaskaden
Administratoren, Entwickler
PmWiki nutzt eine Reihe von "Kaskaden"[1] im Zusammenhang mit den Deklarationen. Kenntnisse darüber kann nützlich sein für Jemanden, der Probleme durch Entwanzen (debugging) einkreist oder neue Rezepte schreibt. Lokale AnpassungenWenn 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 # field/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 Wenn die seitenbezogene Datei die gruppenbezogenen Einstellungen zuerst laden möchte, kann sie es mit Hilfe von PasswörterEs 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 So überschreibt das Seitenpasswort das Gruppenpasswort und das Gruppenpasswort überschreibt die site-weiten (Vor-)einstellungen. 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 erlaubt den Zugriff unabhängig von jeglichem gesetzten Passwort. CSSDas Look-and-feel einer Wikiseite wird eingangs durch die Skinvorlagen -Datei bestimmt. 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.
Originalseite auf PmWikiDe.WikiCascades - Rückverweise |