DCE para TYPO3

DCE foi por anos a primeira escolha para Custom Content Elements - agora a migração é necessária

A partir de 2012, o DCE (Dynamic Content Elements) foi um dos métodos mais difundidos para construir elementos de conteúdo próprios no TYPO3. Editores recebiam formulários de backend com exatamente os campos necessários, desenvolvedores definiam tudo via GUI, sem escrever uma linha de PHP ou TCA. Milhares de sites TYPO3 ainda rodam com DCE. O problema: o desenvolvimento desacelerou significativamente. Mask ultrapassou DCE em uso, e para o TYPO3 v13 e v14, com a extensão Content Blocks, existe uma terceira alternativa.

Quem tem DCE em uso não precisa migrar imediatamente. Mas quem planeja um upgrade TYPO3 para v12 ou v13 deve planejar a substituição, pois o DCE é mantido essencialmente por um único desenvolvedor.

Cenários típicos de uso

Projetos existentes com 10 a 50 elementos DCE. Sites corporativos de médio porte construídos entre 2014 e 2020 com TYPO3 v7 a v10 usam DCE para tudo: caixas de teaser, abas, acordeões, galerias de imagens, blocos de citação, cartões de equipe. Os elementos funcionam, mas estão vinculados ao DCE. Em um upgrade TYPO3, é necessário verificar se o DCE roda na versão alvo.

Agências com múltiplos projetos TYPO3. Agências que usaram DCE como padrão em seus projetos enfrentam a questão: migramos todos os projetos de uma vez (grande esforço, corte limpo) ou projeto por projeto no próximo upgrade (passos menores, período mais longo)? A resposta depende do número de projetos afetados e da versão TYPO3 alvo planejada.

Prototipagem rápida para elementos de conteúdo. DCE é adequado para protótipos rápidos: um novo elemento de conteúdo é configurado em 15 minutos, incluindo formulário de backend e template Fluid. Para provas de conceito ou apresentações a clientes, isso pode ser suficiente. Para projetos produtivos, a Gosign recomenda Mask, pois a configuração versionável (mask.json no site package) e a manutenção ativa oferecem vantagens de longo prazo.

Arquitetura técnica

DCE armazena definições de elementos de conteúdo no banco de dados (tabela tx_dce_domain_model_dce), não em arquivos. Cada elemento DCE consiste em uma configuração (campos, tipos, validação), um template Fluid (diretamente no backend ou como referência de arquivo) e um template para a pré-visualização no backend. Os campos são definidos na GUI do DCE: Text, RichText, Integer, Float, Date, File (FAL), Select, Checkbox, Group, Inline (IRRE), Section (fieldsets repetíveis).

Depois de salvar e limpar o cache do sistema, o DCE gera a configuração TCA necessária e registra o elemento no Content Element Wizard. Os dados dos elementos de conteúdo ficam na tabela tt_content, estendida por campos FlexForm específicos do DCE. Essa arquitetura FlexForm é uma das principais diferenças para o Mask, que cria colunas de banco de dados próprias no tt_content.

Problemas frequentes e soluções

Dados FlexForm são difíceis de migrar. Como DCE armazena dados como XML FlexForm no tt_content, uma migração para Mask (que usa colunas próprias) não é trivial. O XML FlexForm deve ser parseado e os valores transferidos para os novos campos Mask. Solução: um script de migração que, por elemento DCE, lê os campos FlexForm e os escreve nos campos Mask correspondentes. A Gosign possui um comando CLI reutilizável que automatiza esse processo por elemento.

Containers DCE e elementos aninhados. DCE oferece uma lógica de container própria que envolve em um template comum os elementos consecutivos do mesmo DCE. Essa lógica é proprietária e não é compreendida por nenhum outro sistema. Solução na migração: converter estruturas de container para b13/container e reconstruir os elementos filhos como elementos Mask.

Performance com muitas definições DCE. Sites com mais de 40 elementos DCE têm tempos de carregamento perceptíveis no backend, quando o DCE gera de novo, a partir do banco de dados, o código de todos os elementos depois que o cache do sistema é limpo. Solução: aquecer o cache do sistema após o deploy com cache:flush --group system e cache:warmup --group system; o cache de código do DCE já fica sempre ativo.

Migração e compatibilidade de versões

O DCE 2.9 suporta TYPO3 v9.5 a v11 e o DCE 3.3 TYPO3 v12 e v13, ambos como versões estáveis. O DCE 4.0.0 suporta o TYPO3 v14 desde agosto de 2026.

Para a migração de DCE para Mask, a Gosign tem um processo padronizado: inventariar elementos DCE (campos, tipos, templates), reconstruir elementos Mask 1:1, migrar dados via script SQL (FlexForm XML para colunas Mask), adaptar templates Fluid, testar e desinstalar DCE. O esforço fica entre 0,5 e 2 horas por elemento, dependendo da complexidade. Um projeto com 25 elementos DCE é migrado em 3 a 5 dias.

A Gosign recomenda na decisão de migração uma análise pragmática de custo-benefício. Se o próximo upgrade TYPO3 está previsto para dentro de 12 meses e o DCE não roda de forma estável na versão alvo, a migração é inevitável. Se o projeto permanecerá mais 2 a 3 anos no TYPO3 v11 ou v12 e o DCE funciona de forma estável ali, a migração pode ser adiada para o próximo relançamento. Em todo caso, deve-se definir já agora se o alvo é Mask ou Content Block API, para que novos elementos de conteúdo sejam criados diretamente no sistema alvo.

Os custos totais de uma migração DCE dependem da quantidade e complexidade dos elementos. Um projeto com 15 elementos DCE simples (texto, imagem, link) é migrado em 2 dias. Um projeto com 40 elementos, dos quais 10 com aninhamento IRRE e 5 com lógica de container, precisa de 8 a 12 dias.