rte_ckeditor_image dla TYPO3: Edycja obrazów w Rich Text Editor

rte_ckeditor_image wprowadza profesjonalne zarządzanie obrazami do Rich Text Editor

TYPO3-CKEditor dopuszcza tylko proste osadzanie obrazów przez tag img, bez powiązania z File Abstraction Layer i bez responsywnych wariantów. Dla redakcji, które regularnie wstawiają obrazy w artykuły, wpisy news lub teksty magazynowe, to nie wystarcza: potrzebują one przycinania, skalowania, tekstu alt, copyright, celu linku i przede wszystkim wyjścia srcset. rte_ckeditor_image od Netresearch uzupełnia CKEditor o dokładnie te funkcje i porządnie integruje go z FAL. W każdym projekcie TYPO3 z redakcyjnie pielęgnowanymi obrazami w tekście głównym rozszerzenie od lat jest standardowym narzędziem i należy do najczęściej instalowanych pomocników redakcji w ekosystemie.

Typowe scenariusze zastosowania leżą w redakcjach z wysokim wolumenem obrazów

Magazyny online i korporacyjne strony news są klasyczną grupą docelową. Magazyn z 200 artykułami rocznie osadza w każdym wpisie dwa do pięciu obrazów w tekście głównym, dodatkowo do obrazów teaserowych i nagłówkowych. Bez rte_ckeditor_image redakcja musiałaby dla każdego obrazu inline akceptować zmianę elementu contentu i przerywać płynność tekstu. Z rozszerzeniem wstawia obraz bezpośrednio przez przycisk na toolbarze, wybiera referencję FAL, ustawia tekst alt i podpis i wraca bez zmiany kontekstu do pisania. Zysk efektywności można mierzyć w praktyce: przy redakcji z 200 wpisami rocznie i średnio czterema obrazami na wpis oszczędzamy na artykule około dwóch minut czasu setup, co w skali roku daje prawie 30 godzin pracy.

Drugim scenariuszem są katalogi produktów i dokumentacja techniczna. Kto w katalogu TYPO3 pielęgnuje instrukcje krok po kroku ze zrzutami ekranu inline, potrzebuje obrazów bezpośrednio w tekście. rte_ckeditor_image pozwala na to z tymi samymi referencjami FAL, które są używane w reszcie projektu, aktualizacje obrazów odbywają się w jednym miejscu i działają wszędzie.

Trzecim scenariuszem jest migracja instalacji TYPO3 z ery htmlArea. Kto do tej pory używał RTEhtmlArea, znalazł tam podobne zarządzanie obrazami. Przy przejściu na CKEditor rte_ckeditor_image jest bezpośrednim rozszerzeniem zastępczym, żeby redaktorzy mogli kontynuować zwykły workflow. Bez rozszerzenia redakcja traci przy upgrade nie tylko jedną funkcję, ale cały krok pracy, który trudno zastąpić dodatkowymi elementami contentu.

Architektura techniczna rozszerza toolbar CKEditora przez plugin

Rozszerzenie składa się z pluginu CKEditora, który rejestruje przycisk Image i dialog Image, oraz serwerowego renderowania, które tłumaczy marker w zapisanym HTML na wyjście Fluid. Plugin komunikuje się z endpointem AJAX, który przetwarza referencję FAL, przycinanie i teksty alt.

W contencie bazy danych obraz stoi jako oznaczenie HTML z atrybutami data data-htmlarea-file-uid i data-htmlarea-file-table, towarzyszonymi przez dalsze atrybuty dla przycinania, zoomu i wysokości. Przy renderowaniu pre-processor zastępuje tag oznaczenia pełnym wywołaniem ViewHelpera Image, które tworzy srcset, warianty webp i atrybuty lazy-loading. Dostępne szerokości obrazów są definiowane przez YAML w konfiguracji RTE. Typowa konfiguracja magazynowa pracuje z trzema do pięciu szerokościami obrazów (480, 768, 1024, 1440, 2048) i automatycznie tworzy z tego responsywne srcset, które na urządzeniach mobilnych ładuje tylko najmniejszy wariant.

Przycinanie wykorzystuje TYPO3-Core-Cropping-Werkzeug: w dialogu obrazu pojawia się edytor crop z backendu, z tymi samymi presetami wariantów co przy regularnym elemencie treści obraz. Przycinanie jest zapisywane per instancja obrazu, dzięki czemu ten sam obraz FAL może być w różnych artykułach inaczej przycięty. Jest to szczególnie ważne, gdy obraz jest używany zarówno w teaserze magazynu (kwadratowy) jak i w tekście głównym (landscape), bez konieczności pielęgnowania przez redakcję dwóch oddzielnych plików.

Częste problemy dotyczą responsywnego wyjścia, WebP i kompatybilności z CKEditor 5

Najczęstszym tematem wsparcia jest brakujące wyjście srcset. Domyślna ścieżka renderowania nie tworzy srcset, gdy YAML RTE nie zawiera definicji szerokości obrazów. Wiele instalacji skopiowało YAML z TYPO3-Core i przy tym pominęło sekcję “proc.entryHTMLparser_db.allowedAttribs” lub “config.additionalAttributes”. Rozwiązaniem jest pełny YAML z wyraźnie zdefiniowanymi szerokościami srcset.

Drugim problemem jest WebP. Kto chce dostarczać nowoczesne formaty obrazów, musi skonfigurować TYPO3-ImageMagick-Provider lub konfigurację GraphicsMagick z obsługą WebP. rte_ckeditor_image sam nie tworzy konwersji WebP, lecz sięga do core-Image-Processora. Bez prawidłowej konfiguracji providera obrazy pozostają w wyjściu jako JPEG.

Po trzecie, CKEditor 5 stanowi zmianę architektury. TYPO3 v12 przynosi CKEditor 5, który używa innego modelu pluginów. Wersje 10.x i 11.x rte_ckeditor_image są przeniesione na CKEditor 5 i działają w v12 out of the box. Własne dostosowania oparte na CKEditor 4 muszą być dostosowane przy upgrade. Kto zbudował własne pluginy lub własne przyciski toolbaru, powinien na migrację zaplanować co najmniej jeden do dwóch dni deweloperskich.

Migracja na TYPO3 v12 i v13 wymaga skoku wersji rozszerzenia

rte_ckeditor_image jest aktywnie utrzymywane przez Netresearch i dostępne dla TYPO3 v11, v12 i v13. Większy skok leży między wersjami rozszerzenia 9.x (CKEditor 4) i 10.x/11.x (CKEditor 5). Kto podnosi instalację TYPO3 v10 lub v11 z rozszerzeniem 9.x na TYPO3 v12, musi jednocześnie przejść na serię 10.x rozszerzenia. Reprezentacja bazy danych obrazów inline pozostaje przy tym kompatybilna, dzięki czemu istniejące artykuły działają bez migracji treści.

W Gosign sprawdzamy przed każdym upgrade TYPO3, czy YAML RTE projektu musi być dostosowany do wersji rozszerzenia i czy istnieją własne dostosowania pluginu lub nadpisane ViewHelpery. W wielu projektach z TYPO3 v12 można dodatkowo sprawdzić, czy natywne funkcje obrazów CKEditor 5 wystarczają i rozszerzenie można średnioterminowo wycofać. Dla redakcji z potrzebą przycinania i srcset rte_ckeditor_image pozostaje jednak najbardziej pragmatyczną opcją. Alternatywą byłby własny przycisk toolbaru obrazu z custom pluginem CKEditor, co jest wyraźnie bardziej kosztowne i trwale przenosi pielęgnację do odpowiedzialności projektu.