Von TemplaVoilà zu ContentBlocks: TYPO3-Templating im ehrlichen Rückblick
Die Extension-Ära: Visual Mapping, FlexForms und das Versionierungsproblem
TYPO3-Templating hat in den letzten fünfzehn Jahren mehr Transformationen durchgemacht als die meisten anderen CMS-Kernbereiche. Wir haben diese Entwicklung in laufenden Kundenprojekten durchlebt, nicht von außen beobachtet — das hinterlässt eine klarere Einschätzung, als jede Marktübersicht sie liefern könnte.
Den Anfang machte für viele Agenturen TemplaVoilà: Ende der 2000er Jahre ermöglichte die Extension ein visuelles Mapping von HTML-Templates auf Felder im TYPO3-Backend. Designer konnten Bereiche markieren, Redakteure bekamen strukturierte Eingabemasken — das war gegenüber reinem TypoScript-Templating ein echter Fortschritt. Das Problem lag, wo es bei komfortablen Lösungen oft liegt: in der Datenbank. Seitenstruktur, Mappings, Felddefinitionen: alles in tx_templavoila_*-Tabellen, kaum versionierbar, schwer deploybar, bei jedem Upgrade ein Risikopunkt. 2015/16 wurde TemplaVoilà offiziell als deprecated markiert. Projekte, die damals noch liefen, brauchten aufwendige Migrationen — und nicht wenige wurden dabei grundlegend neu gebaut.
MASK trat als pragmatische Antwort auf: Content-Elemente ohne PHP-Kenntnisse definieren, Fluid Templates nutzen, das Backend generiert die Eingabemaske. Besser als TemplaVoilà in Bezug auf Wartbarkeit, da die generierten Fluid-Partials zumindest im Dateisystem lagen. Die Extension selbst blieb aber notwendiger Bestandteil jeder Installation. Wer MASK nutzte, koppelte sich an den Entwicklungsrhythmus einer Drittextension, nicht an den des Core — jede neue TYPO3-Hauptversion brachte damit zunächst eine Kompatibilitätsfrage mit sich.
DCE (Dynamic Content Elements) verfolgte einen ähnlichen Ansatz, aber mit stärkerem FlexForm-Einsatz: Felder werden per XML-Konfiguration im Backend definiert, die Ausgabe erfolgt in Fluid. DCE hat eine treue Nutzerbasis, brachte aber auch eine Geschichte mit Sicherheitslücken mit sich. Die starke Extension-Bindung bleibt das strukturelle Problem: Wer mehrere hundert Content-Elemente auf DCE-Basis betreibt, merkt beim nächsten TYPO3-Hauptrelease, wie eng diese Bindung ist.
Gridelements löste ein anderes Problem: komplexe Layouts mit verschachtelten Spalten, Grid-Strukturen, responsiven Bereichen — ohne den nativen Backend-Layout-Mechanismus zu nutzen. Die Extension war zeitweise fast Standard auf dem deutschen Markt. Wir haben selbst Projekte in Gridelements gebaut und betreuen noch einige davon. Das Upgrade-Verhalten ist dabei das Dauerthema: Gridelements kämpft mit jeder TYPO3-Hauptversion um Kompatibilität, und die Migration zu nativen Backend-Layouts ist kein kleines Vorhaben — sondern etwas, das sich in Projekttagen rechnet.
Fluid Styled Content und Site Packages: Struktur ohne Extension-Stack
Parallel zur Extension-Ära entwickelte sich eine andere Richtung: Fluid Styled Content als offiziell mitgelieferter Ausgabepfad, kombiniert mit dem Site Package-Konzept als Strukturrahmen für projektspezifisches Templating. Kein Drittanbieter, keine zusätzliche Composer-Abhängigkeit für die Kernfunktionalität: TypoScript, Fluid Templates und ein Extension-Skeleton, das ausschließlich eigenen Code enthält.
Das ist nicht neuartig, aber es ist sauber. Ein Site Package lässt sich in Git verwalten, per CI/CD deployen und in Code-Reviews prüfen. Wer ein TYPO3-Projekt ausschließlich auf Fluid Styled Content und einem Site Package aufbaut, beschreibt dem nächsten Entwickler den Aufbau in einer Sprache, die das Core-Team selbst spricht: ohne Drittextension als Zwischenschicht, ohne proprietären Konfigurationsspeicher. Das reduziert Einarbeitungszeit und macht den Projektzustand transparent, auch nach einem Entwicklerwechsel.
Dieses Setup hat aber eine Grenze: Benutzerdefinierte Content-Elemente entstehen über TCA-Konfiguration in PHP, Fluid-Templates und TypoScript-Einträge, alles verteilt auf mehrere Dateien, ohne einheitliche Strukturvorgabe. Wer zehn benutzerdefinierte Elemente baut, findet sich in einer gewachsenen Konvention wieder, die nicht jedes Entwickler-Team gleich interpretiert. Die Lösung für genau dieses Problem kam mit TYPO3 12.
ContentBlocks: deklarativ, dateibasiert, offiziell
ContentBlocks adressiert diesen Punkt direkt. Seit TYPO3 12 verfügbar, ab TYPO3 13 offizieller Bestandteil des Core-Ökosystems, im ersten Quartal 2026 mit einem Backend-GUI ergänzt: Content-Elemente werden per YAML deklariert, die Ausgabe über Fluid geregelt, das gesamte Paket liegt als Verzeichnisstruktur im Dateisystem.
Was das praktisch bedeutet: Eine Content-Block-Definition ist eine Textdatei. Sie liegt im Repository, kann in einem Pull Request reviewt werden und lässt sich im CI validieren. Kein Datenbankzustand, der zwischen Entwicklungs- und Produktivumgebung divergiert, keine Extension, die zwischen zwei Releases ihren API-Stand ändert und einen nächtlichen Deployment-Lauf zum Problem macht.
Das deklarative Modell hat einen weiteren Effekt: Onboarding. Wer ContentBlocks noch nicht kannte, versteht die Struktur innerhalb weniger Minuten — YAML-Felder oben, Fluid-Template unten, Ordnername ist der Elementname. Das ist keine Vereinfachung um der Einfachheit willen, sondern eine Konsequenz aus der langjährigen Beobachtung, dass Systeme, die ihren eigenen Aufbau nicht erklären können, längerfristig teurer sind. Der KISS-Gewinn ist real, er lässt sich in Stunden messen.
Eine Einschränkung bleibt zu nennen: ContentBlocks ist noch jung. Die Dokumentation wächst, Randfälle in komplexeren TCA-Konfigurationen erfordern mitunter einen Blick in den Quellcode, und nicht alle Integrationspunkte zu Third-Party-Extensions sind bereits vollständig abgebildet. Ein Argument gegen ContentBlocks ist das nicht — aber ein Grund, die Entwicklung aufmerksam zu verfolgen und bei neuen Projekten frühzeitig Erfahrungen zu sammeln, statt zu warten, bis das Ökosystem noch weiter gewachsen ist.
Wo wir heute stehen
Neue Projekte setzen wir auf ContentBlocks. Nicht weil es das Neueste ist, sondern weil es das Richtige ist: versionierbar, klar strukturiert, ohne Extension-Abhängigkeit im kritischen Pfad, mit offizieller Core-Unterstützung. Die Entscheidung fiel nicht aus Überzeugung auf dem Papier, sondern aus dem direkten Vergleich mit dem, was davor war — und aus dem Wissen, was Migrationsprojekte wirklich kosten.
Parallel betreuen wir weiterhin Projekte auf MASK- und Gridelements-Basis. Diese Systeme funktionieren — sie haben nur einen anderen Preis, der sich beim nächsten TYPO3-Hauptrelease zeigt. Migrationen planen wir nicht erzwungen, sondern dort, wo der Nutzen konkret ist: wenn ein Gridelements-Upgrade aufwendiger wird als eine Migration zu Backend-Layouts, wenn ein MASK-Projekt so weit wächst, dass fehlende Versionierbarkeit zum echten Engpass wird.
Die Frage, die wir uns bei jedem neuen Projekt stellen, lautet: Was kostet diese Templating-Entscheidung beim nächsten Upgrade? TemplaVoilà hat gezeigt, was passiert, wenn diese Frage zu lange aufgeschoben wird. ContentBlocks gibt darauf heute eine bessere Antwort als alle Vorgänger — nicht, weil es keinen Preis hat, sondern weil der Preis kleiner ist und vor allem vorhersehbar.
