Concrete5: Entwicklung mit Concrete5: Concrete's Anwendungsablauf


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

  1. Zuerst wird die Sitzung initialisiert.
  2. 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.
  3. Nachdem die Konfiguration überprüft wurde, wird eine Verbindung zur Datenbank aufgebaut.
  4. 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.
  5. Jetzt wird die Benutzer Klasse geladen. Falls ein Benutzer eingeloggt ist, werden die uLastOnline Parameter aufgefrischt.
  6. 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.