Content Blocks Inhaltselemente, die zur Redaktion passen

Content Blocks ist eine Extension für TYPO3, mit der sich eigene Inhaltselemente, Seitentypen und Datensätze anlegen lassen. Entwickelt wird sie vom Content Types Team der TYPO3-Community gemeinsam mit dem Core-Team, das Paket heißt friendsoftypo3/content-blocks.

Jedes Inhaltselement bekommt einen eigenen Ordner. Darin liegen eine Datei config.yaml mit den Feldern, das Fluid-Template für die Website, auf Wunsch eine eigene Vorschau für das Backend, die Beschriftungen für die Redaktion und ein Icon:

Aus diesem Ordner erzeugt Content Blocks alles, was TYPO3 für ein Inhaltselement braucht: die Feldkonfiguration im TCA, die Datenbankfelder, das TypoScript für die Ausgabe und den Eintrag im Assistenten für neue Inhaltselemente. Ein Element lässt sich deshalb als Ordner in ein anderes Projekt kopieren und steht dort sofort zur Verfügung.

Die config.yaml legt fest, welche Felder ein Element hat. Für ein Akkordeon reichen eine Überschrift und beliebig viele Einträge mit Titel und Text:

Die Überschrift nutzt das Feld header, das jedes Inhaltselement in TYPO3 ohnehin hat. Die Einträge sind eine Collection: Die Redaktion legt so viele an, wie sie braucht, und sortiert sie per Drag-and-drop. Der Titel ist Pflicht, der Text bekommt den Rich-Text-Editor. In der labels.xlf stehen die deutschen Beschriftungen, und das Fluid-Template greift direkt auf die Felder zu.

Für die Entwicklung ist das angenehm kompakt. Dazu kommt ein JSON-Schema: Beim Schreiben der config.yaml schlägt die Entwicklungsumgebung damit Feldtypen und Optionen vor.

Ein Inhaltselement aus Content Blocks zeigt im Backend die Felder, die zu genau diesem Inhalt gehören. Ein Teaser hat ein Bild, eine Überschrift, einen kurzen Text und einen Link. Ein Akkordeon hat Fragen und Antworten. Das Formular bleibt übersichtlich, weil es nur anbietet, was das Design auch darstellt.

Pflichtfelder, Hilfetexte unter den Feldern und eine kurze Beschreibung im Assistenten für neue Inhaltselemente erleichtern die Auswahl. Die Backend-Vorschau zeigt im Seitenmodul, was in einem Element steckt, ohne es zu öffnen. Mehrsprachigkeit und Benutzerrechte funktionieren wie bei den Standardelementen von TYPO3: Für jede Gruppe lässt sich festlegen, welche Elemente und Felder sie nutzen darf.

In meinen Projekten entwickle ich die Inhaltselemente als Content Blocks, passend zu den Inhalten und zum Design der jeweiligen Website. Auf den Websites von Stadtwerken bekommen so auch wiederkehrende Inhalte wie Störungen, Preisblätter oder Stellenanzeigen eigene Eingabemasken.

Ohne Hilfsmittel verteilt sich ein eigenes Inhaltselement auf mehrere Stellen einer Extension: die Feldkonfiguration im TCA, die Datenbankfelder in der ext_tables.sql, TypoScript für die Ausgabe, der Eintrag im Assistenten, dazu Template und Sprachdateien. Das ist übrigens bis heute der Weg, den der Core selbst geht. Content Blocks bündelt genau diese Einträge in einem Ordner und erzeugt sie beim Laden.

Mask hat das Anlegen eigener Elemente in eine Oberfläche im Backend verlegt. Die Felder werden dort zusammengestellt, die Konfiguration landet in einer Datei mask.json. Content Blocks folgt in vielen Punkten der Architektur von Mask und gilt als dessen Nachfolger. Mask selbst ist seit TYPO3 v13 als veraltet markiert und bekam Fehlerkorrekturen bis zum Ende der regulären Wartung von TYPO3 v13 am 30. April 2026. Offizielle Pläne für TYPO3 v14 gibt es keine.

DCE (Dynamic Content Elements) definiert Elemente ebenfalls im Backend und speichert die Inhalte als FlexForm, also als XML in einem einzigen Datenbankfeld. Ähnlich arbeiten Flux und, aus den frühen Jahren von TYPO3, TemplaVoilà, das zusätzlich die Seitentemplates verwaltete. DCE und Flux werden weiter gepflegt und laufen auch mit TYPO3 v14. Content Blocks legt dagegen für jedes Feld eine eigene Spalte und für Collections eine eigene Tabelle an. Die Inhalte sind dadurch einfacher auszuwerten, zu übersetzen und später zu migrieren.

Ursprünglich sollte Content Blocks fest in TYPO3 einziehen. 2024 haben sich das Core-Team und das Content Types Team für einen anderen Weg entschieden: Einzelne Bausteine wandern in den Core, die Extension bleibt eigenständig. Seit TYPO3 v13 enthält der Core unter anderem die Record API, auf der Content Blocks seit Version 1.0 aufbaut.

Stand Oktober 2026 gibt es Content Blocks in zwei Linien: Version 2 für TYPO3 v14 und Version 1 für TYPO3 v13. Beide bekommen regelmäßig Updates. In TYPO3 v14 bleibt Content Blocks eine eigene Extension, an weiteren Schritten in Richtung Core für TYPO3 v15 arbeitet das Team. Dazugekommen ist 2026 die Extension Content Blocks GUI, mit der sich Elemente in einer Oberfläche zusammenstellen lassen. Das Ergebnis sind wieder Dateien, die in die Versionsverwaltung wandern.

Weil jedes Element aus Dateien in einer Extension besteht, liegt es in der Versionsverwaltung. Änderungen an einem Element sind nachvollziehbar, lassen sich auf einer Testumgebung prüfen und gehen mit dem nächsten Deployment live. Auf Staging und Live läuft damit immer dieselbe Definition.

Für ein Upgrade heißt das: Die eigenen Elemente bestehen aus Konfiguration und Fluid-Templates, eigener PHP-Code gehört nicht dazu. Mit dem Wechsel auf eine neue TYPO3-Version kommt die passende Version von Content Blocks, beim Sprung von TYPO3 v13 auf v14 also Version 2 statt Version 1. Was sich dabei ändert, dokumentiert das Changelog der Extension.

Bei Websites mit Mask hilft das Migrationswerkzeug mask-to-content-blocks. Es erzeugt aus der mask.json gleichwertige Content Blocks, die vorhandenen Daten bleiben unverändert in der Datenbank. Die Templates werden übernommen und brauchen gelegentlich Nacharbeit. Bei Elementen aus DCE, Flux oder TemplaVoilà ziehen die Inhalte aus dem XML in eigene Felder um. Diese Datenmigration gehört in die Planung des Upgrades, genauso wie der Umstieg von Mask, wenn das Ziel TYPO3 v14 ist. Wie ich gewachsene Installationen einordne, beschreibe ich unter TYPO3-Website übernehmen.