DCE für TYPO3

DCE war jahrelang die erste Wahl für Custom Content Elements, jetzt steht die Migration an

Ab 2012 war DCE (Dynamic Content Elements) eine der verbreitetsten Methoden, um eigene Content-Elemente in TYPO3 zu bauen. Redakteure bekamen Backend-Formulare mit genau den Feldern, die sie brauchten, Entwickler definierten alles per GUI, ohne eine Zeile PHP oder TCA zu schreiben. Tausende TYPO3-Websites laufen noch heute mit DCE. Das Problem: Die Weiterentwicklung hat sich deutlich verlangsamt. Mask hat DCE in der Nutzung überholt, und für TYPO3 v13 und v14 steht mit der Extension Content Blocks eine dritte Alternative bereit.

Wer DCE im Einsatz hat, muss nicht sofort migrieren. Aber wer ein TYPO3-Upgrade auf v12 oder v13 plant, sollte die Ablösung einplanen, weil DCE im Kern ein einzelner Entwickler pflegt.

Typische Einsatzszenarien

Bestandsprojekte mit 10 bis 50 DCE-Elementen. Mittelständische Unternehmenswebsites, die zwischen 2014 und 2020 mit TYPO3 v7 bis v10 aufgebaut wurden, nutzen DCE für alles: Teaser-Boxen, Tabs, Akkordeons, Bildergalerien, Zitat-Blöcke, Team-Karten. Die Elemente funktionieren, sind aber an DCE gebunden. Bei einem TYPO3-Upgrade muss geprüft werden, ob DCE in der Zielversion noch läuft.

Agenturen mit mehreren TYPO3-Projekten. Agenturen, die DCE standardmäßig in ihren Projekten eingesetzt haben, stehen vor der Frage: Migrieren wir alle Projekte auf einmal (großer Aufwand, sauberer Schnitt) oder projekt-für-projekt beim nächsten Upgrade (kleinere Schritte, längerer Zeitraum)? Die Antwort hängt von der Anzahl der betroffenen Projekte und der geplanten TYPO3-Zielversion ab.

Rapid Prototyping für Content-Elemente. DCE eignet sich für schnelle Prototypen: Ein neues Content-Element ist in 15 Minuten konfiguriert, inklusive Backend-Formular und Fluid-Template. Für Proof-of-Concepts oder Kundenpräsentationen kann das ausreichen. Für produktive Projekte empfiehlt Gosign allerdings Mask, weil die versionierbare Konfiguration (mask.json im Sitepackage) und die aktive Pflege langfristige Vorteile bieten.

Technische Architektur

DCE speichert Content-Element-Definitionen in der Datenbank (Tabelle tx_dce_domain_model_dce), nicht in Dateien. Jedes DCE-Element besteht aus einer Konfiguration (Felder, Typen, Validierung), einem Fluid-Template (direkt im Backend oder als Dateiverweis) und einem Template für die Backend-Vorschau. Die Felder werden in der DCE-GUI definiert: Text, RichText, Integer, Float, Datum, Datei (FAL), Select, Checkbox, Gruppe, Inline (IRRE), Section (wiederholbare Fieldsets).

Nach dem Speichern und dem Leeren des Systemcaches generiert DCE die nötige TCA-Konfiguration und registriert das Element im Content Element Wizard. Die Daten der Content-Elemente liegen in der tt_content-Tabelle, erweitert um DCE-spezifische FlexForm-Felder. Diese FlexForm-Architektur ist einer der Hauptunterschiede zu Mask, das eigene Datenbank-Spalten in tt_content anlegt.

Abhängigkeiten: DCE benötigt nur den TYPO3 Core. Optional fasst DCE aufeinanderfolgende Elemente desselben DCE in einem Container zusammen, etwa für Slider; für verschachtelte Content-Bereiche unterstützt DCE die Container-Extension (b13/container).

Häufige Probleme und Lösungen

