In der Webentwicklung gibt es seit Jahren einen Trend zu sogenannten Headless-Architekturen: Das CMS liefert nur noch Daten über eine API, ein separates Frontend-Framework wie Next.js oder Nuxt rendert die Ausgabe. Modular, komponentenbasiert, flexibel. Klingt gut — aber ist es für die meisten TYPO3-Projekte wirklich notwendig? Wir meinen: nein. Und die Extension content_blocks zeigt warum.
content_blocks ist eine TYPO3 Extension, die eine neue API zur Erstellung eigener Content-Typen bietet — Content Elements, Page Types und Record Types. Sie ist für TYPO3 v13 und v14 verfügbar und soll perspektivisch in den TYPO3 Core v15 LTS einfließen.
Für viele, die bisher mit der Extension Mask gearbeitet haben, ist das eine wichtige Information: Mask wird nicht mehr weiterentwickelt — Bugfixes gab es noch bis April 2026, eine Unterstützung für TYPO3 v14 ist nicht geplant. Content Blocks ist der klare Nachfolger.
Das Prinzip ist schnell erklärt: Jedes Content Element lebt in einem eigenen Ordner — mit einer YAML-Datei für die Felddefinition, einem Fluid-Template für die Ausgabe, und optional eigenen CSS- und JavaScript-Dateien nur für dieses Element. Die TCA-Konfiguration wird automatisch aus der YAML-Datei generiert, eine CLI legt neue Elemente per Befehl als fertiges Grundgerüst an. Eine grafische Oberfläche für TYPO3 v13 ist in Entwicklung — wer lieber visuell arbeitet als YAML zu schreiben, bekommt damit ein echtes Werkzeug.
Wer mit React, Vue oder Angular entwickelt, kennt das Prinzip: Eine Komponente ist eine in sich geschlossene Einheit. Sie bringt ihre eigene Logik, ihr eigenes Markup und ihre eigenen Styles mit — und lässt sich überall dort einsetzen, wo sie gebraucht wird, ohne dass sie von anderen Elementen abhängt.
Content Blocks denkt genauso. Ein Content Block ist eine eigenständige, wiederverwendbare Einheit. Er bringt sein eigenes Template mit, seine eigene Felddefinition und seine eigenen Assets. Er ist isoliert entwickelbar, unabhängig testbar und ohne Seiteneffekte auf andere Elemente einsetzbar.
Der Unterschied zu klassischer TYPO3-Entwicklung: Bisher wurden Content Elemente verstreut über TCA-Konfigurationen, TypoScript und Fluid-Partials definiert — die Zusammenhänge existierten nur im Kopf des Entwicklers. Mit Content Blocks gehört alles, was ein Element ausmacht, in einen einzigen Ordner. Das ist konzeptionell exakt das, was Storybook für Frontend-Komponenten leistet: Isolation und Dokumentation in einem.
Headless-Architekturen haben ihren Platz — vor allem dort, wo ein und dasselbe Content-Repository mehrere Ausgabekanäle bedienen muss: Website, App, Newsletter. In solchen Szenarien macht eine API-basierte Entkopplung von CMS und Frontend echten Sinn.
Für die meisten B2B-Websites, Unternehmensauftritte und Portale — also genau die Projekte, die wir bei Müller New Media betreuen — ist das nicht der Fall. Hier gibt es einen Ausgabekanal: die Website. Und für diesen Kanal ist eine Headless-Architektur vor allem eines: zusätzliche Komplexität.
Zwei separate Systeme müssen deployed, gewartet und aufeinander abgestimmt werden. Redakteure arbeiten im CMS, sehen das Ergebnis aber erst nach einem Build-Prozess im Frontend. Hydration, Caching-Strategien und API-Performance werden zu eigenen Projekten. Der Entwicklungsaufwand steigt — der Nutzen für den Kunden bleibt gleich.
Content Blocks löst das eigentliche Problem, das Headless-Systeme attraktiv gemacht hat — die fehlende Modularität auf CMS-Seite — direkt in TYPO3. Der Entwickler arbeitet in klar strukturierten, isolierten Einheiten. Der Redakteur arbeitet im vertrauten TYPO3-Backend. Die Ausgabe ist serverseitig gerendert, mit TYPO3-Caching schnell, und es gibt kein zweites System, das gepflegt werden muss.
TYPO3 v14 unterstützt Headless-APIs — das ist gut, weil es die Flexibilität erhöht. Aber Flexibilität bedeutet nicht, dass man jede Möglichkeit nutzen muss. Für die meisten Projekte ist TYPO3 mit Content Blocks die sauberere, schlankere und wirtschaftlichere Lösung.
Content Blocks steht noch am Anfang seiner Verbreitung — aber die Richtung ist klar. Wer heute neue TYPO3-Projekte auf v13 oder v14 aufsetzt, sollte Content Blocks von Anfang an mitdenken. Und wer Mask im Einsatz hat, sollte die Migration nicht zu lange aufschieben.