DCE para TYPO3

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

A partir de 2012, DCE (Dynamic Content Elements) fue uno de los métodos más extendidos 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 para TYPO3 v13 y v14 está disponible la extensión Content Blocks, una tercera alternativa.

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 DCE lo mantiene básicamente un único desarrollador.

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 de la configuración versionable (mask.json en el site package) 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 una plantilla para la vista previa en el backend. Los campos se definen en la GUI de DCE: Text, RichText, Integer, Float, Fecha, Archivo (FAL), Select, Checkbox, Grupo, Inline (IRRE), Section (fieldsets repetibles).

Tras guardar y vaciar la caché del sistema, 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 envuelve en una plantilla común los elementos consecutivos del mismo DCE. 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, cuando DCE vuelve a generar desde la base de datos el código de todos los elementos tras vaciar la caché del sistema. Solución: precalentar la caché del sistema tras el despliegue con cache:flush --group system y cache:warmup --group system; DCE mantiene su caché de código siempre activa.

Migración y compatibilidad de versiones

DCE 2.9 es compatible con TYPO3 v9.5 a v11 y DCE 3.3 con TYPO3 v12 y v13, ambos como versiones estables. DCE 4.0.0 es compatible con TYPO3 v14 desde agosto de 2026. El mantenimiento comunitario es menos activo que en Mask, donde Nikita Hovratov y Gernot Ploiner (WEBprofil) como desarrolladores principales siguen 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.