rte_ckeditor_image für TYPO3: Bildbearbeitung im Rich Text Editor

rte_ckeditor_image bringt professionelle Bildverwaltung in den Rich Text Editor

Der TYPO3-CKEditor erlaubt nur einfache Bild-Einbindungen per img-Tag, ohne Verbindung zum File Abstraction Layer und ohne responsive Varianten. Für Redaktionen, die regelmässig Bilder in Artikel, News-Beiträge oder Magazin-Texte einfügen, reicht das nicht: Sie brauchen Zuschnitt, Skalierung, Alt-Text, Copyright, Linkziel und vor allem srcset-Ausgabe. rte_ckeditor_image von Netresearch ergänzt den CKEditor um genau diese Funktionen und integriert ihn sauber in den FAL. Auf jedem TYPO3-Projekt mit redaktionell gepflegten Fliesstext-Bildern ist die Extension seit Jahren das Standard-Tool und zählt zu den am häufigsten installierten Redaktions-Helfern im Ökosystem.

Typische Einsatzszenarien liegen in Redaktionen mit hohem Bildaufkommen

Online-Magazine und Corporate-News-Seiten sind die klassische Zielgruppe. Ein Magazin mit 200 Artikeln pro Jahr bindet pro Beitrag zwei bis fünf Bilder im Fliesstext ein, zusätzlich zu Teaser- und Header-Bildern. Ohne rte_ckeditor_image müsste die Redaktion für jedes Inline-Bild einen Content-Element-Wechsel akzeptieren und den Textfluss unterbrechen. Mit der Extension fügt sie das Bild direkt über einen Toolbar-Button ein, wählt die FAL-Referenz, setzt Alt-Text und Bildunterschrift und kehrt ohne Kontextwechsel zum Schreiben zurück. Der Effizienzgewinn lässt sich in der Praxis messen: Bei einer Redaktion mit 200 Beiträgen pro Jahr und durchschnittlich vier Bildern pro Beitrag sparen wir pro Artikel etwa zwei Minuten Setup-Zeit, was aufs Jahr gerechnet knapp 30 Arbeitsstunden ausmacht.

Ein zweites Szenario sind Produktkataloge und Technische Dokumentation. Wer in einem TYPO3-Katalog Schritt-für-Schritt-Anleitungen mit Inline-Screenshots pflegt, braucht die Bilder direkt im Text. rte_ckeditor_image erlaubt das mit den gleichen FAL-Referenzen, die auch im restlichen Projekt verwendet werden - Bild-Updates erfolgen an einer Stelle und wirken sich überall aus.

Ein drittes Szenario ist die Migration von TYPO3-Installationen aus der htmlArea-Ära. Wer bisher den RTEhtmlArea im Einsatz hatte, fand dort eine ähnliche Bildverwaltung. Beim Umstieg auf CKEditor ist rte_ckeditor_image die direkte Ersatz-Extension, damit Redakteure den gewohnten Workflow weiternutzen können. Ohne die Extension fällt der Redaktion beim Upgrade nicht nur eine Funktion weg, sondern ein kompletter Arbeitsschritt, der sich nur mühsam durch zusätzliche Content-Elemente ersetzen lässt.

Technische Architektur erweitert den CKEditor-Toolbar per Plugin

Die Extension besteht aus einem CKEditor-Plugin, das den Image-Button und den Image-Dialog registriert, sowie einem serverseitigen Rendering, das den Marker im gespeicherten HTML in eine Fluid-Ausgabe übersetzt. Das Plugin kommuniziert mit einem AJAX-Endpunkt, der die FAL-Referenz, das Cropping und die Alt-Texte verarbeitet.

Im Datenbank-Content steht das Bild als HTML-Markierung mit den data-Attributen data-htmlarea-file-uid und data-htmlarea-file-table, begleitet von weiteren Attributen für Cropping, Zoom und Height. Beim Rendering ersetzt ein Pre-Processor den Markierungs-Tag durch einen vollen Image-ViewHelper-Call, der srcset, webp-Varianten und Lazy-Loading-Attribute erzeugt. Die verfügbaren Bildbreiten werden per YAML in der RTE-Konfiguration definiert. Ein typisches Magazin-Setup arbeitet mit drei bis fünf Bildbreiten (480, 768, 1024, 1440, 2048) und erzeugt daraus automatisch ein responsive srcset, das auf mobilen Geräten nur die kleinste Variante lädt.

