Zielgruppe EntwicklungVersion: GSB10.1Subsite mit eigener Domain

Grundlegender Ansatz

Die Erstellung von Subsites ist so konzipiert, dass die Konfiguration und Programmierung weitestgehend identisch zu der eines normalen Mandanten ist.

Die Subsites basieren auf den beiden folgenden Ansätzen:

• Eine Subsite ist immer Teil eines normalen Mandanten.
• Es gibt neue, Subsites spezifische _config Ordner
• Jede Subsite hat ihren eigenen, eindeutigen Namen
• Jede Subsite hat ihren eigenen, eindeutigen Ordnerbaum innerhalb der Ablagestruktur. Hierbei gilt:
  • Der Ordnerbaum muss direkt unterhalb der Mandanten beginnen
  • Der Ordnername muss identisch zum Namen der Subsite sein.

Die Idee bei der Konfiguration ist es nun, eine Subsite genauso zu konfigurieren, wie man ansonsten einen neuen, zusätzlichen Mandanten konfigurieren würde.

Ordnerstruktur und Konfigurationsordner

Die Konfigurationsordner einer Subsite sind vom Aufbau und den Inhalten identisch zu normalen Konfigurationsordnern. Sie erhalten nur eine zusätzliche Auszeichnung welcher Subsite sie zugehörig sind. Eine Subsite kann immer nur Konfigurationen aus ihren oder den allgemeinen Konfigurationsordnern lesen.

Hierbei gilt:

• _config

• Allgemeiner Konfigurationsordner

• _config_<Name der Subsite>

• Spezieller Konfigurationsordner für eine eine Subsite

Abbildung 1: Exemplarische Konfiguration von Subsite Ordnern

Für die obige Konfiguration würden, wenn für die Subsite SUBSITE1 unter

/MANDANT/SharedContent/Pressemitteilungen

ein Dokument angezeigt werden sollte, die folgenden Konfigurationsordner genutzt werden:

• /MANDANT/SharedContent/_config_SUBSITE1
• /MANDANT/_config_SUBSITE1
• /MANDANT/_config

Die Konfigurationsdokumente der Subsite werden ausgehend vom Ordner in dem das darzustellende Dokument abgelegt ist, durchsucht um möglichst passende Konfigurationsdokumente zu finden. Hierbei wird zunächst die Ordnerhierarchie nach Subsite spezifischen Konfigurationsordnern und –dokumente durchsucht. Kann kein Subsite spezifisches Konfigurationsdokument gefunden werden, so wird das entsprechende Dokument des Mandanten verwendet.

Es ist auch möglich unterhalb von

/MANDANT/SiteGlobals

Subsite spezifische Konfigurationsordner gemäß der oben skizzierten Nomenklatur anzulegen.

Subsite Konfigurationsdokumente

Für eine minimale Subsite-Konfiguration werden neben dem eigentlichen Subsite-Content einige wenige Konfigurationsdokumente benötigt:

• /MANDANT/_config_SUBSITE/FolderRedirectPage definiert die Startseite der Subsite bei Direktaufruf der Subsite-Domain
• /MANDANT/SiteGlobals/_config_SUBSITE/ServerFQHN_preview enthält den vollqualifizierten Servernamen der Subsite-Previewadresse
• /MANDANT/SiteGlobals/_config_SUBSITE/ServerFQHN_preview enthält den vollqualifizierten Servernamen der Subsite-Liveadresse

Darüber hinausgehende Konfigurationsdokumente können bei Bedarf angelegt werden. Als Orientierung können die Konfigurationsdokumente des der Subsite zugehörigen GSB-Mandanten herangezogen werden. Die Semantik eines Konfigurationsdokumentes ist unabhängig von der Verwendung innerhalb einer Subsite bzw. dem zugehörigen GSB-Mandanten.

Konfiguration der Suche

Die Suche innerhalb von Subsites ist ein besonderer Fall, da hier pro Subsite sowohl der Subsite spezifischer Content als auch der SharedContent durchsucht werden soll. Content aus anderen Subsites dürfen nicht berücksichtigt werden.

Dies wird erreicht indem pro Subsite eine eigenständige Suche konfiguriert wird, die eine zusätzliche Einschränkung des Suchpfades in der zugehörigen Suchaction beinhaltet.

Nachfolgend wird die Konfiguration exemplarisch beschrieben.

Es wird angelegt pro Subsite und Suche:

• Ein Suchformularintegrator (HTML-Formularintegrator)

• der verweist auf das folgende Suchformular

• Ein Suchformular (HTML_Formular)

• Die Suchformulare können für alle Subsites identisch sein, bis auf die Subsite spezifische Suchaction.

Die Einschränkung der Suche wird in der Suchaction des Formulars vorgenommen. In der Suchaction sind alle zu berücksichtigenden Suchpfade innerhalb des GSB-Mandanten aufzuführen. Hierbei handelt es sich üblicherweise um die folgenden Ordner:

• SharedDocs enthält alle übergreifende Dokumente die in allen Subsites und Auftritt des Hauptmandanten verwendet werden
• Subsite-Wurzelordner enthält alle Subsite spezifischen Dokumente

