DCE para TYPO3

DCE fue durante años la primera opción para Custom Content Elements, ahora toca migrar

Entre 2013 y 2020, DCE (Dynamic Content Elements) fue junto con Mask el método más popular para crear elementos de contenido propios en TYPO3. Los editores obtenían formularios de backend con los campos exactos que necesitaban; los desarrolladores definían todo mediante GUI, sin escribir una línea de PHP o TCA. Miles de webs TYPO3 siguen funcionando hoy con DCE. El problema: el desarrollo se ha ralentizado considerablemente. Mask ha superado a DCE en adopción, y a partir de TYPO3 v13 está disponible la Content Block API nativa, una tercera alternativa que no requiere overhead de extensión.

Quien tiene DCE en producción no necesita migrar de inmediato. Pero quien planifique una actualización de TYPO3 a v12 o v13 debería incluir la sustitución en su plan, ya que el soporte a largo plazo es incierto.

Escenarios de uso habituales

Proyectos existentes con 10 a 50 elementos DCE. Webs corporativas de empresas medianas construidas entre 2014 y 2020 con TYPO3 v7 a v10 usan DCE para todo: cajas teaser, pestañas, acordeones, galerías de imágenes, bloques de citas, tarjetas de equipo. Los elementos funcionan, pero están vinculados a DCE. En una actualización de TYPO3 hay que verificar si DCE funciona en la versión destino.

Agencias con múltiples proyectos TYPO3. Agencias que usaron DCE como estándar en sus proyectos se enfrentan a la pregunta: migrar todos los proyectos a la vez (gran esfuerzo, corte limpio) o proyecto por proyecto en la siguiente actualización (pasos más pequeños, período más largo). La respuesta depende del número de proyectos afectados y la versión TYPO3 objetivo.

Prototipado rápido para elementos de contenido. DCE sirve para prototipos rápidos: un nuevo elemento de contenido se configura en 15 minutos, incluyendo formulario de backend y plantilla Fluid. Para pruebas de concepto o presentaciones a clientes puede ser suficiente. Para proyectos productivos, Gosign recomienda Mask por las ventajas a largo plazo del flujo de exportación (mask_export) y el mantenimiento activo.

Arquitectura técnica

DCE almacena las definiciones de elementos de contenido en la base de datos (tabla tx_dce_domain_model_dce), no en archivos. Cada elemento DCE consta de una configuración (campos, tipos, validación), una plantilla Fluid (directamente en el backend o como referencia a archivo) y layouts de backend opcionales. Los campos se definen en la GUI de DCE: Text, RichText, Integer, Float, Fecha, Archivo (FAL), Select, Checkbox, Grupo (IRRE), Section (fieldsets repetibles).

Al guardar, DCE genera la configuración TCA necesaria y registra el elemento en el Content Element Wizard. Los datos de los elementos se almacenan en la tabla tt_content, ampliada con campos FlexForm específicos de DCE. Esta arquitectura FlexForm es una de las diferencias principales con Mask, que crea columnas de base de datos propias en tt_content.

Problemas frecuentes y soluciones

Los datos FlexForm son difíciles de migrar. Como DCE almacena datos como XML FlexForm en tt_content, la migración a Mask (que usa columnas propias) no es trivial. El XML FlexForm debe parsearse y los valores transferirse a las nuevas columnas de Mask. Solución: un script de migración que, por elemento DCE, lee los campos FlexForm y los escribe en los campos Mask correspondientes. Gosign dispone de un comando CLI reutilizable que automatiza el proceso por elemento.

Contenedores DCE y elementos anidados. DCE ofrece una lógica de contenedor propia que anida elementos de contenido entre sí. Esta lógica es propietaria y ningún otro sistema la entiende. Solución en la migración: cambiar las estructuras de contenedor a b13/container y recrear los elementos hijo como elementos Mask.

Rendimiento con muchas definiciones DCE. Webs con más de 40 elementos DCE sufren tiempos de carga del backend notables, porque todas las configuraciones FlexForm se leen y parsean desde la base de datos en cada llamada. Solución: activar el caché de DCE (configuración TypoScript plugin.tx_dce.enableCache = 1) o cambiar a configuración basada en archivos (función de exportación DCE).

Migración y compatibilidad de versiones

DCE es compatible con TYPO3 v11 y v12. La compatibilidad con TYPO3 v13 es limitada: existe una rama de desarrollo pero no hay un release oficialmente marcado como estable (estado: abril 2026). El mantenimiento comunitario es menos activo que en Mask, donde in2code como desarrollador principal sigue un ciclo de releases claro.

Para la migración de DCE a Mask, Gosign tiene un proceso estandarizado: inventariar elementos DCE (campos, tipos, plantillas), recrear elementos Mask 1:1, migrar datos mediante script SQL (FlexForm XML a columnas Mask), adaptar plantillas Fluid (las llamadas a ViewHelper y nombres de variables cambian parcialmente), probar y desinstalar DCE. El esfuerzo es de 0,5 a 2 horas por elemento según complejidad. Un proyecto con 25 elementos DCE se migra en 3 a 5 días.

Gosign recomienda en la decisión de migración un cálculo pragmático de coste-beneficio. Si la próxima actualización de TYPO3 está prevista en los próximos 12 meses y DCE no funciona de forma estable en la versión objetivo, la migración es inevitable. Si el proyecto va a permanecer 2 a 3 años más en TYPO3 v11 o v12 y DCE funciona establemente allí, la migración puede posponerse al siguiente relanzamiento. En cualquier caso, debe decidirse ya si el destino es Mask o la Content Block API, para que los nuevos elementos de contenido se creen directamente en el sistema objetivo y no se generen más dependencias de DCE.