DCE für TYPO3

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

Zwischen 2013 und 2020 war DCE (Dynamic Content Elements) neben Mask die populärste Methode, 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 ab TYPO3 v13 steht mit dem nativen Content Block API eine dritte Alternative bereit, die keinen Extension-Overhead mehr benötigt.

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 der langfristige Support unsicher ist.

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ässig in ihren Projekten eingesetzt haben, stehen vor der Frage: Migrieren wir alle Projekte auf einmal (grosser 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 der Export-Workflow (mask_export) 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 optionalen Backend-Layouts. Die Felder werden in der DCE-GUI definiert: Text, RichText, Integer, Float, Datum, Datei (FAL), Select, Checkbox, Gruppe (IRRE), Section (wiederholbare Fieldsets).

Beim Speichern 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 kann DCE Container-Elemente erstellen (verschachtelte Content-Bereiche), was aber seit der Einführung der Container-Extension (b13/container) als separater Ansatz empfohlen wird.

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 Content-Elemente ineinander verschachtelt. 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, weil alle FlexForm-Konfigurationen bei jedem Aufruf aus der Datenbank gelesen und geparst werden. Lösung: DCE-Caching aktivieren (TypoScript-Setting plugin.tx_dce.enableCache = 1) oder auf dateibasierte Konfiguration umstellen (DCE-Export-Funktion).

Migration und Versions-Kompatibilität

DCE unterstützt TYPO3 v11 und v12. Die Kompatibilität mit TYPO3 v13 ist eingeschränkt: Es gibt einen Entwicklungszweig, aber keinen offiziell als stabil markierten Release (Stand April 2026). Die Community-Pflege ist weniger aktiv als bei Mask, wo in2code als Hauptentwickler einen klaren Release-Zyklus verfolgt.

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 das native Content Block API 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.