Webserver Integration fedsSite Macro

Das fedsSite-Apache-Macro wird vom Apache-Control-Modul im IES-Webnode bereit gestellt und ist dort unter den Pfad IES_WEBNODE_HOME/data/ies-webnode/data/apache2/macros/fedsSite.conf erreichbar. In der Regeln wird das Verzeichnis IES_WEBNODE_HOME/data/ies-webnode/data/apache2/ in dem Apache-Konfigurationsverzeichnis verlinkt und ist dann unter einem Pfad wie /etc/apache/ies.conf.d/ erreichbar. Um die IES-Spezifischen Macros und VHost-Konfigurationen zu laden wird die Hauptkonfiguration des Apache (z.B. /etc/apache2/apache2.conf) durch folgende Konfiguration ergänzt.

# --managed-by-ies-webnode-updater
<IfModule macro_module>
IncludeOptional ies.conf.d/macros/*.conf
IncludeOptional ies.conf.d/sites/*.conf
</IfModule>
# --/managed-by-ies-webnode-updater

Damit wird das Macro dem Apache bekannt gemacht.

Das Macro fedsSite wird verwendet, um FEDS basierte Webseiten zu konfigurieren. Dafür sind auf dem Webserver folgende Komponenten bereit zu stellen.

Ein Frontend-Projekt, das korrespondierend zu dem serverseitigen die frontendseitige Logik für die Webseite bereit stellt.
Ein FEDS-Projekt, das korrespondierend zu dem Frontend die serverseitige Logik für die Webseite bereit stellt.
Die publizierten Resourcen, die das CMS bereit gestellt hat. Dies sind die Inhalte der Redakteure und Administratoren, die für bestimmte Publikationsbereiche freigegeben sind.

Diese Komponenten werden über das fedsSite-Macro zusammegeführt. Dies erfolgt immer pro virtuellem Host.

Die Virtual-Host Konfigurationen werden unter /etc/apache/ies.conf.d/sites abgelegt und müssen mit .conf enden. Ein Beispiel hierfür ist:

/etc/apache/ies.conf.d/sites/www.domain.de.conf

# fedsSite $configName $baseDir $serverName $sitekitToken
Use fedsSite www.domain.de "/var/www/domain.de/www" www.domain.de Djfjhgr4jfdu

Der $configName ist relevant für Kundenspezifische Includes. In diesem Fall sind folgenden Konfigurationen möglich:

includes/www.domain.de.common.conf

Wird vor allen anderen Konfigurationen eingelesen

includes/www.domain.de.extra.conf

Wird anch deen recommendation-, includes/ssl.conf- und den allgemeinen includes/extra.conf eingelesen

includes/www.domain.de.extra.conf

Wird anch deen recommendation-, includes/ssl.conf- und den allgemeinen includes/extra.conf eingelesen

includes/www.domain.de.directory.conf

Wird inner halb der <Directory>-Direktive für den Document-Root und nach includes/directory.conf eingelesen

includes/www.domain.de.overwrite.conf

Wird ganz zum Schluss nach allen Konfigurationen des Macros eingelesen.

Der $baseDir definert da Basis-Verzeichnis für den Publikationsbereich

Der $serverName gibt an, unter welcher Domain die Webseite erreicht werden soll. Server-Aliases können in includes/www.domain.de.common.conf definiert werden.

Der $sitekitToken erlaubt die Aktivierung von Debugging-Werkzeugen in Produktiv-Systemen.

Aus den Angaben werden im Macro folgende Variablen definiert:

Define APP_PUBLIC $baseDir/app/public
Define FRONTEND_PUBLIC $baseDir/frontend/public
Define MEDIA_PUBLIC $baseDir/resources/media/public
Define RESOURCE_ROOT $baseDir/resources

Diese Konfiguration basiert auf einem definierten Verzeichnis-Layout unterhalb von /var/www/domain.de/www (oder z.B. auch /var/www/domain.de/preview, je nach Publikationsbereich).

/var/www/domain.de
  + www
    + app -> IES_WEBNODE_HOME/feds/my-project-feds
      + public 
    + frontend -> IES_WEBNODE_HOME/feds/my-project-frontend
      + public
    + resources
      + media
        + public

app/ : In diesem Verzeichnis liegt die Serverseitige Applikationslogik. Diese wird vom FEDS-Projekt bereit gestellt. Das FEDS-Projekt liegt unterhalb von IES_WEBNODE_HOME/feds. Über den Link wird definiert welches FEDS-Projekt verwendet werden soll. Es muss immer ein public/-Verzeichnis enthalten.
frontend/ : In diesem Verzeichnis liegen alle Frontend-Dateien. Diese wird vom Frontend-Projekt bereit gestellt. Das Frontend-Projekt liegt unterhalb von IES_WEBNODE_HOME/frontend. Über den Link wird definiert welches Frontend-Projekt verwendet werden soll. Es muss immer ein public/-Verzeichnis enthalten.
resources/ : In diesem Verzeichnis liegen alle vom CMS publizierten Inhalte. Öffentlich zugängliche Medien, die direkt vom Webserver ausgeliefet werden dürfen liegen unterhalb von resources/media/public

Durch das zusammenführen der drei Bereiche FEDS, Frontend und RESOURCES ergeben sich im Prinzip drei public-Verzeichnisse, die gemeinsam den Dokument-Root bilden. Da es aber nur einen Dokument-Root geben kannt wird dies wie folgt gelöst.

Die Lösung hierfür ist ein Verzeichnis als Document-Root zu definieren und die zwei übrigen über rewrite-Regeln einzubinden.

APP_PUBLIC wird als DOCUMENT_ROOT festgelegt.

DocumentRoot ${APP_PUBLIC}

Dann folgt eine rewrite-Regeln für das Medien-Verzeichnis:

RewriteCond ${MEDIA_PUBLIC}%{REQUEST_URI} -f
RewriteRule ^ ${MEDIA_PUBLIC}%{REQUEST_URI} [L]

Mit dieser Regel wird geprüft, ob die Datei ${MEDIA_PUBLIC}%{REQUEST_URI} existiert. REQUEST_URI ist der Pfad der angefragten Url. Z.B. /service/illu.jpg. Es wird nun geprüft ob die Datei /var/www/domain.de/www/resources/media/public/service/illu.jpg existiert. Ist dies der Fall wird sie zurück geliefert.

Ist dies nicht der Fall, wird die nächste Regeln geprüft:

RewriteCond ${FRONTEND_PUBLIC}%{REQUEST_URI} -f
RewriteRule ^ ${FRONTEND_PUBLIC}%{REQUEST_URI} [L]

Mit dieser Regel wird geprüft, ob die Datei ${FRONTEND_PUBLIC}%{REQUEST_URI} existiert. Z.B. wird mit /js/main.js geprüft, ob die Datei /var/www/domain.de/www/frontend/js/main.js existiert. Ist dies der Fall wird sie zurück geliefert.

Ist dies nicht der Fall, wird die nächste Regeln geprüft:

RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteRule ^ /index.php [L]

Mit dieser Regel wird geprüft, ob die Datei ${DOCUMENT_ROOT}%{REQUEST_URI} nicht existiert. Z.B. wird mit /service/abfall/index.php geprüft ob die Datei /var/www/domain.de/www/app/public/service/abfall/index.php nicht existiert. Dies ist hier auch nicht der Fall, da in der Regeln in dem app/public-Verzeichnis nur eine index.php liegt, die als Front-Controller für die Applikation dient. Die Regel trifft also hier zu und der Request wird an den Front-Controller der Applikation weitergeleitet. Ab hier wird über PHP-Logik jeder Request weiterverarbeitet, für die in den Verzeichnissen resources/media/public, frontend/public und app/public die entsprechende Datei nicht gefunden werden konnte.

Sollte in dem app/public die angefrage Datei liegen, greift die Regel nicht und der Apache würde sie ausliefert, das app/public als Document-Root definiert ist.

Daraus ergibt sich eine Art virtueller Dokument-Root aus den drei genannten public-Verzeichnissen, bei der noch folgende Überschreibungs-Regeln gelten:

Da das resources/media/public-Verzeichnis zuerst geprüft wird, ist das CMS in der Lage die Resoucen von frontend/public und app/public zu überschreiben.

Da das frontend/public-Verzeichnis als zweites geprüft wird, überschreibt das frontend/public-Verzeichnis Dateien im app/public-Verzeichnis.

Webserver-Seite Webserver Integration fedsSite Macro