Das neue Site-Configuration Modul in TYPO3 9.5

10. Dezember 2019

Seit TYPO3 9.5 gibt es nun dieses Site-Configuration Modul. Die Site-Configuration wird nicht in der Datenbank gespeichert sondern in Yaml Dateien. Ein großer Vorteil wie ich finde, da man diese Konfiguration(en) jetzt auch gut versionieren und in Teams verwenden kann. In dieser Datei findet TYPO3 die benötigten Informationen zu Domain, Einstiegspunkt im Seitenbaum, Anweisungen wie TYPO3 mit Fehlern wie 404 umgeht, verwendete Sprachen und vieles mehr.

Wenn man mit einer TYPO3 Instanz mehrere Seiten (Multi Domain Installation) pflegt, wir für jede Root-Seite eine Konfigurationsdatei angelegt. Die Konfigurationsdatei liegt dann immer in config/sites/IDENTIFIER/config.yaml. Den IDENTIFIER könnt Ihr im BE auch ändern.

Der config Ordner liegt abhängig davon ob ihr eine Composer basierte Installation habt an unterschiedlichen Stellen.

Für Composer basierte Installationen: im Projekt-Root, dort wo auch die composer.json Datei liegt, für Nicht-Composer Installationen: im typo3conf Ordner

Die meisten Sachen in dieser Yaml Datei erklären sich von selbst und sind durch das Backend-Modul prima zu konfigurieren. Für einfache Seiten muss man gar nicht mehr sagen. Wer sich gerne VideoTutorials anschaut, kann sich hier einen guten Einstieg verschaffen: Feature Demo – Site Module .

Spannend wird es nun bei MultiDomain-Installationen und verschiedenen Umgebungen.

Beipiel:

  • Eine TYPO3 Instanz, 2 Domains (2 RootSeiten im TYPO3), eine lokale Entwicklungsumgebung, einen Staging Server, einen Live Server

Das Problem:

  • man kann in der config.yaml nicht mehr einfach
    base: 'https://%env(SERVER_NAME)%/'

    setzen

  • je Domain/Seite eine Konfigurationsdatei, die nicht jedesmal angepasst werden soll, wenn man die Installation irgendwohin schiebt.
      • Lokal -> Staging
      • Lokal -> Live
      • Staging -> Live

Die Lösung:

  • baseVariants und eine Environment Variable für einen Domain Suffix

Bei dieser Lösung setzt ihr eine Environment Variable in den jeweiligen Umgebungen. Wie bleibt euch überlassen. Ein Weg wäre über die .htaccess. Kann aber auch wieder Probleme machen wenn diese mit zum Projekt gehören soll und in den verschiedenen Umgebungen gebraucht wird.

Ein anderer Weg, so lösen wir das momentan, ist bei Composer Installationen relativ einfach möglich. Wir nutzen den Dotenv Connector von vlucas/phpdotenv , installiert mit dem Composer. Noch ein kurzer Aufruf in der AdditionalConfiguration.php und wir können beliebige Environment Variablen im TYPO3 abfragen.

// Load environment from .env file
$dotenvPath = __DIR__ . '/path/to/env-folder/';
if (is_file($dotenvPath . '.env')) {
  $loader = \Dotenv\Dotenv::create($dotenvPath);
  $loader->load();
}

Wichtig dabei, die .env Datei sollte natürlich außerhalb vom Webroot liegen. Unter Umständen hat man dort sensible Daten (Zugangsdaten kann man dort auch prima ablegen) drin. In dieser .env Datei definieren wir unsere Environment Variable „DOMAIN_SUFFIX“. In jeder Umgebung (Lokal, Staging, Live) haben wir eine solche .env Datei liegen. Diese wird nicht mit versioniert (Stichwort .gitignore Datei) und muss einmal überall angelegt werden. Für lokal haben wir diese dann mit „.lan“ befüllt. Auf Staging beispielsweise mit „.staging.devdomain.de“ und auf Live bleibt sie einfach leer oder ist gar nicht da.

In der config.yaml kommen nun die baseVariants‚ zum Einsatz

base: 'https://livedomain-1.de/'

baseVariants:
  -
    base: 'https://livedomain-1.de%env(DOMAIN_SUFFIX)%/'
    condition: 'getenv("DOMAIN_SUFFIX")'

und für die zweite Seite/config.yaml

base: 'https://livedomain-2.de/'

baseVariants:
  -
    base: 'https://livedomain-2.de%env(DOMAIN_SUFFIX)%/'
    condition: 'getenv("DOMAIN_SUFFIX")'

Die Standard base kennt keine Condition, nur in den baseVariants kann man diese setzen. Die braucht man auch, da der Parser in dem Fall wenn die Environment Variable nicht gesetzt ist, einfach den String %env(DOMAIN_SUFFIX)% in die base schreibt. Was wir natürlich nicht wollen.

Url-Umschreibung in der Site-Config

Ein weiteres spannendes Thema ist die Url-Umschreibung für Extensions. Das werde ich ggf. auch noch mal in einem Beitrag erläutern.
Wer nicht warten will, dem wird das hier schon gut erklärt: RoutingEnhancers. Das Beispiel mit News wird den meisten sicherlich schon reichen. Hiervon kann man die Konfiguration prima auf andere Extensions abbilden.

Ähnliche Artikel:

Meta-Daten



Auch mal Kommentieren:

Kommentar