Erinnern Sie sich noch an die Zeiten, als Sie sich durch sys_template Datensätze wühlen, TypoScript manuell importieren und mit mehreren @import Anweisungen jonglieren mussten? Mit TYPO3 v13 hat das Kernteam Site Sets eingeführt, ein neues Konzept, das die Konfiguration auf Site-Ebene vereinheitlichen und modernisieren soll.
Wenn Sie Redakteur oder Integrator/Entwickler sind, werden Sie begeistert sein, wie Site Sets die Einrichtung vereinfachen, das Abhängigkeitsmanagement verbessern und saubere, besser wartbare TYPO3 Projekte schaffen.
In diesem Artikel werden wir die Grundlagen von Site Sets untersuchen, wie sie hinter den Kulissen funktionieren und warum sie mehr sind als nur eine Möglichkeit, TypoScript einzubinden.
Wir werden auch Beispiele für jeden Schritt liefern: von der Erstellung eines benutzerdefinierten Sets, der Definition Ihrer Einstellungen und dem automatischen Laden von TypoScript bis hin zur abschließenden Konfiguration mit minimalem Datenbank-Wirrwarr.
Site-Sets sind in TYPO3 v13 LTS verfügbar und wurden so entwickelt, dass sie mit bestehenden Konfigurationsansätzen koexistieren, sodass Teams sie schrittweise während der Upgrades von früheren TYPO3 LTS-Versionen übernehmen können.
Was sind Site Sets?
Site Sets sind zusammensetzbare Teile der Konfiguration, die in TYPO3 v13 (ab Version 13.1) eingeführt wurden. Sie kapseln verschiedene Teile der Konfiguration einer Site, TYPOScript, TSconfig, Einstellungsdefinitionen, referenzfähige Inhaltsblöcke und mehr, in einer einzigen logischen Einheit.
Anstatt die Konfigurationen über statische Includes, ext_localconf.php oder sys_template-Datensätze zu verstreuen, können Sie mit Site Sets alles ordentlich bündeln:
- Sie können diese Konfigurationen ganz einfach auf mehrere TYPO3 Sites anwenden.
- Wiederverwendung der gleichen Sets in verschiedenen Projekten oder verschiedenen Untergruppen eines einzelnen Projekts.
- Abhängigkeiten werden automatisch gehandhabt, so dass Sie mehrere Site Sets übereinander legen können, ohne sich Gedanken über Konflikte bei der Ladereihenfolge zu machen.
Was Site-Sets sind und was sie nicht sind
- Sind: Site-spezifische Konfigurationsbündel, die verwandtes TypoScript, TSconfig und Einstellungen gruppieren.
- Sind nicht: Ein Ersatz für TYPO3 Extensions, TYPO3 Templates oder Geschäftslogik auf Anwendungsebene.
- Sind optional: Site-Sets sind in TYPO3 v13 nicht obligatorisch und können schrittweise zusammen mit bestehenden Konfigurationsansätzen übernommen werden.
Warum es Zeit ist, veraltete Methoden abzulegen
In früheren TYPO3 Versionen bestand das Hinzufügen neuer Funktionen oft aus mehreren Schritten: Erstellen von statischen TypoScript-Includes, Verweisen auf diese in deinem Seiten- oder site-Template oder manuelles Aufrufen von @import in TypoScript-Dateien.
Dieser Ansatz konnte unübersichtlich werden, wenn mehrere Extensions beteiligt waren, was zu Verwirrung bei der Lade-Reihenfolge und Duplikationen führte.
Mit Site Sets:
- Keine statischen TypoScript mehr:
Die klassische Methode, TypoScript in sys_template Datensätzen zu speichern, kann in vielen gängigen Szenarien vermieden werden, da die Konfiguration nun in einer strukturierten, site-spezifischen Weise geliefert werden kann. - Kein manuelles @import mehr:
Die Lade-Reihenfolge kann durch Site Set-Abhängigkeiten gehandhabt werden, wodurch der Bedarf entfällt, @import Anweisungen manuell zu verwalten. - Kein globales TSconfig mehr:
Page TSconfig kann nun pro site geliefert werden, wodurch Multi-Site-Setups leichter verwaltet werden können, ohne auf globale Konfigurationen angewiesen zu sein.
1. Sauberere Konfiguration
Die Zeiten, in denen TypoScript in sys_template Datensätzen gespeichert wurde und mit @import Komplexitäten zu kämpfen war, sind vorbei. Site Sets vereinheitlichen alles in gut definierten Verzeichnissen.
2. Weniger Datenbank-Chaos
Einstellungen, die früher an mehreren Stellen gespeichert wurden, sind nun in dateibasierten YAML-Konfigurationen zusammengefasst, was die Versionskontrolle erleichtert.
3. Automatische Reihenfolge & Deduplication
Wenn mehrere Sets dasselbe TypoScript-Snippet benötigen, werden Abhängigkeiten von TYPO3 intelligent geschichtet, ohne Konflikte oder doppelte Code-Blöcke.
Was TYPO3 garantiert und was nicht
- Garantiert: Deklarierte Site Set-Abhängigkeiten werden in einer definierten Reihenfolge geladen.
- Nicht garantiert: TYPO3 löst keine semantischen oder logischen Konflikte zwischen Konfigurationen.
- Wichtig: Deduplication bezieht sich auf das Laden von Abhängigkeiten, nicht auf Geschäftslogik oder sich überschneidende TypoScript-Definitionen.
4. Editor-freundlich
Ein neuer Site Settings Editor in TYPO3 (eingeführt mit Version 13.3) ermöglicht es Editoren, Einstellungen über das Backend anzupassen, wodurch die Notwendigkeit entfällt, in YAML-Dateien oder die Datenbank einzutauchen.
# EXT:your_extension/Configuration/Sets/YourSet/config.yaml
name: your-vendor/your-set
label: Your Set
# Provide references to other sets you want to include
dependencies:
- namespace/teaser
- namespace/slider
- namespace/myelement
- name: Ein eindeutiger Bezeichner für Ihr Set.
- Bezeichnung: Der von Menschen lesbare Name für Ihr Set.
- Abhängigkeiten: Andere Sets, von denen Ihr Set abhängt. TYPO3 lädt diese zuerst, um sicherzustellen, dass die gesamte Konfiguration in der richtigen Reihenfolge verfügbar ist.
2. settings.definitions.yaml - Definieren von editierbaren Einstellungen
Wenn Ihr Set vom Benutzer editierbare Einstellungen enthalten muss (z. B. die Standardanzahl der Elemente in einem Karussell), können Sie diese in settings.definitions.yaml deklarieren.
# EXT:your_extension/Configuration/Sets/YourSet/settings.definitions.yaml
settings:
foo.bar.baz:
label: 'Your example set settings'
description: 'You need to add description'
type: int
default: 5
3. settings.yaml - Konfigurieren von Abhängigkeiten oder Subsets
Wenn Ihr Set von anderen Sets abhängt oder Sie deren Standardeinstellungen überschreiben möchten, legen Sie diese Überschreibungen in settings.yaml ab.
# EXT:your_extension/Configuration/Sets/YourSet/settings.yaml
styles:
content:
defaultHeaderType: 1
Wenn Sie die Einstellungen auf diese Weise organisieren, bleibt Ihr Set flexibel. Andere Erweiterungen oder Projekte können Ihr Set später übernehmen, ohne alles an mehreren Stellen neu definieren zu müssen.
Was NICHT in ein Site Set aufgenommen werden sollte
- Temporäre Überschreibungen, die für kurzfristige Änderungen vorgesehen sind
- Seiten-spezifische oder einmalige Projekt-Hacks
- Experimentelle oder instabile Konfigurationen, die sich häufig ändern können
# EXT:your_extension/Configuration/Sets/YourSet/config.yaml
name: your-vendor/your-set
label: 'Your Set'
dependencies:
- namespace/teaser
- namespace/myelement
- name: Identifiziert Ihr Set eindeutig
- etikett: Anzeige-Name im TYPO3 Backend
- abhängigkeiten: Sets, die zuerst geladen werden müssen
# EXT:your_extension/Configuration/Sets/YourSet/settings.definitions.yaml
settings:
yourVendor.yourSet.maxSliderItems:
label: 'Maximum Slider Items'
description: 'Sets how many items can appear in the slider'
type: int
default: 5
yourVendor.yourSet.enableAdvancedMode:
label: 'Enable Advanced Mode'
description: 'Toggles additional features for power users'
type: bool
default: false
# EXT:your_extension/Configuration/Sets/YourSet/settings.yaml
yourVendor.yourSet.maxSliderItems: 3
yourVendor.yourSet.enableAdvancedMode: true
# EXT:your_extension/Configuration/Sets/YourSet/setup.typoscript
page = PAGE
page.10 = TEXT
page.10.value = This is loaded via My Site Set
# EXT:your_extension/Configuration/Sets/YourSet/page.tsconfig
TCEFORM.tt_content {
imageorient.disabled = 1
}
# config/sites/your-site/config.yaml
base: 'https://your-domain.com/'
rootPageId: 1
dependencies:
- your-vendor/your-set
Kein statisches Einschließen von TypoScript, @import, Page TSconfig mehr
TypoScript Abhängigkeiten können nun über Site Set-Abhängigkeiten eingebunden werden, was eine strukturierte Alternative zu veralteten Ansätzen wie static_file_include oder manuellen @impor Anweisungen bietet. Die Konfiguration wird auf site-Ebene aufgelöst, wodurch der Bedarf entfällt, die Einschluss-Reihenfolge manuell über Templates oder Extensions zu verwalten.
Automatisches Laden von TypoScript
Wenn Sie die Dateien setup.typoscript oder constants.typoscript im selben Verzeichnis wie config.yaml ablegen, werden sie von TYPO3 automatisch geladen. Dies bedeutet:
EXT:your_extension/Configuration/Sets/YourSet/
│ ├─ config.yaml
│ ├─ setup.typoscript # Auto-loaded as TypoScript Setup
│ ├─ constants.typoscript # Auto-loaded as TypoScript Constants
│ └─ page.tsconfig # Auto-loaded as Page TSconfig
Durch die Verwendung dieser Struktur kann TypoScript bereitgestellt werden, ohne auf manuelle @import Anweisungen oder die Option „Static TypoScript einbinden“ in sys_template Datensätzen angewiesen zu sein. Der Einschluss wird als Teil der Site Set Konfiguration auf site-Ebene behandelt.
Automatische Seite TSconfig
Ähnlich wie TypoScript wird Page TSconfig auf site-Ebene angewendet. Durch das Platzieren einer page.tsconfig Datei neben deiner config.yaml erben alle Seiten, die zu dieser site gehören, diese TSconfig-Einstellungen.
Dies ermöglicht eine fein abgestufte Kontrolle auf site-Ebene und reduziert den Bedarf an globalem TSconfig-Einschluss oder manueller Registrierung in ext_localconf.php.
Neues Backend-Modul für Website-Einstellungen in TYPO3 v13.3
Mit TYPO3 v13.3 wurde ein neues Modul für den Site Settings Editor eingeführt. Redakteure und Integratoren können nun die Einstellungen pro Site direkt aus dem TYPO3 Backend verwalten, anstatt YAML Dateien manuell zu bearbeiten.
- Zentralisierte Verwaltung: Alle Site-spezifischen Einstellungen sind unter "Site Management > Settings" zugänglich.
- Kategorie Organisation: Einstellungen können in Kategorien gruppiert werden, die in settings.definitions.yaml deklariert werden.
- Minimaler Change Footprint: Es werden nur geänderte Werte gespeichert, so dass Ihre YAML Konfigurationen sauber bleiben.
Wenn Sie z.B. ein benutzerdefiniertes Set mit der folgenden settings.definitions.yaml haben:
# EXT:my_extension/Configuration/Sets/MySet/settings.definitions.yaml
categories:
myCategory:
label: 'My Category'
settings:
my.example.setting:
label: 'My example setting'
category: myCategory
type: string
default: ''
my.seoRelevantSetting:
label: 'My SEO relevant setting'
category: seo
type: int
default: 5
Im Editor für die Website-Einstellungen finden Sie einen neuen Abschnitt mit der Bezeichnung "Meine Kategorie", in dem Sie den Standardwert von my.example.setting außer Kraft setzen können.
Verantwortungsaufteilung: Entwickler vs. Editor
- Entwickler: Definiert das Einstellungs-Schema, Datentypen, Standardwerte und Kategorien in settings.definitions.yaml.
- Editor: Überschreibt erlaubte Werte über den Site Settings Editor im TYPO3-Backend.
- Speicherung: Definitionen leben in YAML-Dateien, während überschreibene Werte separat gespeichert und nur bei Änderungen beibehalten werden.
Erweiterte Anwendungsfälle
Extensions im Stil eines Frameworks
Eine Extension kann mit mehreren Sets (z. B. "basic", "pro", "enterprise") geliefert werden, die jeweils unterschiedliche Konfigurationen aufweisen. Site-Administratoren wählen aus, welches Set der Komplexität ihrer Site entspricht.
Konsistenz für mehrere Sites
Wenn Sie mehrere Sites mit gemeinsamen Funktionen betreiben, können Sie sicherstellen, dass sie alle dasselbe Basisset erben, während Sie site-spezifische Anpassungen in separaten settings.yaml oder sogar über den Site Settings Editor vornehmen.
Schrittweise Migration
Bei bestehenden TYPO3 Installationen können Sie ältere TypoScript-Sets nach und nach migrieren. Beginnen Sie mit einem einzigen Set, verschieben Sie Ihre bestehenden @import oder statischen Includes in setup.typoscript und constants.typoscript und entfernen Sie alte Referenzen aus sys_template , sobald diese stabil sind.
Wann eine schrittweise Migration nicht empfohlen wird
Projekte mit stark experimentellen Konfigurationen, häufigen kurzfristigen Überschreibungen oder instabilen Extension-Setups könnten davon profitieren, die Migration zu verschieben, bis die Konfiguration stabilisiert ist.
Praktische Vorteile der Einbindung von TYPO3 v13-Sitesets
In der Praxis betreffen Site Sets hauptsächlich, wie die Konfiguration strukturiert und verwaltet wird, anstatt neue Frontend- oder redaktionelle Funktionen einzuführen.
- Zeitersparnis: Die Konfiguration wird auf site-Ebene gruppiert, wodurch der Bedarf entfällt, Einstellungen über mehrere Templates oder Einschlussmechanismen hinweg nachzuverfolgen.
- Konsistenz: Gemeinsame Konfigurationen können über mehrere sites hinweg wiederverwendet werden, was den Teams hilft, dieselben strukturellen Standards in Multi-Site-Umgebungen anzuwenden.
- Reduzierter globaler Bereich: TypoScript, Page TSconfig und Einstellungen sind pro site definiert, was hilft, unbeabsichtigte Nebeneffekte in komplexen Installationen zu begrenzen.
- Editor-Interaktion: Wo Einstellungen absichtlich freigegeben werden, können Editoren Werte über das Backend anpassen, ohne Konfigurationsdateien zu bearbeiten.
- Laufende Kompatibilität: Site Sets richten sich nach der Konfigurationsrichtung, die in TYPO3 v13 eingeführt wurde, und ermöglichen es Projekten, aktuellen Core-Konventionen zu folgen, ohne auf veraltete Muster angewiesen zu sein.
Schlussfolgerung
Site Sets führen eine strukturierte Möglichkeit ein, die site-spezifische Konfiguration in TYPO3 v13 zu verwalten, indem TypoScript, Page TSconfig und Einstellungen in klar definierte, site-spezifische Einheiten gruppiert werden.
Sie verringern die Abhängigkeit von verstreuten Konfigurationsdatensätzen und machen Abhängigkeiten zwischen Konfigurationsebenen expliziter. Für Teams, die mit Multi-Site-Setups, geteilten Konfigurationen oder langfristig laufenden TYPO3-Projekten arbeiten, bieten Site Sets eine konsistente Grundlage, die mit dem in TYPO3 v13 eingeführten Konfigurationsmodell übereinstimmt.
Gleichzeitig sind sie so konzipiert, dass sie mit bestehenden Ansätzen koexistieren, wodurch eine schrittweise Einführung möglich ist, ohne eine sofortige Refaktorisierung zu erzwingen.
Wie bei anderen TYPO3-Konfigurationsmechanismen hängt ihr Wert davon ab, wie bewusst sie eingesetzt werden. Wenn Site Sets durchdacht angewendet werden, können sie helfen, die Konfiguration wartbar und transparent zu halten, während sich Projekte weiterentwickeln.
FAQs
Nein. Site Sets sind in TYPO3 v13 optional und koexistieren mit bestehenden Konfigurationsmethoden. Projekte können weiterhin sys_template, statisches TypoScript oder Extension-basierte Konfiguration verwenden und Site Sets schrittweise einführen, wenn und wo sie sinnvoll sind.
Nein. Site Sets ersetzen nicht TypoScript. Sie bieten eine strukturierte Möglichkeit, TypoScript auf site-Ebene bereitzustellen und einzugrenzen, aber TypoScript selbst bleibt die Konfigurationssprache für Rendering und Verhalten.
Ja. Eine TYPO3-Site kann von mehreren Site Sets abhängen. TYPO3 löst sie basierend auf deklarierten Abhängigkeiten und der Lade-Reihenfolge auf, wodurch eine geschichtete Konfiguration ohne manuelles Einschluss-Management ermöglicht wird.
Einstellungsdefinitionen werden in YAML-Dateien innerhalb des Site Sets gespeichert. Nur überschreibene Werte werden separat gespeichert, wodurch die Konfiguration größtenteils dateibasiert und versionskontrolliert bleibt.
Ja. Site Sets sind Teil von TYPO3 v13 LTS und für den langfristigen Einsatz konzipiert. Sie sollen eine stabile Konfigurationsverwaltung über kleinere Updates im v13 LTS-Lifecycle hinweg unterstützen.
Nicht unbedingt. Site Sets sind besonders nützlich für Extensions, die site-spezifische Konfigurationen oder wiederverwendbare Integrationslogik bereitstellen. Extensions, die sich ausschließlich auf Backend-Funktionalitäten oder isolierte Features konzentrieren, benötigen sie möglicherweise nicht.

Big thanks to the author for this detailed blog on TYPO3 v13 Site Sets! It explained everything I needed to know about setting them up and using them effectively. I now feel more confident managing my TYPO3 sites with these new features.