TYPO3 Theme Manager im Jahr 2026: Parent-Child-Theme-Architektur, Site Sets und Camino
TYPO3 bietet Entwicklern seit jeher eine starke Kontrolle über Templates, Extensions und die Site-Konfiguration. Was jedoch häufig gefehlt hat, ist eine einfache und standardisierte Möglichkeit, Themes über mehrere Projekte hinweg zu erstellen, wiederzuverwenden und zu verwalten.
Das Parent-Child-Theme-Konzept wurde eingeführt, um diese Lücke zu schließen, indem gemeinsame Funktionalitäten von projektspezifischem Design getrennt werden. Seit die ursprüngliche Idee im Jahr 2019 vorgestellt wurde, hat sich das TYPO3-Theme-Ökosystem erheblich weiterentwickelt.
Dieser Artikel greift dieses Konzept erneut auf, erklärt, was sich verändert hat, und zeigt auf, wie moderne TYPO3-Funktionen heute eine strukturiertere Theme-Architektur unterstützen.
Das ursprüngliche TYPO3 Theme Manager-Konzept
Mein Vortrag bei den TYPO3 Developer Days 2019
Bei den TYPO3 Developer Days 2019 in Karlsruhe, Deutschland, präsentierte ich „Essential Solutions for TYPO3 Productivity“.“ Eine zentrale Idee war ein Parent- und Child-Theme-Framework, um wiederholte TYPO3-Einrichtungen zu reduzieren und die Wiederverwendung von Themes über mehrere Projekte hinweg zu verbessern.
Das Parent Theme sollte gemeinsame Templates, Einstellungen und Extensions enthalten. Das Child Theme sollte projektspezifisches Design und Funktionalitäten verwalten.
Video: Essential Solutions for TYPO3 Productivity
Themen-Diskussion beginnt um: 15:20
[<iframe width="560" height="315" src="https://www.youtube.com/embed/EiIKz-wK6z8?si=XlN3A4iQ5LFM4lYI&controls=0&start=920" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>]
Das TYPO3 Theme-Problem
Im Jahr 2019 gab es in TYPO3 keine universelle Möglichkeit, Themes zu erstellen, zu installieren oder zu verwalten. Projekte wiederholten häufig TypoScript, Page TSconfig, Templates und die Einrichtung von Inhaltselementen, wodurch Themes schwieriger wiederzuverwenden, zu konfigurieren und zu warten waren.
Die Parent-Child-Theme-Idee zielte darauf ab, gemeinsame Konfigurationen von projektspezifischen Anpassungen zu trennen.
Was ein TYPO3 Theme Manager leisten sollte
Ein vollständiger TYPO3 Theme Manager sollte Benutzern dabei helfen, Themes zu installieren, Abhängigkeiten zu verwalten, Logos, Farben und Layouts zu konfigurieren, Parent-Einstellungen zu übernehmen, Templates zu überschreiben, Starter-Inhalte zu importieren, die Kompatibilität zu prüfen, Änderungen in der Vorschau anzuzeigen und gemeinsame Komponenten zentral zu aktualisieren.
TYPO3 Theme Management im Jahr 2026: Was hat sich verändert?
Was hat sich verändert?
Die TYPO3-Theme-Entwicklung ist heute strukturierter. Site Sets bündeln wiederverwendbare Konfigurationen, Content Blocks vereinfachen benutzerdefinierte Inhaltstypen, und TYPO3 v14 enthält Camino als standardmäßiges Frontend-Theme.
Jahr | Entwicklung |
2019 | Parent-Child-Theme-Konzept vorgestellt |
2023–2024 | Site Sets eingeführt |
2024–2025 | Content Blocks etabliert |
Januar 2026 | Camino mit TYPO3 14.1 eingeführt |
April 2026 | TYPO3 14.3 als erste v14 LTS-Version veröffentlicht |
TYPO3 14.1 wurde am 20. Januar 2026 veröffentlicht, gefolgt von TYPO3 14.3 LTS am 21. April 2026.
Hat TYPO3 v14 einen vollständigen Theme Manager?
Nicht vollständig. TYPO3 v14 stellt viele Bausteine für das Theme-Management bereit, aber kein einzelnes universelles Backend-Modul zum Installieren, Vorschauen, Bearbeiten und Verwalten aller Themes.
TYPO3 v14 umfasst Camino, bearbeitbare Site-Einstellungen, Site Sets, Composer-verwaltete Pakete, Site Packages, wiederverwendbares TypoScript, Page TSconfig, Content Blocks und Backend-Layouts.
Es enthält weiterhin keinen universellen Theme-Marktplatz, keine One-Click-Erstellung von Parent-Child-Themes, keine vollständige Kompatibilitätsprüfung, keine visuelle Theme-Bearbeitung, keine Vorschau- oder Rollback-Funktion.
Camino: Das Standard-Theme von TYPO3
Camino ist das standardmäßige responsive Frontend-Theme für TYPO3 v14.1 und höher. Es bietet frischen Installationen im klassischen Modus ein funktionierendes Frontend mit minimalem Einrichtungsaufwand.
Es umfasst Backend-Layouts, Farbschemata, Logo-Einstellungen, Standard-Inhaltselemente, Camino-spezifische Inhaltselemente und eine grundlegende Navigation.
Camino eignet sich für einfache Websites, Demos und schnelle Starts. Komplexe Marken-Websites benötigen in der Regel weiterhin ein individuelles Site Package oder ein Theme-Framework.
TYPO3 Site Sets für wiederverwendbare Themes
TYPO3 Site Sets bündeln wiederverwendbare Site-Konfigurationen, einschließlich Einstellungen, TypoScript, Page TSconfig, Abhängigkeiten und Route Enhancers.
Configuration/Sets/MyTheme/
├── config.yaml
├── settings.definitions.yaml
├── settings.yaml
├── setup.typoscript
├── constants.typoscript
├── page.tsconfig
└── route-enhancers.yaml
Site Sets können über Sites > Setup zugewiesen werden, wodurch die Wiederverwendung gemeinsamer Konfigurationen über mehrere TYPO3-Websites hinweg einfacher wird.
Site Package vs Theme Extension vs Site Set
Konzept | Hauptrolle |
Site Package | Projekt-Thema und Funktionalität |
Theme Extension | Frontend-Design und Templates |
Site Set | Wiederverwendbare Konfiguration und Abhängigkeiten |
Parent Theme | Gemeinsame Architektur und Komponenten |
Child Theme | Projektspezifische Überschreibungen |
Camino | Standardmäßiges TYPO3 v14 Frontend-Theme |
Diese Konzepte können zusammenarbeiten. Ein Site Package kann ein Site Set enthalten, von einem Parent Theme abhängig sein und Child-Theme-Überschreibungen für eine bestimmte TYPO3-Website bereitstellen.
TYPO3 Parent- und Child-Theme-Architektur erklärt
Was sind ein Parent- und ein Child-Theme in TYPO3?
Ein Parent Theme enthält gemeinsame Layouts, Assets, Templates, Site Sets, Konfigurationen und Funktionalitäten, die über mehrere TYPO3-Websites hinweg wiederverwendet werden können.
Ein Child Theme erbt vom Parent Theme und fügt nur projektspezifisches Design, Einstellungen und Funktionalitäten hinzu oder überschreibt diese, ohne den gemeinsamen Parent-Code zu verändern.
Definition
Typ | Bedeutung |
Parent Theme | Wiederverwendbares Basispaket |
Child Theme | Projektspezifische Erweiterung des Parent Themes |
Wie funktioniert die Vererbung?
Das Child Theme übernimmt Templates, Assets, Site Sets und Konfigurationen vom Parent Theme. Es überschreibt nur die Dateien oder Einstellungen, die für die jeweilige Website erforderlich sind.
TYPO3 Core
↓
Parent Theme
↓
Child Theme
↓
Projekt-Website
Das Parent Theme wird normalerweise von der Agentur oder dem Produktteam gepflegt. Das Child Theme wird für jedes Kundenprojekt individuell verwaltet.
Geeignete Projekttypen
Die Parent-Child-Theme-Architektur eignet sich gut für Multi-Brand-Websites, große Organisationen, Agentur-Starter-Kits und Multi-Client-TYPO3-Projekte.
Was gehört in das Parent Theme?
Das Parent Theme sollte gemeinsame Ressourcen wie Site Sets, globale Templates, Layouts, ViewHelpers, Design-Tokens, Navigation, Formulare, Barrierefreiheits-Standards, gemeinsame Content Blocks, CSS/JS-Build-Konfiguration, Testkonfiguration und grundlegende SEO-Einstellungen enthalten.
Was gehört in das Child Theme?
Das Child Theme sollte projektspezifische Ressourcen wie Marken-Assets, individuelle Templates, Design-Token-Überschreibungen, projektspezifische Content Blocks, Site-Einstellungen, Integrationen, Route Enhancers, Übersetzungen und kundenspezifische Editor-Berechtigungen enthalten.
Parent Theme vs Child Theme
Parent Theme | Child Theme |
Wird über mehrere Projekte hinweg verwendet | Wird für ein einzelnes Projekt genutzt |
Enthält wiederverwendbare Layouts | Enthält projektspezifische Layouts |
Definiert gemeinsame Styles | Überschreibt Styles bei Bedarf |
Stellt gemeinsame Komponenten bereit | Fügt individuelle Komponenten hinzu |
Enthält gemeinsame Site Sets | Nutzt projektspezifische Site Settings |
Zentral verwaltet | Pro Kunde verwaltet |
Einmal aktualisiert für alle Websites | Aktualisiert entsprechend den Projektanforderungen |
Vorteile der Parent-Child-Architektur
Dieser Ansatz reduziert Duplikationen, beschleunigt Multi-Brand-Launches, hält Projekt-Code kleiner und erleichtert die Verwaltung gemeinsamer Updates für Barrierefreiheit, Sicherheit und Kompatibilität. Außerdem entstehen vorhersehbare Überschreibungsstellen, wodurch Teams mehrere TYPO3-Websites effizienter verwalten können.
Einschränkungen und Kompromisse
Die wichtigsten Risiken sind eine starke Abhängigkeit vom Parent Package, fehlerhafte Änderungen in gemeinsamen Templates, abweichende Überschreibungen, Abhängigkeitskonflikte und die Notwendigkeit, Änderungen über mehrere Websites hinweg zu testen. Ein Parent Theme kann außerdem zu umfangreich werden, wenn es versucht, jeden möglichen Anwendungsfall abzudecken.
ns_basetheme und TYPO3 Child Theme Framework
Einführung in ns_basetheme
ns_basetheme ist das wiederverwendbare TYPO3 Parent Theme von NITSAN zum Erstellen mehrerer Websites auf Basis einer gemeinsamen Codebasis.
Element | Details |
Aktuelle Version | 14.0.3 |
Veröffentlichungsdatum | 14. Juli 2026 |
TYPO3-Kompatibilität | TYPO3 v14 LTS |
Composer-Paket | nitsan/ |
TER-Status | Im TYPO3 Extension Repository verfügbar |
Maintainer | NITSAN Technologies |
Architektur | Parent-Child-Theme mit Site Sets |
ns_basetheme vs Camino
ns_basetheme | Camino |
Wiederverwendbares Parent-Framework | Starter-Website |
Unterstützt Child Themes | Fokus auf ein einzelnes Projekt |
Für mehrere Websites entwickelt | Für schnelle Einrichtung entwickelt |
Wo ist ns_basetheme zu finden?
ns_basetheme ist über das TYPO3 Extension Repository, das Composer-Paket, das GitHub-Repository, die Dokumentation, das Changelog, den Issue Tracker, Kompatibilitätsinformationen und die Security Advisory-Seite verfügbar.
Einführung in das Child Theme
Ein Child Theme enthält ausschließlich projektspezifische Anpassungen. Es wird für Marken-Styling, individuelle Templates, Projekteinstellungen, Integrationen und projektspezifische Content Blocks verwendet.
Es kann Fluid-Überschreibungen, CSS/JS-Überschreibungen, Site Settings und Übersetzungen unterstützen. Best Practice ist es, die Parent-Abhängigkeit zu deklarieren, klare Paketnamen zu verwenden, Semantic Versioning zu befolgen und das Child Theme unabhängig vom Parent Theme zu veröffentlichen.
Aktuelle ns_basetheme-Architektur
packages/ns_basetheme/
├── composer.json
├── Configuration/
├── Configuration/Sets/
├── Resources/
│ ├── Private/
│ │ ├── Templates/
│ │ ├── Partials/
│ │ └── Layouts/
│ ├── Public/
│ └── Translations/
├── ContentBlocks/
├── PageTS/
├── Tests/
└── Build/
Das Parent Theme enthält gemeinsame TYPO3-Konfigurationen, Site Sets, Fluid Templates, wiederverwendbare Komponenten, Layouts, gemeinsame Inhaltselemente, öffentliche Assets, Übersetzungen, Backend PageTS, automatisierte Tests und Frontend-Build-Tools.
Aktuelle Child-Theme-Architektur
packages/site_customer/
├── composer.json
├── Configuration/
├── Resources/
│ ├── Private/
│ ├── Public/
│ └── Translations/
├── ContentBlocks/
└── PageTS/
Das Child Theme enthält Projekteinstellungen, individuelle Templates, Marken-Assets, Projektübersetzungen, kundenspezifische Content Blocks und Editor-Konfigurationen.
ns_basetheme vs Camino vs Custom Site Package
Anforderung | Bester Ausgangspunkt |
Einfache Website mit minimaler Einrichtung | Camino |
Individuelle Single-Brand-Website | Custom Site Package |
Wiederverwendbares Agentur-Framework | ns_basetheme |
Mehrere zusammengehörige Marken-Websites | Parent-Child-Architektur |
Erlernen der TYPO3-Konventionen | Offizielles Site-Package-Tutorial |
Stark kontrollierte Komponenten-Plattform | Custom Site Package + Site Sets + Content Blocks |
TYPO3 v14 Theme-Implementierungs-Tutorial
Voraussetzungen
Bevor Sie mit diesem TYPO3 v14 Theme-Tutorial beginnen, stellen Sie sicher, dass Ihre Umgebung Folgendes umfasst:
- TYPO3 14.3 LTS
- PHP 8.2–8.5
- Composer
- DDEV
- Git
- Node-Tools, falls erforderlich
- Grundkenntnisse in Fluid und TypoScript
Option A: Aufbau mit dem TYPO3 Camino Theme
Camino ist der schnellste Ausgangspunkt für eine TYPO3 v14 Website.
Grundlegende Schritte:
- Erstellen Sie ein TYPO3 v14 Projekt.
- Installieren Sie
typo3/theme-camino. - Erstellen oder konfigurieren Sie die Site.
- Fügen Sie das Camino Site Set hinzu.
- Wählen Sie das Backend-Layout aus.
- Konfigurieren Sie das Logo und die Farben.
- Fügen Sie Inhalte hinzu.
- Erweitern Sie die Einrichtung durch ein individuelles Site Package.
Der offizielle Ansatz besteht darin, Camino bei Bedarf zu erweitern oder zu kopieren und nicht Dateien innerhalb von vendor/typo3 zu bearbeiten. Änderungen an Vendor-Dateien werden bei Updates überschrieben.
Option B: Aufbau mit ns_basetheme und einem Child Theme
Für eine wiederverwendbare Theme-Architektur verwenden Sie ns_basetheme mit einem Child Theme.
Grundlegende Schritte:
- Erstellen Sie das Projektverzeichnis.
- Konfigurieren Sie DDEV und die erforderliche PHP-Version.
- Installieren Sie TYPO3 14.
- Installieren Sie
nitsan/ns-basetheme. - Erstellen oder installieren Sie das Child-Theme-Paket.
- Konfigurieren Sie die TYPO3-Site.
- Weisen Sie Site Sets zu, sofern zutreffend.
- Führen Sie Datenbankmigrationen aus.
- Lernen Sie die Caches.
- Überprüfen Sie die Frontend-Darstellung.
Dieser Ansatz eignet sich, wenn mehrere Websites ein gemeinsames Parent Theme nutzen sollen, während projektspezifische Änderungen getrennt bleiben.
Historische TYPO3 v9-Demonstration
Die folgende Demonstration wird nur als Archiv des ursprünglichen Workflows aus dem Jahr 2019 beibehalten. Verwenden Sie diese Befehle nicht für ein neues TYPO3 v14 Projekt.
Verschieben Sie alle alten PHP 7.2- und TYPO3 v9-Befehle in diesen Abschnitt.
Um aktuelle Leser nicht zu verwirren, platzieren Sie die archivierten Befehle innerhalb eines ausklappbaren Bereichs:
<details>
<summary>View historical TYPO3 v9 demonstration</summary>
<!-- Old TYPO3 v9 and PHP 7.2 commands go here -->
</details>
Dies bewahrt die Historie, ohne Benutzer abzulenken, die wegen des aktuellen TYPO3-v14-Workflows gekommen sind.
Clean Blog TYPO3 Theme Demo und Einrichtung
Clean Blog Theme-Beispiel
Die Clean Blog Child Theme-Demo sollte die bestehenden TER-, Git- und Composer-Verweise beibehalten, aber die Paketinformationen sollten aktualisiert werden.
Aktuelle Paketdetails:
Element | Details |
Paket |
|
Aktuelle Version | 14.1.0 |
TYPO3-Kompatibilität | TYPO3 12, 13 und 14 |
Parent-Abhängigkeit |
|
Installation | Composer |
Demo-Verfügbarkeit | Aktuellen Demo-Link/Status hinzufügen |
Datum der letzten Aktualisierung | Aktuelles Veröffentlichungsdatum hinzufügen |
Lizenz | Aktuelle Paketlizenz hinzufügen |
Erforderliche Content-Extensions | Aktuelle Abhängigkeiten hinzufügen |
Installation und Konfiguration des Clean Blog Child Themes
Verwenden Sie einen klaren Installationsablauf anstelle eines zweistufigen „fertig“-Versprechens.
Empfohlene Struktur:
- Prüfen Sie die Umgebungsanforderungen.
- Installieren Sie das Paket mit Composer.
ddev composer require nitsan/ns-theme-cleanblog
- Führen Sie Datenbankmigrationen aus.
- Aktivieren Sie das erforderliche Site Set.
- Importieren Sie den Seitenbaum oder Demo-Inhalte, falls verfügbar.
- Leeren Sie die TYPO3-Caches.
- Überprüfen Sie die Frontend-Ausgabe.
- Prüfen Sie die Logs, falls etwas nicht korrekt gerendert wird.
Beispiel für einen Composer-Befehl:
composer require nitsan/ns-theme-cleanblog
Bestätigen Sie nach der Installation, ob das Theme die Konfiguration automatisch hinzufügt oder eine manuelle Aktivierung des Site Sets und den Import von Inhalten erfordert.
Was installiert das Theme automatisch?
Fügen Sie diese Tabelle hinzu, damit Benutzer genau wissen, welche Änderungen durch die Composer-Installation vorgenommen werden.
Element | Automatisch installiert? | Wo wird es gespeichert |
Seitenbaum | Aktuelles Verhalten prüfen | Datenbank oder Import |
TypoScript | Ja/nein | Site Set oder Extension |
Page TSconfig | Ja/nein | Site Set oder Extension |
Content Blocks | Ja/nein | Child-Theme-Paket |
Assets | Ja/nein | Resources/Public |
Site-Konfiguration | Ja/nein | config/sites/ |
Demo-Inhalte | Ja/nein | Import-Paket |
Dies verhindert, dass Benutzer davon ausgehen, dass die Composer-Installation automatisch Seiten, Inhalte, Layouts oder eine vollständige Site-Konfiguration erstellt.
Verifizierungs-Checkliste
Überprüfen Sie nach der Installation:
- Das Paket ist über Composer installiert.
- Die Datenbankmigrationen sind abgeschlossen.
- Die erforderlichen Site Sets sind aktiv.
- Das Backend-Layout kann ausgewählt werden.
- Assets werden korrekt geladen.
- Inhaltselemente werden korrekt dargestellt.
- Demo-Inhalte werden korrekt importiert, sofern enthalten.
- Es erscheinen keine TYPO3-Fehler in den Logs.
- Frontend-Seiten werden wie erwartet dargestellt.
Fehlerbehebung
Wenn das Theme nicht wie erwartet funktioniert, prüfen Sie Composer-Abhängigkeiten, TYPO3-Kompatibilität, Site Set-Aktivierung, Datenbankmigrationen, Cache-Status, fehlende Content-Extensions, Dateiberechtigungen und TYPO3-Logs.
Vermeiden Sie absolute Aussagen wie „Fertig, keine weiteren Schritte erforderlich“. Das Verhalten eines Themes kann von der TYPO3-Einrichtung, der Paketversion, der Site-Set-Konfiguration und davon abhängen, ob Demo-Inhalte separat importiert werden.
Benutzerdefinierte Inhaltselemente in TYPO3 v14
Historischer Core-Workflow für benutzerdefinierte Inhaltselemente
Der ursprüngliche TYPO3 v9-Workflow für benutzerdefinierte Inhaltselemente sollte als historische Referenz beibehalten, aber eindeutig als veraltet gekennzeichnet werden.
Dieser Abschnitt zeigt den ursprünglichen TYPO3 v9-Ansatz. Vor der Veröffentlichung sollten API-Namen und Code-Beispiele anhand der aktuellen TYPO3 v14-Standards überprüft werden.
Platzieren Sie den langen historischen Workflow in einem ausklappbaren Bereich, damit aktuelle Leser nicht durch veraltete Schritte abgelenkt werden.
<details>
<summary>View original TYPO3 v9 custom content element workflow</summary>
<!-- Original TYPO3 v9 workflow goes here -→
</details>
Der ursprüngliche ns_basetheme Shortcut
Der ursprüngliche ns_basetheme Shortcut kann ebenfalls beibehalten werden. Behalten Sie die XML- und HTML-Beispiele bei, erklären Sie jedoch, wie das System funktioniert:
- Welcher Prozess die XML- und HTML-Dateien scannt.
- Wie
CType-Namen generiert werden. - Wie XML-Felder den Backend-Feldern zugeordnet werden.
- Wo die Validierung stattfindet.
- Wie Labels und Übersetzungen geladen werden.
- Wie Icons registriert werden.
- Wie Backend-Vorschauen generiert werden.
- Welche Grenzen hat die automatische Erkennung?
Dies gibt Lesern einen nützlichen Kontext, ohne den Shortcut als den einzigen modernen Ansatz darzustellen.
Moderner TYPO3 v14-Ansatz: Content Blocks
Für TYPO3 v14 sind Content Blocks der sauberere moderne Ansatz für strukturierte Inhaltselemente. Ein Content Block wird normalerweise auf Basis einer config.yaml-Datei, eines Fluid-Frontend-Templates, Assets, Labels, eines Icons und einer optionalen Backend-Vorschau-Konfiguration erstellt. Die offizielle Content Blocks-Dokumentation beschreibt config.yaml als die zentrale Datei eines Content Blocks.
Ein typischer Content Block kann Folgendes enthalten:
ContentBlocks/MyElement/
├── config.yaml
├── templates/
│ └── frontend.html
├── assets/
│ ├── icon.svg
│ └── style.css
└── labels.xlf
Content Blocks können Felder, Labels, Icons, Frontend-Templates und die Asset-Verwaltung definieren. Die Asset-Dokumentation behandelt außerdem unterstützte Icon-Formate und das TYPO3-Verhalten beim Veröffentlichen von Assets.
Vergleich der Methoden für benutzerdefinierte Elemente
Methode | Am besten geeignet für | Hinweise |
Core CType | Vollständige manuelle Kontrolle | Leistungsfähig, aber aufwendiger bei der Einrichtung |
Content Blocks | Moderne strukturierte Inhaltselemente | Beste Standardwahl für TYPO3 v14-Projekte |
Mask | Editor-freundliche benutzerdefinierte Elemente | Gut für Teams, die eine Backend-basierte Einrichtung bevorzugen |
DCE | Flexible dynamische Inhaltselemente | Nützlich für Legacy- oder spezielle Workflows |
Flux | Fluid-basierte Inhaltsstrukturen | Leistungsstark, aber abhängig vom Projektstandard |
ns_basetheme | Theme-basierte automatische Elemente | Nützlich innerhalb von NITSAN Parent-Child-Theme-Setups |
Für die meisten neuen TYPO3 v14-Projekte sollten Content Blocks für benutzerdefinierte Inhaltselemente verwendet werden. Verwenden Sie Core CType, wenn Sie vollständige Kontrolle auf niedriger Ebene benötigen. Nutzen Sie ns_basetheme Shortcuts, wenn das Projekt bereits dieser Parent-Child-Theme-Architektur folgt.
TYPO3 Theme-Upgrades, Wartung und Governance
Ein Upgrade für mehrere TYPO3-Projekte
Ein Parent Theme kann wiederholte Upgrade-Arbeiten reduzieren, entlastet jedoch nicht die Verantwortung auf Projektebene.
Gemeinsame Kompatibilitätsfixes können aus dem Parent-Paket veröffentlicht werden. Jede Child-Site muss weiterhin separat getestet werden. Projektspezifische Overrides, Integrationen und Datenmigrationen bleiben separate Verantwortlichkeiten.
Upgrade-Ablauf für ein Parent Theme
Ein sauberes Parent-Theme-Upgrade sollte diesem Ablauf folgen:
- Einen Kompatibilitäts-Branch erstellen.
- Die TYPO3 Core-Anforderungen aktualisieren.
- Rector und Deprecation-Checks ausführen, sofern anwendbar.
- Fluid Templates und TypoScript aktualisieren.
- Gemeinsame Komponenten testen.
- Eine semantische Version veröffentlichen.
- Child-Projekte aktualisieren.
- Projektspezifische Tests durchführen.
- Über Staging bereitstellen.
- Logs und Frontend-Fehler überwachen.
Kompatibilitätsmatrix
Veröffentlichen Sie keine ungeprüften Kompatibilitätsfelder. Behalten Sie „Verify“ bei, wenn die Paket-Kompatibilität noch geprüft werden muss.
Paket | TYPO3 12 | TYPO3 13 | TYPO3 14 | Aktuelle Version | Geprüftes Datum |
| Verify | Verify | Yes | 14.0.3 | Juli 2026 |
| Yes | Yes | Yes | 14.1.0 | Juli 2026 |
Camino | No | No | Yes | v14 series | Juli 2026 |
Content Blocks | Check package line | Yes | Yes | Current 2.x line | Juli 2026 |
ns_basetheme 14.0.3 ist auf TER und Packagist mit TYPO3 v14-Kompatibilität aufgeführt. ns-theme-cleanblog 14.1.0 ist mit einer Abhängigkeit von nitsan/ns-basetheme ^14.0.0 aufgeführt.
Test-Checkliste
Vor der Veröffentlichung von Parent-Theme- oder Child-Theme-Updates prüfen:
- Composer-Abhängigkeitsvalidierung.
- Ergebnisse des TYPO3 Extension Scanners.
- Deprecation-Logs.
- Unit- und Funktionstests.
- Fluid Template-Rendering.
- Visuelle Regression.
- Barrierefreiheit.
- Core Web Vitals.
- Mehrsprachiges Rendering.
- Cache-Verhalten.
- Editor-Berechtigungen.
- Upgrade-Rollback-Plan.
Wann sollte kein Parent Theme verwendet werden?
Vermeiden Sie eine Parent-Child-Theme-Architektur, wenn das Projekt eine kleine individuelle Website ist, ein vollständig unabhängiges Designsystem besitzt, einen isolierten Release-Zyklus benötigt oder das Team keine gemeinsame Abhängigkeit pflegen kann.
Vermeiden Sie sie ebenfalls, wenn die meisten Änderungen auf Child-Theme-Ebene stattfinden. Wenn jedes Child Theme die Hälfte des Parent Themes überschreibt, ist das Parent Theme kein Framework mehr. Es ist nur noch Ballast mit einer Versionsnummer.
Für einfache Websites können Camino oder ein fokussiertes Site Package besser geeignet sein.
Die richtige TYPO3 Theme-Architektur auswählen
Welche TYPO3-Theme-Architektur sollten Sie wählen?
Nutzen Sie diesen Entscheidungsweg:
Anforderung | Empfohlener Ansatz |
Einfache Website schnell erstellen | Camino verwenden |
Individuelles einmaliges Projekt | Ein benutzerdefiniertes Site Package erstellen |
Gemeinsame Architektur über Projekte hinweg | Ein Base Theme verwenden |
Markenspezifische Overrides | Child Themes hinzufügen |
Wiederverwendbare Konfiguration | Site Sets verwenden |
Benutzerdefinierte Komponenten | Content Blocks oder einen dokumentierten Projektstandard verwenden |
Kurz gesagt: Verwenden Sie Camino für Geschwindigkeit, Site Packages für individuelle Builds, Site Sets für wiederverwendbare Konfigurationen, Content Blocks für benutzerdefinierte Elemente und Parent-Child-Themes, wenn mehrere Websites eine gemeinsame Architektur benötigen.
Was würde ein vollständiger TYPO3 Theme Manager noch benötigen?
TYPO3 v14 bietet starke Bausteine, aber ein vollständiger Theme-Manager würde weiterhin benötigt werden:
- Theme-Manifest-Standard.
- Kompatibilitäts-Metadaten.
- Schema für visuelle Konfiguration.
- Vorschau und Rollback.
- Parent-Child-Abhängigkeits-UI.
- Theme-Update-Health-Checks.
- Import von Starter-Inhalten.
- Verwaltung von Design-Tokens.
- Validierung von Extension-Abhängigkeiten.
- Marketplace-Integration.
- Bewertung von Barrierefreiheit und Performance.
- Visuelle Site-Set-Verwaltung.
Diese Unterscheidung ist wichtig: TYPO3 v14 verfügt über viele Bestandteile eines Theme-Management-Systems, aber noch nicht über ein universelles Modul, das Erkennung, Installation, Konfiguration, Vorschau, Rollback und Governance vollständig von Anfang bis Ende verwaltet.
TYPO3 v15 Ausblick
TYPO3 v15 sollte sorgfältig als Roadmap-Thema und nicht als garantierte Feature-Liste diskutiert werden.
Das TYPO3 v14 Camino Changelog beschreibt, dass Camino nicht innerhalb des TYPO3 Core weiterentwickelt werden soll und geplant ist, es mit TYPO3 v15.0 in ein separates Repository auf TER, Packagist und GitHub zu verschieben. Außerdem wird erwähnt, dass ein neueres Theme zukünftige v15-Funktionalitäten verwenden könnte.
Die Content-Blocks-Dokumentation und Paketinformationen weisen auf eine stärkere Core-Ausrichtung hin, wobei das Paket als für TYPO3 v13/v14 nutzbar beschrieben wird und erwartet wird, dass es in TYPO3 v15 LTS ein Core-Feature wird.
Diese Aussagen sollten als geplante Richtung und nicht als bestätigtes finales Release-Verhalten dargestellt werden. TYPO3 v15 könnte die Entwicklung hin zu wiederverwendbaren Themes, strukturierten Inhalten und einer saubereren Konfiguration fortsetzen, aber die finale Implementierung sollte vor der Veröffentlichung immer anhand des offiziellen TYPO3 Changelogs und der Release Notes geprüft werden.
Fazit
TYPO3 v14 hat das Theme-Management mit Camino, Site Sets und Content Blocks verbessert.
Parent- und Child-Themes helfen Agenturen dabei, eine gemeinsame Architektur über mehrere Websites hinweg wiederzuverwenden.
Dennoch bietet TYPO3 derzeit noch keinen vollständigen universellen Theme-Manager. Die richtige Lösung hängt von Projektgröße, Branding-Anforderungen, Wiederverwendungszielen und der Wartungsplanung ab.
FAQs
TYPO3 v14 verfügt nicht über einen vollständigen Theme Manager. Es bietet Camino, Site Sets, Site Packages, Content Blocks und Composer-verwaltete Extensions, aber kein zentrales Modul für Theme-Erkennung, Vorschau, Rollback und visuelle Bearbeitung.
Camino ist das Standard-Frontend-Theme, das mit TYPO3 14.1 eingeführt wurde. Es bietet neuen Installationen im klassischen Modus ein grundlegendes funktionierendes Frontend mit Layouts, Farben, Logo-Einstellungen, Navigation und standardmäßigen Inhaltselementen.
Ein TYPO3 Parent Theme ist ein wiederverwendbares Basis-Paket. Es enthält gemeinsame Layouts, Templates, Assets, Site Sets und Konfigurationen, die mehrere Websites verwenden können.
Ein TYPO3 Child Theme erweitert ein Parent Theme für ein einzelnes Projekt. Es übernimmt gemeinsame Dateien und überschreibt nur projektspezifische Elemente wie Branding, Templates, Übersetzungen oder Einstellungen.
Ein Site Set speichert wiederverwendbare Konfigurationen wie TypoScript, Page TSconfig, Einstellungen und Abhängigkeiten. Ein Site Package enthält normalerweise das vollständige Theme, Templates, Assets und die projektspezifische Website-Einrichtung.
Content Blocks sind die empfohlene moderne Option für TYPO3 v14. Sie verwenden YAML-Konfiguration, Fluid Templates, Labels, Icons und Assets, um strukturierte benutzerdefinierte Inhaltselemente zu erstellen.
Ansprechpartner für Internetagentur und TYPO3 Projekte
Sven Thelemann
Servicepartner - Deutschland
Sven Thelemann
Client Service LeadSven Thelemann ist Client Service Lead bei NITSAN und konzentriert sich auf die Bereitstellung von TYPO3 Lösungen, die den Kundenzielen entsprechen. Mit seinem ausgeprägten Verständnis für Technologie und Kundenerwartungen sorgt er für eine reibungslose Kommunikation und Projektabwicklung. Außerhalb der Arbeit fährt Sven Thelemann gerne Fahrrad und experimentiert mit selbstgemachten Rezepten.
Sei der erste der kommentiert