Das Cropping nutzt das TYPO3-Core-Cropping-Werkzeug: Im Bild-Dialog erscheint der Crop-Editor aus dem Backend, mit denselben Varianten-Presets wie beim regulären Bild-Content-Element. Cropping wird pro Bild-Instanz gespeichert, sodass dasselbe FAL-Bild in verschiedenen Artikeln unterschiedlich zugeschnitten sein kann. Das ist besonders wichtig, wenn ein Bild sowohl im Magazin-Teaser (quadratisch) als auch im Fliesstext (landscape) verwendet wird, ohne dass die Redaktion zwei separate Dateien pflegen muss.

Häufige Probleme betreffen responsive Ausgabe, WebP und CKEditor-5-Kompatibilität

Das häufigste Supportthema ist die fehlende srcset-Ausgabe. Der Default-Rendering-Pfad erzeugt kein srcset, wenn die RTE-YAML keine Bildbreiten-Definition enthält. Viele Installationen haben die YAML vom TYPO3-Core kopiert und dabei den Abschnitt “proc.entryHTMLparser_db.allowedAttribs” oder “config.additionalAttributes” ausgelassen. Die Lösung ist eine vollständige YAML mit explizit definierten srcset-Breiten.

Das zweite Problem ist WebP. Wer moderne Bildformate ausliefern will, muss den TYPO3-ImageMagick-Provider oder einen GraphicsMagick-Setup mit WebP-Unterstützung einrichten. rte_ckeditor_image selbst erzeugt keine WebP-Konvertierung, sondern greift auf den Core-Image-Processor zurück. Ohne korrekte Provider-Konfiguration bleiben die Bilder als JPEG in der Ausgabe.

Drittens stellt CKEditor 5 einen Architektur-Wechsel dar. TYPO3 v12 bringt CKEditor 5 mit, der ein anderes Plugin-Modell verwendet. Die rte_ckeditor_image-Versionen 10.x und 11.x sind auf CKEditor 5 portiert und funktionieren in v12 out of the box. Eigene Anpassungen, die auf CKEditor 4 basieren, müssen beim Upgrade angepasst werden. Wer Custom-Plugins oder eigene Toolbar-Buttons gebaut hat, sollte für die Migration mindestens ein bis zwei Entwicklertage einplanen.

Migration auf TYPO3 v12 und v13 verlangt Versionssprung der Extension

rte_ckeditor_image wird von Netresearch aktiv gepflegt und ist für TYPO3 v11, v12 und v13 verfügbar. Der grössere Sprung liegt zwischen den Extension-Versionen 9.x (CKEditor 4) und 10.x/11.x (CKEditor 5). Wer eine TYPO3-v10- oder v11-Installation mit Extension 9.x auf TYPO3 v12 hebt, muss gleichzeitig auf die 10.x-Serie der Extension wechseln. Die Datenbank-Repräsentation der Inline-Bilder bleibt dabei kompatibel, sodass bestehende Artikel ohne Inhalts-Migration funktionieren.

Bei Gosign prüfen wir vor jedem TYPO3-Upgrade, ob die Projekt-RTE-YAML an die Extension-Version angepasst werden muss und ob eigene Plugin-Anpassungen oder überschriebene ViewHelper existieren. In vielen Projekten mit TYPO3 v12 lässt sich ausserdem prüfen, ob die nativen CKEditor-5-Bildfunktionen ausreichen und die Extension mittelfristig abgebaut werden kann. Für Redaktionen mit Cropping- und srcset-Bedarf bleibt rte_ckeditor_image allerdings die pragmatischste Option. Die Alternative wäre ein eigener Bild-Toolbar-Button mit custom CKEditor-Plugin, was deutlich aufwändiger ist und die Pflege dauerhaft in den Projektverantwortung holt.