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 skalowania, tekstu alt, podpisu, celu linku i przede wszystkim ostrego obrazu na ekranach o wysokiej gęstości pikseli. 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, wymiary obrazu 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 zoomu, poziomu jakości, szerokości i wysokości. Przy renderowaniu preUserFunc w lib.parseFunc_RTE przetwarza tag oznaczenia: skaluje obraz przez przetwarzanie obrazów TYPO3, ustawia atrybut lazy-loading i wyświetla figure, link i podpis przez nadpisywalne partiale Fluid. Górne limity szerokości i wysokości ustawia się w Page TSconfig (maxWidth, maxHeight). Typowa konfiguracja magazynowa pracuje z trzema do pięciu szerokościami obrazów (480, 768, 1024, 1440, 2048) i do srcset potrzebuje własnej preUserFunc, takiej jak w przykładzie z dokumentacji rozszerzenia; samo rozszerzenie nie tworzy srcset.

Dialog obrazu ustawia szerokość, wysokość, tekst alt, tytuł, poziom jakości i powiększanie po kliknięciu. Przycinanie z wariantami oferuje tylko regularny element treści obraz. Szerokość i wysokość są zapisywane per instancja obrazu, dzięki czemu ten sam obraz FAL może mieć w różnych artykułach inny rozmiar. Jest to szczególnie ważne, gdy obraz jest używany w różnych rozmiarach zarówno w teaserze magazynu, jak i w tekście głównym, 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 w ogóle nie tworzy srcset, tylko przeskalowaną wersję obrazu. Ustawienia szerokości srcset nie ma ani w YAML RTE, ani w konfiguracji rozszerzenia. Rozwiązaniem jest własna preUserFunc według przykładu z dokumentacji, która dla każdej szerokości tworzy przetworzony wariant.

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 12.x dla TYPO3 v12 i 13.x dla v13 i v14 rte_ckeditor_image są przeniesione na CKEditor 5 i działają 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 serią 11.x rozszerzenia z CKEditor 4 a seriami 12.x i 13.x z CKEditor 5. Kto podnosi instalację TYPO3 v10 lub v11 z rozszerzeniem 10.x lub 11.x na TYPO3 v12, musi jednocześnie przejść na serię 12.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 wystarczą obrazy jako osobne elementy treści i rozszerzenie można średnioterminowo wycofać. Dla redakcji, które potrzebują obrazów wewnątrz tekstu głównego, 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.