DCE for TYPO3

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

From 2012 onwards, DCE (Dynamic Content Elements) was one of the most widely used methods 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 for TYPO3 v13 and v14, the Content Blocks extension offers a third alternative.

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 DCE is essentially maintained by a single developer.

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 versionable configuration (mask.json in the site package) 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 a template for the backend preview. Fields are defined in the DCE GUI: Text, RichText, Integer, Float, Date, File (FAL), Select, Checkbox, Group, Inline (IRRE), Section (repeatable fieldsets).

After saving and clearing the system cache, 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 groups consecutive elements of the same DCE in a container, for example for sliders; for nested content areas, DCE supports the Container extension (b13/container).

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 wraps consecutive elements of the same DCE in a shared template. 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 when DCE regenerates the code of all elements from the database after the system cache has been cleared. Solution: warm up the system cache after deployment with cache:flush --group system and cache:warmup --group system; DCE keeps its code cache enabled at all times anyway.

Migration and version compatibility

DCE 2.9 supports TYPO3 v9.5 to v11 and DCE 3.3 supports TYPO3 v12 and v13, both as stable releases. DCE 4.0.0 has supported TYPO3 v14 since August 2026. Community maintenance is less active than with Mask, where Nikita Hovratov and Gernot Ploiner (WEBprofil) as the main developers follow 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 Content Blocks extension. 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.