DCE dla TYPO3

DCE przez lata było pierwszym wyborem dla Custom Content Elements - teraz czas na migrację

Od 2012 roku DCE (Dynamic Content Elements) było jedną z najczęściej stosowanych metod tworzenia własnych elementów treści w TYPO3. Redaktorzy dostawali formularze backendowe z dokładnie takimi polami, jakich potrzebowali, programiści definiowali wszystko przez GUI - bez jednej linii PHP czy TCA. Tysiące witryn TYPO3 nadal działają na DCE. Problem: dalszy rozwój znacznie spowolnił. Mask prześcignął DCE pod względem użycia, a dla TYPO3 v13 i v14 dostępna jest z rozszerzeniem Content Blocks trzecia alternatywa.

Kto ma DCE w użyciu, nie musi migrować natychmiast. Ale kto planuje aktualizację TYPO3 do v12 lub v13, powinien uwzględnić migrację, ponieważ DCE w praktyce utrzymuje jeden deweloper.

Typowe scenariusze zastosowań

Istniejące projekty z 10 do 50 elementami DCE. Witryny firm średniej wielkości, budowane między 2014 a 2020 na TYPO3 v7 do v10, używają DCE do wszystkiego: boksów teaserowych, zakładek, akordeonów, galerii, bloków cytatów, kart zespołu. Elementy działają, ale są związane z DCE. Przy aktualizacji TYPO3 trzeba sprawdzić, czy DCE jeszcze działa w docelowej wersji.

Agencje z wieloma projektami TYPO3. Agencje, które standardowo stosowały DCE w swoich projektach, stoją przed pytaniem: migrujemy wszystkie projekty naraz (duży nakład, czyste cięcie) czy projekt po projekcie przy następnej aktualizacji (mniejsze kroki, dłuższy okres)? Odpowiedź zależy od liczby dotkniętych projektów i planowanej docelowej wersji TYPO3.

Rapid Prototyping elementów treści. DCE nadaje się do szybkich prototypów: nowy element treści jest skonfigurowany w 15 minut, włącznie z formularzem backendowym i szablonem Fluid. Do proof-of-concept czy prezentacji klienckich to może wystarczyć. Dla produktywnych projektów Gosign zaleca jednak Mask, ponieważ wersjonowalna konfiguracja (mask.json w site package) i aktywna pielęgnacja oferują długoterminowe korzyści.

Architektura techniczna

DCE przechowuje definicje elementów treści w bazie danych (tabela tx_dce_domain_model_dce), nie w plikach. Każdy element DCE składa się z konfiguracji (pola, typy, walidacja), szablonu Fluid (bezpośrednio w backendzie lub jako odwołanie do pliku) i szablonu podglądu w backendzie. Pola są definiowane w GUI DCE: Text, RichText, Integer, Float, Date, File (FAL), Select, Checkbox, Group, Inline (IRRE), Section (powtarzalne fieldsets).

Po zapisie i wyczyszczeniu cache systemowego DCE generuje potrzebną konfigurację TCA i rejestruje element w Content Element Wizard. Dane elementów treści leżą w tabeli tt_content, rozszerzonej o specyficzne pola FlexForm DCE. Ta architektura FlexForm jest jedną z głównych różnic wobec Mask, który tworzy własne kolumny bazy danych w tt_content.

Częste problemy i rozwiązania

Dane FlexForm są trudne do migracji. Ponieważ DCE przechowuje dane jako XML FlexForm w tt_content, migracja na Mask (który używa własnych kolumn) nie jest trywialna. XML FlexForm musi być sparsowany, a wartości przeniesione do nowych kolumn Mask. Rozwiązanie: skrypt migracyjny, który per element DCE odczytuje pola FlexForm i zapisuje je w odpowiednich polach Mask. Gosign ma do tego wielokrotnego użytku CLI-Command, który automatyzuje proces per element.

Kontenery DCE i zagnieżdżone elementy. DCE oferuje własną logikę kontenerową, która obejmuje wspólnym szablonem kolejne elementy tego samego DCE. Ta logika jest własnościowa i nie jest rozumiana przez żaden inny system. Rozwiązanie przy migracji: przejście struktur kontenerowych na b13/container i odtworzenie elementów podrzędnych jako elementów Mask.

Wydajność przy wielu definicjach DCE. Witryny z ponad 40 elementami DCE mają odczuwalne czasy ładowania backendu, gdy DCE po wyczyszczeniu cache systemowego ponownie generuje z bazy danych kod wszystkich elementów. Rozwiązanie: rozgrzanie cache systemowego po wdrożeniu przez cache:flush --group system i cache:warmup --group system; cache kodu DCE jest i tak zawsze aktywny.

Migracja i kompatybilność wersji

DCE 2.9 wspiera TYPO3 v9.5 do v11, a DCE 3.3 TYPO3 v12 i v13, w obu przypadkach jako stabilne wydania. DCE 4.0.0 wspiera od sierpnia 2026 TYPO3 v14. Pielęgnacja społecznościowa jest mniej aktywna niż przy Mask, gdzie Nikita Hovratov i Gernot Ploiner (WEBprofil) jako główni deweloperzy prowadzą jasny cykl wydań.

Do migracji z DCE na Mask Gosign ma zestandaryzowany proces: inwentaryzacja elementów DCE (pola, typy, szablony), odtworzenie elementów Mask 1:1, migracja danych przez skrypt SQL (FlexForm-XML do kolumn Mask), dostosowanie szablonów Fluid (wywołania ViewHelper i nazwy zmiennych częściowo się zmieniają), testy i deinstalacja DCE. Nakład to od 0,5 do 2 godzin per element, w zależności od złożoności. Projekt z 25 elementami DCE jest zmigrowany w 3 do 5 dni.

Gosign zaleca przy decyzji migracyjnej pragmatyczny rachunek kosztów i korzyści. Jeśli następna aktualizacja TYPO3 jest planowana w ciągu 12 miesięcy i DCE nie działa stabilnie w docelowej wersji, migracja jest bezalternatywna. Jeśli projekt ma zostać na TYPO3 v11 lub v12 jeszcze 2 do 3 lat i DCE tam stabilnie funkcjonuje, migrację można przesunąć na następny relaunch. W każdym przypadku już teraz należy ustalić, czy Mask czy Content Block API jest celem, aby nowe elementy treści były tworzone bezpośrednio w systemie docelowym i nie powstawały dalsze zależności DCE.