DCE dla TYPO3

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

Między 2013 a 2020 rokiem DCE (Dynamic Content Elements) obok Mask było najpopularniejszą 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 od TYPO3 v13 dostępna jest z natywnym Content Block API trzecia alternatywa, która nie wymaga już żadnego dodatkowego rozszerzenia.

Kto ma DCE w użyciu, nie musi migrować natychmiast. Ale kto planuje aktualizację TYPO3 do v12 lub v13, powinien uwzględnić ablację, ponieważ długoterminowe wsparcie jest niepewne.

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ż workflow eksportowy (mask_export) 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 opcjonalnych layoutów backendowych. Pola są definiowane w GUI DCE: Text, RichText, Integer, Float, Date, File (FAL), Select, Checkbox, Group (IRRE), Section (powtarzalne fieldsets).

Przy zapisie 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 zagnieżdża elementy treści w sobie. Ta logika jest propriatarna 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, ponieważ wszystkie konfiguracje FlexForm są odczytywane z bazy danych i parsowane przy każdym wywołaniu. Rozwiązanie: aktywacja cachowania DCE (ustawienie TypoScript plugin.tx_dce.enableCache = 1) lub przejście na konfigurację opartą na plikach (funkcja eksportu DCE).

Migracja i kompatybilność wersji

DCE wspiera TYPO3 v11 i v12. Kompatybilność z TYPO3 v13 jest ograniczona: istnieje gałąź deweloperska, ale brak oficjalnie oznaczonego jako stabilny wydania (stan kwiecień 2026). Pielęgnacja społecznościowa jest mniej aktywna niż przy Mask, gdzie in2code jako główny deweloper prowadzi 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.