TYPO3 Templates & Sitepackages: Custom statt fertig

Fertige TYPO3-Templates sparen kurzfristig Zeit und kosten langfristig mehr

Die Versuchung ist groß: Ein fertiges TYPO3-Template für 79 Euro kaufen, installieren, Logo austauschen, fertig. In Wirklichkeit beginnt damit ein Kreislauf aus Workarounds, Overrides und Versionskonflikten, der jedes Update erschwert und die Weiterentwicklung bremst. dmpr_template steht exemplarisch für diese Kategorie. Gosign empfiehlt stattdessen Custom Sitepackages: individuelle Template-Pakete, die exakt auf die Anforderungen zugeschnitten, wartbar und versionierbar sind.

Ein Sitepackage ist eine TYPO3-Extension, die das komplette Frontend-Setup enthält: TypoScript, Fluid-Templates, Partials, Layouts, CSS/SCSS, JavaScript und Backend-Layouts. Es ist die offizielle TYPO3-Best-Practice seit Version 8 und ersetzt die alte Methode, Templates im Dateisystem zu konfigurieren.

Typische Einsatzszenarien

Unternehmens-Relaunch mit individuellen Anforderungen. Ein Unternehmen startet einen Website-Relaunch. Das Design steht als Figma-Datei, die Informationsarchitektur als Sitemap, die Content-Typen sind definiert. Ein Custom Sitepackage übersetzt diese Vorgaben 1:1 in TYPO3: Jeder Content-Typ wird als Backend-Layout oder Custom Content Element abgebildet, die Fluid-Templates entsprechen dem Design pixelgenau. Kein Template-Framework steht dazwischen, das Kompromisse erzwingt.

Multi-Site-Setup mit geteilten Komponenten. Ein Konzern betreibt 5 Markenwebsites in einer TYPO3-Instanz. Alle teilen ein Basis-Sitepackage mit Grid-System, Typografie und Basis-Komponenten. Jede Marke hat ein eigenes Sitepackage, das die Basis-Extension erweitert: Farben, Logo, markenspezifische Layouts. Änderungen an der Basis wirken sich auf alle 5 Seiten aus, ohne dass 5 separate Codebases gepflegt werden müssen.

Migration von alten Template-Setups. TYPO3-Installationen aus der Version 6 oder 7 nutzen oft TemplaVoilà, Fluid Styled Content mit umfangreichen TypoScript-Overrides oder sogar Marker-basierte Templates. Die Migration auf ein sauberes Sitepackage modernisiert den gesamten Frontend-Stack in einem Schritt: weg von globalen TypoScript-Konfigurationen, hin zu einer versionierbaren Extension mit klarer Verzeichnisstruktur.

Technische Architektur

Ein Sitepackage ist eine reguläre TYPO3-Extension mit einer definierten Verzeichnisstruktur:

Configuration/TypoScript/ enthält die TypoScript-Konfiguration: Constants, Setup, Page-TSconfig. Hier wird definiert, welche Templates für welche Seitentypen gelten, welche Inhaltselemente verfügbar sind und wie sie gerendert werden.

Resources/Private/Templates/ enthält die Fluid-Templates für die Seitentypen (Page), Inhaltselemente (ContentElements) und Partials (wiederverwendbare Template-Fragmente). Die Trennung in Templates, Partials und Layouts folgt TYPO3s Fluid-Konvention.

Resources/Public/ enthält CSS/SCSS, JavaScript, Bilder und Fonts. Alles, was der Browser direkt ausliefert. In modernen Setups wird SCSS per Build-Tool (Vite, Webpack) kompiliert und die generierten Dateien in Resources/Public/Build/ abgelegt.

Configuration/TCA/ definiert Backend-Layouts und Custom Content Elements. Backend-Layouts steuern, welche Spalten und Bereiche auf einer Seite im Backend verfügbar sind. Custom Content Elements werden über TCA, TypoScript und Fluid-Templates definiert.

Das Sitepackage wird per Composer installiert und über die Site Configuration (config.yaml) der jeweiligen TYPO3-Site zugewiesen. Mehrere Sites können dasselbe Sitepackage nutzen (Multi-Site) oder jeweils ein eigenes haben.

Häufige Probleme und Lösungen

Fertig-Templates kollidieren mit TYPO3-Updates. Gekaufte Templates überschreiben oft Core-Konfigurationen und TCA-Definitionen auf eine Weise, die bei TYPO3-Updates bricht. Ein Template, das für TYPO3 v10 entwickelt wurde, funktioniert nach dem Update auf v12 häufig nicht mehr, weil TCA-Wizards, Backend-Layout-Registrierung und Fluid-ViewHelpers sich geändert haben. Mit einem Custom Sitepackage kontrolliert man selbst, welche Core-Features genutzt werden, und kann Updates schrittweise durchführen.

Sitepackage-Struktur wächst unkontrolliert. Über Jahre sammeln sich in einem Sitepackage dutzende Partials, verwaiste Templates und TypoScript-Fragmente an. Lösung: Regelmäßiges Refactoring. Ein sauberes Sitepackage hat maximal 20-30 Partials, klare Naming-Conventions (PascalCase für Templates, Ordner nach Funktion) und keine ungenutzten Dateien. Der Aufwand für ein Refactoring liegt bei 2-5 Tagen, abhängig von der Größe.

CSS-Spezifität-Konflikte mit Fluid Styled Content. TYPO3s Fluid Styled Content bringt eigene CSS-Klassen mit (ce-, frame-). Wenn das Sitepackage eigene Klassen nutzt, entstehen Spezifitäts-Konflikte. Lösung: Entweder Fluid Styled Content komplett durch eigene Content-Element-Definitionen ersetzen (sauberer, aber aufwändiger) oder die Fluid Styled Content Templates überschreiben und die Klassen anpassen.

Migration und Versions-Kompatibilität

Das Sitepackage-Konzept ist seit TYPO3 v8 der Standard und wird in jeder neuen TYPO3-Version weiterentwickelt. Die grundlegende Struktur (Extension mit TypoScript, Fluid-Templates, TCA) bleibt stabil. Anpassungen bei Major-Updates betreffen typischerweise TCA-Syntax (Wizards, renderTypes), TypoScript-Bedingungen (neu: Symfony Expression Language) und Backend-Modul-Registrierung.

Die Migration von einem Fertig-Template (dmpr_template, j77_template, in2template) auf ein Custom Sitepackage ist ein Rewrite, keine Portierung. Man analysiert die bestehenden Templates, extrahiert die gewünschte Funktionalität und baut sie in einer sauberen Sitepackage-Struktur neu auf. Bei einem typischen Projekt mit 10 Seitentypen und 15 Content-Elementen liegt der Aufwand bei 2-3 Wochen.

TYPO3 v13 führt Content Blocks als neues Konzept für Content-Element-Definitionen ein. Content Blocks vereinfachen die Erstellung von Custom Content Elements erheblich und reduzieren den Boilerplate-Code. Sitepackages bleiben davon unberührt, sie können Content Blocks zusätzlich nutzen. Gosign baut seit Jahren ausschließlich Custom Sitepackages und hat die Erfahrung, bestehende Template-Setups effizient auf moderne Strukturen zu migrieren.