Darüber hinaus können je nach Ablagestruktur innerhalb des GSB-Mandanten weitere Ordner mit hinzukonfiguriert werden.

Die Sucheinschränkung wird in der Action-Property additionalQuery definiert, wobei die zu berücksichtigenden Suchpfade mit einer logischen ODER-Verknüpfung miteinander verknüpft werden. Die Sucheinschränkung über mehrere Pfade hat somit den folgenden Aufbau:

(path_: /MANDANT/PATH1/* OR path_: /MANDANT/PATH2/*)

Anpassungen Apache

Subsites werden unter einem eigenständigen Domainnamen angesprochen, verfügen somit über eine dedizierte VirtualHost-Definition innerhalb des Apache-Webservers. Die VirtualHost-Definition der Subsite kann einfach durch Kopie und Anpassung der Apache-Build-Properties des Hauptmandanten eingerichtet werden. Hierzu wird bspw. die Datei MANDANT_basis/config/Apache/VirtualHostsLive/MANDANT.properties kopiert und unter einem Subsite spezifischen Dateinamen im selben Verzeichnis abgelegt. Anschließend werden die Build-Properties auf die Subsite spezfischen Werte angepasst. Die Properties server_name und virtual_host_name werden auf den Domainnamen der Subsite geändert, die Property virtual_host_subsite enthält den Namen der Subsite innerhalb des GSB-Mandanten und entspricht dem Ordnernamen der Subsite im Content-Repository. Die folgende Definition skizziert dies exemplarisch anhand der Subsite SUBSITE1 des Mandanten standardlsg:

mandant=standardlsg isSslEnabled=false server_name=subsite1.standardlsg.domain.example virtual_host_name=subsite1.standardlsg.domain.example virtual_host_subsite=SUBSITE1 virtual_host_port=80 virtual_host_cae=true

Die Definition der Build-Property virtual_host_subsite steuert, dass es sich bei dem zugehörigen VirtualHost um eine Subsite handelt, so dass beim Deployment des Apache-Webservers die Definition des VirtualHosts entsprechend erweitert wird. Die GSB-Standarddefinitionen des VirtualHosts werden um das Setzen einer Umgebungsvariablen SUBSITE erweitert. Diese wird an den zugeordneten Tomcat-Server weitergereicht und ermöglicht so Zuordnung und Ermittlung der jeweiligen Subsite. Der folgende Auszug der VirtualHost-Definition skizziert dies exemplarisch für die Subsite SUBSITE1:

RewriteRule ^(.+) $1 [E=SUBSITE:SUBSITE1] # /favicon.ico, robots.txt # aus Static-Html-Bereich ausliefern, NICHT an Tomcat weiterleiten RewriteCond %{REQUEST_FILENAME} ^/favicon.ico$|^/robots.txt$ RewriteRule ^(.+) /space/gsb/active/Apache2/static/standardlsg$1 [E=no-jk:no-jk,L]

Eine entsprechende VirtualHost-Definition muss für jede Subsite des Mandanten konfiguriert werden. Dieses kann durch Anlegen der benötigten Subsite spezifischen BuildProperty-Dateien und anschließendem Deployment des Apache-Webservers umgesetzt werden.

Routing von Subsite-Zugriffen

Subsite-Inhalte und Mandanten-Inhalte werden innerhalb eines GSB-Mandanten verwaltet. So können prinzipiell alle Inhalte des Mandanten unter einer zugehörigen Domain (Subsite oder Mandant) abgerufen werden, was im Fall von Shared-Content auch so gewollt ist.

Wenn verhindert werden soll, dass Subsite-Inhalte von einer anderen Domain abgerufen werden können, so kann dies über eine Erweiterung der Apache-Webserver Rewrite-Rules verhindert werden. Die Definition von Mandanten spezifischen Regeln erfolgt in der Datei config/Apache/VirtualHosts(Live|Preview)/<MANDANT>_custom_config.txt. Das folgende Beispiel würde alle Zugriffe auf Content der SUBSITE1 auf die eigentliche Domain der Subsite (SUBSITE1_DOMAIN) umleiten.

# Umlenkung der Zugriffe auf Subsite-Content auf SUBSITE_DOMAIN RewriteCond %{REQUEST_FILENAME} ^/SUBSITE1 RewriteRule ^(.*) http://SUBSITE1_DOMAIN$1 [R,L]

Anpassungen Editor

Der Editor bleibt weitestgehend unverändert. Es müssen nur pro Subsite eigene Editorgruppen erstellt werden.

Eine der wichtigsten Änderungen bei der Editorkonfiguration ist, dass der Preview nicht mehr direkt auf den Port des Tomcat gehen darf, sondern immer über den Virtual Host der Subsite gehen muss.

Der Eintrag für die im Beispiel verwendete Subsite-Konfiguration der Subsite SUBSITE1 wäre dann unter Verwendung des Preview-Hostnames subsite1.standardlsg.domain.example wie folgt:

<WebContext context="bund" host="subsite1.standardlsg.domain.example" port="80"> <WebExtension name="preview"/> </WebContext> <WebContext context="cae" host="subsite1.standardlsg.domain.example" loginPort="8443" port="8001"> <WebExtension name="query"/> <WebExtension name="difference"/> </WebContext>

nach oben