DCE for TYPO3

DCE was the first choice for custom content elements for years - now it is time to migrate

Between 2013 and 2020, DCE (Dynamic Content Elements) was alongside Mask the most popular method for building custom content elements in TYPO3. Editors received backend forms with exactly the fields they needed, developers defined everything via GUI without writing a single line of PHP or TCA. Thousands of TYPO3 websites still run on DCE today. The problem: development has slowed significantly. Mask has overtaken DCE in usage, and starting with TYPO3 v13, the native Content Block API offers a third alternative that requires no extension overhead.

Those with DCE in production do not need to migrate immediately. But anyone planning a TYPO3 upgrade to v12 or v13 should plan the replacement, because long-term support is uncertain.

Typical use cases

Existing projects with 10 to 50 DCE elements. Mid-market corporate websites built between 2014 and 2020 with TYPO3 v7 through v10 use DCE for everything: teaser boxes, tabs, accordions, image galleries, quote blocks, team cards. The elements work but are tied to DCE. During a TYPO3 upgrade, it must be verified whether DCE still runs on the target version.

Agencies with multiple TYPO3 projects. Agencies that standardized on DCE across their projects face the question: migrate all projects at once (large effort, clean break) or project-by-project at the next upgrade (smaller steps, longer timeline)? The answer depends on the number of affected projects and the planned TYPO3 target version.

Rapid prototyping for content elements. DCE is well suited for quick prototypes: a new content element is configured in 15 minutes, including backend form and Fluid template. For proof-of-concepts or client presentations, this may suffice. For production projects, Gosign recommends Mask because the export workflow (mask_export) and active maintenance offer long-term advantages.

Technical architecture

DCE stores content element definitions in the database (table tx_dce_domain_model_dce), not in files. Each DCE element consists of a configuration (fields, types, validation), a Fluid template (directly in the backend or as a file reference) and optional backend layouts. Fields are defined in the DCE GUI: Text, RichText, Integer, Float, Date, File (FAL), Select, Checkbox, Group (IRRE), Section (repeatable fieldsets).

On save, DCE generates the necessary TCA configuration and registers the element in the Content Element Wizard. The data for content elements resides in the tt_content table, extended by DCE-specific FlexForm fields. This FlexForm architecture is one of the key differences from Mask, which creates its own database columns in tt_content.

Dependencies: DCE requires only the TYPO3 Core. Optionally, DCE can create container elements (nested content areas), though since the introduction of the Container extension (b13/container), this is recommended as a separate approach.

Common problems and solutions

FlexForm data is difficult to migrate. Because DCE stores data as XML FlexForm in tt_content, migration to Mask (which uses its own columns) is not trivial. The FlexForm XML must be parsed and the values transferred to the new Mask columns. Solution: a migration script that reads the FlexForm fields per DCE element and writes them into the corresponding Mask fields. Gosign has a reusable CLI command that automates this process per element.

DCE containers and nested elements. DCE offers its own container logic that nests content elements within each other. This logic is proprietary and understood by no other system. Solution for migration: convert container structures to b13/container and rebuild the child elements as Mask elements.

Performance with many DCE definitions. Websites with 40+ DCE elements experience noticeable backend loading times because all FlexForm configurations are read from the database and parsed with every call. Solution: activate DCE caching (TypoScript setting plugin.tx_dce.enableCache = 1) or switch to file-based configuration (DCE export function).

Migration and version compatibility

DCE supports TYPO3 v11 and v12. Compatibility with TYPO3 v13 is limited: there is a development branch but no release officially marked as stable (as of April 2026). Community maintenance is less active than with Mask, where in2code as the primary developer follows a clear release cycle.

For migrating from DCE to Mask, Gosign has a standardized process: inventory DCE elements (fields, types, templates), rebuild Mask elements 1:1, migrate data via SQL script (FlexForm XML to Mask columns), adapt Fluid templates (ViewHelper calls and variable names partially change), test and uninstall DCE. The effort is 0.5 to 2 hours per element depending on complexity. A project with 25 DCE elements is migrated in 3 to 5 days.

Alternatively, projects on TYPO3 v13 can switch directly to the native Content Block API. This requires the target version to be v13 with no backward compatibility to v11/v12 needed.

Gosign recommends a pragmatic cost-benefit analysis for the migration decision. If the next TYPO3 upgrade is within 12 months and DCE does not run stably on the target version, migration is unavoidable. If the project will remain on TYPO3 v11 or v12 for another 2 to 3 years and DCE functions stably there, migration can be deferred to the next relaunch. In either case, the target system - Mask or Content Block API - should be decided now, so new content elements are created directly in the target system and no further DCE dependencies accumulate.

Total migration costs depend on the number and complexity of elements. A project with 15 simple DCE elements (text, image, link) is migrated in 2 days. A project with 40 elements, 10 of them with IRRE nesting and 5 with container logic, requires 8 to 12 days.