Concrete5: Entwicklung mit Concrete5: Concrete's Anwendungsablauf
Zurück zu 'Coding Style Anleitung' | 
Hoch zu 'Inhaltsverzeichnis' | Vor zu 'Themen verstehen/erweitern'
Jede Anfrage im Concrete-System läuft über index.php im Webroot. Solange das System schicke URLs, ist Apaches mod_rewrite-Modul für das Rerouting der Aufrufe im Hintergrund verantwortlich. Index.php nimmt die gesamte Anfrage entgegen und sendet sie weiter an dispatcher.php aus dem Basis-Anwendungsverzeichnis. Dies geschieht, damit sich mehrere Concrete-Webseiten eine Dateiansammlung auf einem festgelegten Server teilen können. Die folgende Liste gibt Aufschluss über die Aktionen, die von dispatcher.php zum Behandeln von Anfragen ausgeführt werden:
Definieren von C5_EXECUTE
Bearbeiten define('C5_EXECUTE', true);
Mit dem Setzen dieser Konstanten wird sichergestellt, dass innerhalb von dispatcher.php agiert wird.
Startup check
Bearbeiten require(dirname(__FILE__) . '/startup/config_check.php');
Dies ist das erste Element im Ablauf. Damit wird überprüft, ob config/site.php verfügbar ist. Falls das der Fall ist, wird diese inkludiert. Falls nicht, wird eine Variable gesetzt, durch die Concrete erfährt, dass diese als nicht installiert erscheint. Das wird später verwendet, nachdem bestimmte Kernbibliotheken geladen wurden.
Laden der Basis Konfigurationsdatei
Bearbeiten require(dirname(__FILE__) . '/config/base.php');
Hier werden alle Konstanten und internen Einstellungen, die von Concrete verwendet werden, mit Pfaden geladen. Diese Datei übernimmt zudem das Inkludieren der Loader-Bibliothek, die zum Laden von Elementen von hier nach außen verwendet wird.
Aufruf von dispatcher.php sicherstellen
Bearbeiten require(dirname(__FILE__) . '/startup/file_access_check.php');
Um einen direkten Aufruf von dispatcher.php zu unterbinden, wird hier der Aufruf sichergestellt.
Laden der Datenbank
Bearbeiten Loader::database();
Concrete lädt die Datenbank (verbindet sich allerdings noch nicht) . Das geschieht durch ADODB.
Laden benötigter Bibliotheken
Bearbeiten Loader::library('object');
Loader::library('log');
Loader::library('localization');
Loader::library('request');
Loader::library('events');
Loader::library('model');
Loader::library('item_list');
Loader::library('view');
Loader::library('controller');
Loader::library('file/types');
Loader::library('block_view');
Loader::library('block_view_template');
Loader::library('block_controller');
Loader::library('attribute/view');
Loader::library('attribute/controller');
Concrete lädt nun seine eigenen Kern-Bibliotheken. In Concrete5 stellt eine Bibliothek einen Teil des Codes dar, der ohne speziell an das CMS gekoppelt zu sein, verwendet wird.
Autoload Einstellungen
Bearbeiten if (C5_ENVIRONMENT_ONLY == false) {
require(dirname(__FILE__) . '/startup/autoload.php');
}
Laden benötigter Module
Bearbeiten Loader::model('area');
Loader::model('attribute/key');
Loader::model('attribute/value');
Loader::model('attribute/category');
Loader::model('attribute/set');
Loader::model('attribute/type');
Loader::model('block');
Loader::model('block_styles');
Loader::model('file');
Loader::model('file_version');
Loader::model('block_types');
Loader::model('collection');
Loader::model('collection_version');
Loader::model('config');
Loader::model('groups');
Loader::model('package');
Loader::model('page');
Loader::model('page_theme');
Loader::model('permissions');
Loader::model('user');
Loader::model('userinfo');
Concrete-Ladevorgang beinhaltet die benötigten Modelle and Klassen, die für einen normalen Rendervorgang einer Seite benötigt werden. Modelle sind direkt an die Datenbank gebunden, obwohl es darüber hinaus momentan keine lexikalische Definition gibt.
Setup Timezone Support
Bearbeiten require(dirname(__FILE__) . '/startup/timezone.php'); // muss inkludiert werden, bevor Funktionen aufgerufen werden, die sich auf Datum Bearbeitung beziehen (php 5.3 +)
Startup Cache
Bearbeiten Loader::library('cache/abstract');
Loader::library('cache/' . CACHE_LIBRARY);
Cache::startup();
Startup Check, Installation
Bearbeiten require(dirname(__FILE__) . '/startup/magic_quotes_gpc_check.php');
Default Routen zu den unterschiedlichen Inhaltseinträgen
Bearbeiten require(dirname(__FILE__) . '/config/theme_paths.php');
Laden der Session Handler
Bearbeiten require(dirname(__FILE__) . '/startup/session.php');
Startup Check, Dekodierung
Bearbeiten require(dirname(__FILE__) . '/startup/encoding_check.php');
Dateitypen
Bearbeiten require(dirname(__FILE__) . '/config/file_types.php');
Startup Check, Konfiguration abgeschlossen
Bearbeiten require(dirname(__FILE__) . '/startup/config_check_complete.php');
Benutzerebene, Konfiguration
Bearbeiten require(dirname(__FILE__) . '/config/app.php');
Seitenebene, POST Benutzer/Anwendungen Konfiguration
Bearbeiten if (file_exists(DIR_BASE . '/config/site_post.php')) {
require(DIR_BASE . '/config/site_post.php');
}
Setzen von Debug abhängigen und aufzeichnenden Aktivitäten
Bearbeiten require(dirname(__FILE__) . '/startup/debug_logging.php');
require(dirname(__FILE__) . '/startup/tools_upgrade_check.php');
Spezielle Seiten Routen für unterschiedlichen Inhaltseinträgen (falls vorhanden)
Bearbeiten @include('config/site_theme_paths.php');
Dieser Codeblock initialisiert interne Pfade für verschieden Themen auf der Webseite. Themenpfade routen bestimmte Themen in Kernpfaden des Concrete Dateisystem. Fehlerbehandlung wird in der zweiten Inkludierung vorgenommen, weil die Datei nicht existieren könnte. (Hinweis: das Konfigurationsverzeichnis einer Webseite existiert an zwei Stellen - einmal im Anwendungsverzeichnis ./concrete und einmal im Webroot ./)
Spezielle Seiten Routen für unterschiedlichen Dateitypen (falls vorhanden)
Bearbeiten @include('config/site_file_types.php');
Paketereignisse
Bearbeiten require(dirname(__FILE__) . '/startup/packages.php');
Inkludierungscheck
Bearbeiten require(dirname(__FILE__) . '/startup/tools.php');
// Inkludierungswerkzeuge. Format: index.php?task=include_frontend&fType=TOOL&filename=test.php
Spezifische Seiten/Anwendung Ereignisse (falls definiert)
Bearbeiten if (defined('ENABLE_APPLICATION_EVENTS') && ENABLE_APPLICATION_EVENTS == true) {
@include('config/site_events.php');
}
Diese müssen vor packages.php eingebunden werden.
Benutzerbezogene Ablaufbearbeitung
Bearbeiten require(dirname(__FILE__) . '/startup/user.php');
Der obere Codeblock lädt eine Reihe von Subroutinen die im Startverzeichnis liegen
- Zuerst wird die Sitzung initialisiert.
- Als nächstes wird überprüft, ob Concrete installiert ist. Configcheckcomplete prüft die Variable, die von der am Anfang von dispatcher.php stehenden configcheck Routine gesetzt wurde. Falls Concrete keine seiner Konfigurationsdateien finden kann, sorgt configcheck_complete dafür, dass die Installationsansicht gerendert, und das Hauptprogramm verlassen wird.
- Nachdem die Konfiguration überprüft wurde, wird eine Verbindung zur Datenbank aufgebaut.
- Anschließend wird die SQL und Fehler Ausgabe eingerichtet. Dies geschieht getrennt vom logging - dadurch wird auch grundlegend bestimmt ob bestimmte Fehler in der Ausgabe, und dem ausführlichen Modus, alle SQL Anfragen mit angezeigt werden. Im Dashboard kann diese Option eingestellt werden.
- Jetzt wird die Benutzer Klasse geladen. Falls ein Benutzer eingeloggt ist, werden die uLastOnline Parameter aufgefrischt.
- Zu guter Letzt, initialisiert dieser Codeblock die “tools/” Anfragen. Werkzeuge sind statische PHP Dateien mit dem Zweck, interne Concrete Interface Funktionalität durchzuführen. Diese laufen auch durch dispatcher.php
if (C5_ENVIRONMENT_ONLY == false) {
// Herausfinden wohin es geht
$req = Request::get();
if ($req->getRequestCollectionPath() != '') {
$c = Page::getByPath($req->getRequestCollectionPath(), false);
} else {
$c = Page::getByID($req->getRequestCollectionID(), false);
}
Dieser Code löst unsere aktuelle Anfrage auf, und findet heraus, wie ein Seitenobjekt zu bekommen ist. Wird ein cID übergeben (der zu Collection/Page ID verknüpft), dann fragen wir numerisch an, indem die getById Methode der Seiten Klasse verwendet wird. Wird eine cPath Variable übergeben, wird die Seite mit Hilfe der getByPath Methode ermittelt.
if ($c->isError()) {
// falls ein Fehler beim Holen von Informationen über diese einzelne Sammlung auftratt,
// wird die Inhalt Klasse geladen
switch($c->getError()) {
case COLLECTION_NOT_FOUND:
$v = View::getInstance();
$v->render('/page_not_found');
break;
}
}
Die Seite wird daraufhin überprüft ob Sie einen Fehlercode zurückgegeben hat. Wenn dem so ist, was wirklich nur der Fall sein kann, wenn es die aufgerufene Seite nicht gibt, wird die "404" Ansicht gerendert. (Hinweis: diese Fehlerkonstanten sind in config/base.php definiert)
Check maintenance mode
Bearbeiten require(dirname(__FILE__) . '/startup/maintenance_mode_check.php');
An diesem Punkt wird überprüft, ob sich die geladene Seite im maintenance Modus befindet. Der maintenance Modus wird über das Dashboard gesteuert. Ist dieser aktiv, ist das Dashboard immer noch für Administratoren erreichbar, die Webseite ist aber nicht erreichbar.
Check externen Alias
Bearbeiten // Es wird überprüft, ob es sich um eine externen Alias
// handelt. Ist dies der Fall geht es hier weiter
include(dirname(__FILE__) . '/startup/external_link.php');
Als nächstes wird geprüft, ob die geladene Sammlung zu einem externen Link korrespondiert. Ein externer Link ist ein HTTP Link zu einer externen Resource, wie z.B. "http://www.nutzleistung.de". Durch Hinzufügen im Dashboard, sind externe Links nützlich, um externe Resourcen in die interne Navigationsstruktur einzufügen, wie z.B. die Page List und AutoNav Blöcke.
Zugriffsobjekt erhalten
Bearbeiten $cp = new Permissions($c);
// Nun, da wir das Sammlungs- und Zugriffsobjekt haben,
// überprüfen wir ob alles mit der Sammlungen und den Zugriffen OK ist
if ($cp->isError()) {
// falls ein Fehler aufgetreten ist, wird die Inhaltsklasse
// geladen und 'Seitenzugriff nicht erlaubt' ausgegeben
switch($cp->getError()) {
case COLLECTION_FORBIDDEN:
$v = View::getInstance();
$v->setCollectionObject($c);
$v->render('/page_forbidden');
break;
}
}
Falls bis hier alles geklappt hat, wird versucht eine validierte Seite anzufordern. Also wird das Seitenobjekt einem Zugriffskonstruktor übergeben, der ein Zugriffsobjekt zurückgibt. Danach wird das Zugriffsobjekt auf Fehler überprüft und im Fehlerfall davon ausgegangen, dass eine Seite aufgerufen wurde für die kein Zugriffsrecht besteht. In diesem Fall wird eine 403 Ansicht gerendert, die normalerweise identischen zur Login Ansicht ist.
Zusammenfügen der Sammlung
Bearbeiten // Sind keine Fehler aufgetreten, wird die Sammlung hier zusammengefügt,
// aber erst, nachdem die zugehörige Seitenversion geladen wurde.
// Über zwei Klassenmethoden des Sammlungsobjekts, wird bestimmt,
// welche Version man sieht.
if ($cp->canWrite() || $cp->canReadVersions()) {
$cvID = ($_REQUEST['cvID']) ? $_REQUEST['cvID'] : "RECENT";
} else {
$cvID = "ACTIVE";
}
if ($_REQUEST['ccm-disable-controls'] == true || intval($cvID) > 0) {
$v = View::getInstance();
$v->disableEditing();
$v->disableLinks();
}
In diesem Codeabschnitt wird bestimmt, ob eine bestimmte Version einer Seite geladen werden soll, und, falls dies der Fall ist, ob diese Seite editierbar ist (Editieren alter Seitenversionen ist deaktiviert.)
$vp = $c->loadVersionObject($cvID);
// gibt das $vp Object zurück, welches dann daraufhin überprüft wird
if ($vp->isError()) {
// ob ein Fehler aufgetreten ist. Dann wird die Inhaltsklasse geladen
switch($vp->getError()) {
case VERSION_NOT_RECENT:
// Ist die Sammlung nicht die aktuellste Seitenversion,
// wird das Schreiben in diese deaktiviert.
$cp->disableWrite();
break;
}
}
Versionsverwaltung wird fortgeführt, und Editierbarkeit für alte Versionen deaktiviert.
Überprüfen transferierter Formulare
Bearbeiten require(dirname(__FILE__) . '/startup/process.php');
Das ist CMS spezifische Arbeit, ähnlich dem Seiten Hinzufügen. Die process.php Datei bestimmt, ob bestimmte Aktionen auf Basis von POST und REQUEST Variablen ausgeführt werden. Process.php ist die Datei die alle CMS Abläufe überwacht, die von Concrete durchgeführt werden.
Aufzeichnen der Ansicht
Bearbeiten if (STATISTICS_TRACK_PAGE_VIEWS == true) {
$u->recordView($c);
}
Dieser Codeblock nimmt die Ansicht in einer statistischen Tabelle auf.
Rendern der Ansicht
Bearbeiten $v = View::getInstance();
$v->render($c);
}
Dieser finale Abschnitt ist für das Rendern der Ansicht zuständig. Die Rendermethode ist für das Abmelden von der Datenbank genauso verantwortlich, wie für das Ausgeben von SQL Anfragen, wenn das entsprechende Debug Level gesetzt ist.
Zurück zu 'Coding Style Anleitung' | Hoch zu 'Inhaltsverzeichnis' | Vor zu 'Themen verstehen/erweitern'