FlexForm-Daten sind schwer zu migrieren. Weil DCE Daten als XML-FlexForm in tt_content speichert, ist eine Migration auf Mask (das eigene Spalten nutzt) nicht trivial. Die FlexForm-XML muss geparst und die Werte in die neuen Mask-Spalten überführt werden. Lösung: Ein Migrations-Skript, das pro DCE-Element die FlexForm-Felder ausliest und in die entsprechenden Mask-Felder schreibt. Gosign hat dafür ein wiederverwendbares CLI-Command, das den Prozess pro Element automatisiert.

DCE-Container und verschachtelte Elemente. DCE bietet eine eigene Container-Logik, die aufeinanderfolgende Elemente desselben DCE mit einem gemeinsamen Template umschließt. Diese Logik ist proprietär und wird von keinem anderen System verstanden. Lösung bei Migration: Container-Strukturen auf b13/container umstellen und die Kind-Elemente als Mask-Elemente nachbauen.

Performance bei vielen DCE-Definitionen. Websites mit 40+ DCE-Elementen haben spürbare Backend-Ladezeiten, wenn DCE den Code aller Elemente nach dem Leeren des Systemcaches neu aus der Datenbank erzeugt. Lösung: Den Systemcache nach dem Deployment mit cache:flush --group system und cache:warmup --group system vorwärmen; den Code-Cache hält DCE ohnehin immer aktiv.

Migration und Versions-Kompatibilität

DCE 2.9 unterstützt TYPO3 v9.5 bis v11, DCE 3.3 TYPO3 v12 und v13, beide als stabile Versionen. DCE 4.0.0 unterstützt seit August 2026 TYPO3 v14. Die Community-Pflege ist weniger aktiv als bei Mask, wo Nikita Hovratov und Gernot Ploiner (WEBprofil) als Hauptentwickler einen klaren Release-Zyklus verfolgen.

Für die Migration von DCE auf Mask hat Gosign einen standardisierten Prozess: DCE-Elemente inventarisieren (Felder, Typen, Templates), Mask-Elemente 1:1 nachbauen, Daten per SQL-Skript migrieren (FlexForm-XML zu Mask-Spalten), Fluid-Templates anpassen (ViewHelper-Aufrufe und Variable-Namen ändern sich teilweise), testen und DCE deinstallieren. Der Aufwand liegt bei 0,5 bis 2 Stunden pro Element, je nach Komplexität. Ein Projekt mit 25 DCE-Elementen ist in 3 bis 5 Tagen migriert.

Alternativ können Projekte auf TYPO3 v13 direkt auf die Extension Content Blocks umsteigen. Das setzt allerdings voraus, dass die Zielversion v13 ist und keine Abwärtskompatibilität zu v11/v12 benötigt wird.

Gosign empfiehlt bei der Migrationsentscheidung eine pragmatische Kosten-Nutzen-Rechnung. Wenn das nächste TYPO3-Upgrade innerhalb von 12 Monaten ansteht und DCE auf der Zielversion nicht stabil läuft, ist die Migration alternativlos. Wenn das Projekt noch 2 bis 3 Jahre auf TYPO3 v11 oder v12 bleiben soll und DCE dort stabil funktioniert, kann die Migration auf den nächsten Relaunch verschoben werden. In jedem Fall sollte schon jetzt festgelegt werden, ob Mask oder das Content Block API das Ziel ist, damit neue Content-Elemente direkt im Ziel-System erstellt werden und nicht weitere DCE-Abhängigkeiten entstehen.

Die Gesamtkosten einer DCE-Migration hängen von der Anzahl und Komplexität der Elemente ab. Ein Projekt mit 15 einfachen DCE-Elementen (Text, Bild, Link) ist in 2 Tagen migriert. Ein Projekt mit 40 Elementen, davon 10 mit IRRE-Verschachtelung und 5 mit Container-Logik, braucht 8 bis 12 Tage.