Die Vision
Die Vision für den Visual Editor ist eine Form der Inhaltspflege, bei der Redakteure die Website direkt in ihrer tatsächlichen Darstellung bearbeiten können.
Der Visual Editor zeigt weder eine vereinfachte Vorschau noch eine angenäherte Backend-Darstellung oder eine zweite Version des Frontends. Er verwendet das reale Frontend-Rendering des Projekts. Während der Bearbeitung sieht die Seite so aus, wie sie auch für Besucher aussieht, ergänzt lediglich um die notwendigen Bedienelemente des Editors.
Das bedeutet echtes visuelles WYSIWYG:
Redakteure bearbeiten keine abstrakte Repräsentation der Website. Sie bearbeiten die Website direkt in ihrer tatsächlichen visuellen Darstellung.
Dieses Konzept basiert auf zwei gleichwertigen Grundprinzipien:
- Das Bearbeitungserlebnis nutzt das echte Frontend.
- Die Integration erfolgt als Progressive Enhancement mit möglichst geringem Aufwand für bestehende Projekte.
Beide Prinzipien bedingen sich gegenseitig. Ein Visual Editor kann nur breite Anwendung finden, wenn er keine zweite Frontend-Architektur erfordert und bestehende Projekte nicht grundlegend umgebaut werden müssen.
Eine Darstellung statt zweier Rendering-Systeme
Viele visuelle Editoren versuchen, das Frontend innerhalb einer eigenen Editor-Oberfläche nachzubilden. Dabei entstehen zwei Darstellungen:
• das echte Frontend • eine separate Bearbeitungs- oder Preview-Darstellung
Sobald zwei Rendering-Systeme existieren, können diese voneinander abweichen. Templates, CSS, JavaScript, Breakpoints oder projektspezifische Komponenten müssen dann doppelt berücksichtigt werden. Jede Weiterentwicklung des Frontends kann zusätzliche Anpassungen im Editor erforderlich machen.
Der Visual Editor verfolgt bewusst einen anderen Ansatz. Er bearbeitet die serverseitig gerenderte Website selbst.
Das reguläre Fluid-Rendering, das Frontend-CSS und das projektspezifische JavaScript bilden weiterhin die Grundlage der Darstellung. Es gibt weder separate Visual-Editor-Templates noch ein zusätzliches Stylesheet, das versucht, das Frontend innerhalb des Editors nachzubilden.
Dieses Prinzip wird ausdrücklich als Inline Editing verstanden, das der Frontend-Ausgabe entspricht. Zur Kennzeichnung bearbeitbarer Texte und Content Areas innerhalb des regulären Renderings werden Fluid-ViewHelper verwendet. Grundsätzlich sollen projektspezifisches CSS und JavaScript weiter funktionieren. Einzelne Anpassungen können jedoch notwendig sein, wenn das Verhalten einer Komponente mit dem Bearbeitungsmodus kollidiert. Dies ändert jedoch nichts am Grundsatz: Nicht der Visual Editor rekonstruiert das Projekt, sondern das bestehende Projekt wird um Bearbeitungsmöglichkeiten erweitert.
Was „exakt wie im Frontend“ bedeutet
„Exakt wie im Frontend“ bedeutet, dass die sichtbare Darstellung identisch ist. Ausgenommen sind wenige Bedienelemente wie Auswahlrahmen, Action Bars, Drag Handles oder Hinweise auf bearbeitbare Felder.
Es bedeutet jedoch nicht, dass alle denkbaren Zustände einer Website gleichzeitig dargestellt werden.
Eine Website kann von folgenden Faktoren abhängig sein:
• der Viewport-Größe • der aktiven Sprache • dem Workspace • dem Vorschauzeitpunkt • Backend- und Frontend-Benutzerrechten • eingeloggten Frontend-Benutzern • Personalisierung • externen oder zeitabhängigen Daten
Der Visual Editor soll diese Zustände langfristig über „View Options“ auswählbar machen. Die Darstellung bleibt dabei für den jeweils gewählten Zustand korrekt. Es wird jedoch nicht versucht, alle Varianten gleichzeitig in einer einzigen Ansicht abzubilden.
Auch Responsive Editing folgt diesem Prinzip. Der Visual Editor simuliert kein separates responsives Layout, sondern zeigt das echte Frontend in der gewählten Viewport-Größe. Welche Viewports angeboten werden, soll projektspezifisch konfigurierbar sein. Eine spätere automatische Ableitung aus dem CSS ist eine mögliche Ergänzung, ist aber kein notwendiger Bestandteil des Grundkonzepts.
Direktes Bearbeiten statt Formular neben der Seite
Der Visual Editor zeigt nicht lediglich ein Formular neben dem Frontend und überträgt dessen Änderungen in eine Vorschau.
Eine solche Lösung verringert zwar den Abstand zwischen Formular und Ausgabe, basiert aber weiterhin auf einem formularorientierten Bearbeitungskonzept. Der Redakteur muss weiterhin zwischen dem Eingabefeld und der Stelle wechseln, an der das Ergebnis erscheint.
Echtes visuelles Bearbeiten beginnt erst, wenn Inhalt und Eingabeort identisch sind.
Eine Überschrift oder ein Fließtext wird direkt an seiner tatsächlichen Position bearbeitet. Ein Bild wird dort ausgewählt und zugeschnitten, wo es im Layout erscheint.
Das entspricht dem Verhalten moderner Dokumentenanwendungen. Auch in einer Textverarbeitung wird ein Absatz nicht in einem separaten Formular neben dem Dokument verändert.
Progressive Enhancement statt Projektumbau
Der Visual Editor ist weder ein alternatives Rendering-System noch eine neue Projektarchitektur. Er erweitert bestehende TYPO3-Projekte schrittweise.
Die kleinste Integration besteht darin, Content-Elemente über eine Action Bar zugänglich zu machen. Dabei stehen bereits Aktionen wie Bearbeiten, Ausblenden, Löschen und Erstellen zur Verfügung. Auch die bestehende Bildbearbeitung kann genutzt werden.
Anschließend kann Inline Editing gezielt für einzelne Felder ergänzt werden. So kann ein Projekt zunächst nur die Überschriften bearbeitbar machen und später weitere Textfelder oder Inhaltsbereiche integrieren.
Nicht markierte Inhalte bleiben im normalen Frontend. Sie sind weder fehlerhaft noch unvollständig. Der Integrator entscheidet bewusst, welche sichtbaren Felder direkt bearbeitet werden können.
Außerhalb des Bearbeitungsmodus darf sich der Frontend-Output nicht verändern. Auch die Core-ViewHelper müssen ohne installierten Visual Editor das Frontend normal rendern. Dadurch ist es möglich, den Visual Editor zu deaktiviert oder zu entfernen, ohne sämtliche Templates zurückbauen zu müssen.
Ausnahmen sind extension-spezifische Hilfen wie f:mark.contentArea oder f:editMode. Sie dienen in erster Linie der Migration, der Kompatibilität mit älteren TYPO3-Versionen und der Abdeckung spezieller Anwendungsfälle. Das langfristige Ziel besteht darin, möglichst viele Integrationspunkte durch allgemein sinnvolle Core-Abstraktionen abzudecken.
Explizite Integration statt automatischer DOM-Erkennung
Der Visual Editor versucht nicht, aus beliebigem HTML automatisch abzuleiten, welche Elemente bearbeitbar sein könnten.
Eine automatische Erkennung kann nicht zuverlässig feststellen:
• aus welchem TYPO3-Record ein DOM-Knoten stammt • welches Feld dargestellt wird • ob ein sichtbarer Wert direkt gespeichert oder berechnet wurde • ob mehrere Felder zu einer Ausgabe kombiniert wurden • ob die Ausgabe überhaupt aus einem TCA-basierten Record stammt • welche Bearbeitungsrechte für das Feld gelten
Eine nachträgliche Analyse oder Manipulation des DOM wäre fehleranfällig, schwer kontrollierbar und potenziell aufwändig. Sie würde bei komplexen Templates zwangsläufig falsche Zuordnungen erzeugen.
Die explizite Integration im Fluid-Template schafft hingegen eine eindeutige Verbindung zwischen Darstellung, Record und Feld. Der Integrator behält die Kontrolle darüber, welche Inhalte bearbeitbar sind. Gleichzeitig bleibt der notwendige Aufwand gering, da bestehende Ausgaben nicht neu entwickelt, sondern durch sinnvollere Rendering-Abstraktionen ersetzt werden.
Das Ziel besteht nicht darin, Integratoren mit Visual-Editor-spezifischem Wissen zu belasten. Im Gegenteil: Templates sollen reguläres, semantisch korrektes TYPO3-Rendering beschreiben. Die Bearbeitbarkeit ergibt sich daraus möglichst automatisch.
Warum f:render.text notwendig ist
Vor f:render.text wurden Textfelder abhängig je nach Konfiguration unterschiedlich ausgegeben:
• einfache Ausgabe für Plain Text
• f:format.nl2br für mehrzeiligen Text
• f:format.html für Rich Text
Für die reine Darstellung kann das funktionieren. Für eine zuverlässige visuelle Bearbeitung fehlen dabei jedoch entscheidende Informationen.
Ein Formatter erhält in der Regel nur den fertigen Wert. Er weiß nicht:
• zu welchem Record der Wert gehört • aus welcher Tabelle er stammt • welche UID der Record besitzt • welches Datenbankfeld dargestellt wird • wie das Feld im TCA konfiguriert ist
Ohne diese Informationen kann der Visual Editor den sichtbaren Inhalt nicht sicher einem bearbeitbaren TYPO3-Feld zuordnen.
Deshalb erhält f:render.text den vollständigen Record und den Feldnamen. Dadurch kann der ViewHelper die TCA-Konfiguration auswerten und selbst entscheiden, ob das Feld als einfacher Text, mehrzeiliger Text oder Rich Text gerendert werden muss. f:render.text ist ein record-bewusster ViewHelper, der Textfelder anhand ihrer TCA-Konfiguration rendert und die manuelle Formatierungslogik aus den Templates entfernt. Der ViewHelper entstand aus der Notwendigkeit heraus, einen eindeutigen Integrationspunkt für den Visual Editor zu schaffen. Daraus ist gleichzeitig eine allgemein bessere Rendering-Abstraktion entstanden.
Ein Template sollte nicht selbst wissen müssen, ob ein Feld aktuell Plain Text, mehrzeiligen Text oder Rich Text enthält. Diese Entscheidung wurde bereits im TCA getroffen. Das Template sollte dies nicht noch einmal abbilden müssen.
Deshalb gibt es keinen zusätzlichen f:render.richText ViewHelper. Eine frühere Trennung hätte dem Integrator eine unnötige Entscheidung auferlegt. Mit f:render.text kann die Konfiguration eines Feldes im TCA geändert werden, ohne dass anschließend auch jedes Template angepasst werden muss.
Der ViewHelper verbessert somit nicht nur die Integration des Visual-Editors. Er reduziert auch doppelte Konfiguration und macht Templates robuster.
Fehler sollen sichtbar bleiben
Wenn ein Template auf ein nicht vorhandenes Feld zugreift, löst f:render.text standardmäßig eine Exception aus.
Das ist eine bewusste Entscheidung. Eine falsche Annahme im Template soll während der Entwicklung sichtbar werden, damit sie nicht unbemerkt zu einer leerer Ausgabe führt.
Für gemeinsame Partials, die Records mit unterschiedlichen Feldern unterstützen müssen, steht diese Option optional zur Verfügung. In diesem Fall kann der ViewHelper kontrolliert null zurückgeben. Dadurch wird zwischen zwei Situationen unterschieden:
• Ein unerwartet fehlendes Feld ist ein Fehler. • Ein bewusst optionales Feld ist Teil des Template-Konzepts.
Keine Visual-Editor-spezifischen Templates
Bei der Integration wird bewusst kein ViewHelper wie ve:editableText als regulärer Rendering-Weg verwendet.
Ein solcher ViewHelper würde die Templates direkt an die Extension koppeln. Nach einer Deinstallation müssten die Templates wieder angepasst werden. Zudem würde sich die Frage der Bearbeitbarkeit unnötig mit der Aufgabe des Renderings vermischen.
Stattdessen beschreibt f:render.text, wie ein TCA-basiertes Textfeld korrekt ausgegeben wird. Der Visual Editor kann sich an diesen allgemein gültigen Rendering-Punkt integrieren, sofern er installiert und aktiv ist.
Der normale TYPO3 Rendering bleibt der Standardfall. Die Bearbeitbarkeit ist eine zusätzliche Fähigkeit.
Dieses Prinzip gilt auch für Fluid Components. Eine wiederverwendbare Komponente sollte möglichst nichts über den zugrunde liegenden Record, das TCA oder den Visual Editor wissen. Der Aufrufer rendert den Wert und übergibt der Komponente einen String oder ein Stringable-Objekt. Dadurch bleibt die Komponente unabhängig und wiederverwendbar.
Auch f:render.contentArea gehört dazu. Um Inhalte direkt bearbeiten und per Drag-and-drop verschieben zu können, reicht es nicht, einzelne Textfelder zu identifizieren. Auch die strukturelle Bedeutung von Inhaltsbereichen muss bekannt sein.
Historisch werden TYPO3-Inhalte häufig über frei konfigurierte Konstruktionen wie f:cObject, lib.dynamicContent oder manuelle Schleifen gerendert. Das ist zwar für die Ausgabe flexibel, für andere Systeme bleibt jedoch unklar, dass es sich an dieser Stelle um eine definierte Content Area handelt.
Mit f:render.contentArea wird ein typisierter und identifizierbarer Einstiegspunkt eingeführt. Die offizielle TYPO3-Dokumentation empfiehlt den ViewHelper anstelle manueller f:cObject- oder f:for-Konstruktionen. Er rendert eine vom page-content Data Processor bereitgestellte Content Area und ermöglicht Erweiterungen, in die Ausgabe über Events einzugreifen. Der Visual Editor liefert dieser Einstiegspunkt genau den strukturellen Kontext, der für das Erstellen, Verschieben und Zuordnen von Content-Elementen benötigt wird.
f:mark.contentArea war dafür ein notwendiger Fallback für TYPO3 13 sowie für bestehende Rendering-Methoden. Nach einer Migrationsphase soll diese Übergangslösung langfristig entfallen. Wo aktuell noch Markierungen benötigt werden, sollte geprüft werden, ob die zugrunde liegende Rendering-API so erweitert werden kann, dass f:render.contentArea direkt genutzt werden kann.
Vorhandene TYPO3-Mechanismen statt eigener Subsysteme
Eines der wichtigsten Architekturprinzipien lautet:
Der Visual Editor sollte möglichst nichts nachbauen, was TYPO3 schon bereitstellt.
Content-Elemente bleiben TYPO3-Records. Content Areas bleiben TYPO3-Content-Areas. Positionen, Spalten, Parent-Beziehungen und andere strukturelle Informationen bleiben Teil des bestehenden TYPO3-Datenmodells.
Der Visual Editor macht diese Strukturen zwar visuell zugänglich, definiert sie aber nicht neu.
Dasselbe gilt für den Rich-Text-Editor. Der Visual Editor implementiert keinen eigenen RTE, sondern nutzt die vorhandene TYPO3- und CKEditor-Integration. Dadurch bleiben die bereits für ein Feld konfigurierten RTE-Einstellungen erhalten. Es entsteht weniger zusätzlicher Code, und Projekte müssen ihre Editor-Konfiguration nicht ein zweites Mal pflegen.
Änderungen werden ebenfalls nicht über eine eigene Persistenzschicht direkt in die Datenbank geschrieben. Sie laufen stets über den TYPO3 DataHandler.
Der DataHandler verarbeitet Änderungen an TCA-konfigurierten Tabellen, wertet Schreibrechte aus und berücksichtigt dabei unter anderem Versionierung, History, Logging und Relationen. Dabei wird der Client grundsätzlich nicht als vertrauenswürdig betrachtet. Record, Feldname und Wert müssen serverseitig geprüft werden. In der Oberfläche werden nur Felder als bearbeitbar angezeigt, für die der Benutzer die notwendigen Rechte besitzt. Die endgültige Durchsetzung erfolgt trotzdem auf dem Server und im DataHandler.
Im Bedienkonzept ein Page Builder, technisch eher keiner
Aus Sicht des Redakteurs verfügt der Visual Editor über typische Eigenschaften eines Page Builders:
• Elemente können erstellt werden. • Elemente können verschoben oder kopiert werden. • Inhalte können direkt bearbeitet werden. • Die resultierende Seite ist unmittelbar sichtbar.
Technisch gesehen der Visual Editor jedoch kein eigenes Page-Builder-Modell ein.
Er verfügt weder über eine eigene Grid-Engine noch über eine eigene Layoutdefinition. Mehrspaltige Container oder komplexe Strukturen werden auch weiterhin durch die dafür zuständigen TYPO3-Mechanismen wie der container Extension bereitgestellt.
Der Visual Editor soll solche Elemente zwar visuell bedienbar machen, aber nicht von einer bestimmten Fremdextension abhängig werden und deren Funktionen innerhalb einer zweiten Implementierung nachbauen.
Wenn TYPO3 zukünftig Core-Funktionen für Container, Grids oder dynamische Layouts erhält, kann der Visual Editor diese Funktionen visuell zugänglich machen. Die fachliche Definition der Strukturen sollte jedoch nicht Teil des Visual Editors selbst werden.
Damit gilt:
Im Bedienkonzept ist der Visual Editor ein Page Builder. In seiner technischen Architektur ist er eine visuelle Bedienoberfläche für bestehende TYPO3-Strukturen.
Bewusste Grenzen
Der Visual Editor soll das TYPO3-Backend nicht vollständige ersetzen.
Insbesondere sind folgende Aufgaben keine Kernziele:
• freies visuelles Designen • beliebige CSS-Manipulation • Definition neuer Content-Typen • vollständige Seiten- und Datensatzkonfiguration • Ersatz aller Backend-Module und Spezialformulare
Nicht alle TCA-Felder sollen automatisch im Frontend bearbeitbar sein. Grundsätzlich sind nur die Inhalte bearbeitbar, die sichtbar gerendert und eindeutig integriert wurden. Ein Feld, das nicht Teil der sichtbaren Darstellung ist, gehört nicht automatisch in ein WYSIWYG-Interface.
Auch berechnete oder stark transformierte Ausgaben müssen klar behandelt werden. TypoLinks sind beispielsweise nicht zwangsläufig direkt inline bearbeitbar. Wenn der sichtbare Linktext aus einem eigenen Textfeld stammt, kann dieses Feld bearbeitet werden. Die Linkkonfiguration selbst kann weiterhin über ein reguläres TYPO3-Formular erfolgen. Das ist im Visual Editor in der Regel direkt erreichbar.
Rich Text wird unterstützt, sofern das Rendering über die regulären TYPO3-Mechanismen erfolgt. Individuelle lib.parseFunc_RTE-Konfigurationen können jedoch zusätzliche Einschränkungen verursachen. Visuelle Transformationen, wie das Abschneiden eines Textes nach einer bestimmten, Länge sollten möglichst über CSS erfolgen, damit gespeicherter Inhalt und bearbeiteter Inhalt identisch bleiben.
Speichern als bewusste Aktion
Änderungen müssen nicht nach jeder Eingabe sofort dauerhaft gespeichert werden.
Insbesondere im Live-Workspace sollen Redakteure mehrere Änderungen vorbereiten und diese gemeinsam speichern können, sobald der gewünschte Stand erreicht ist. Damit bleibt der Redakteur in Kontrolle darüber, wann Änderungen tatsächlich übernommen werden.
Die Funktion „Autosave“ kann in geeigneten Workspace-Konstellationen angeboten werden. Es handlet sich jedoch nicht um ein universelles Grundprinzip, das unabhängig vom Arbeitskontext immer aktiv sein muss.
Wichtig ist, dass auch eine moderne visuelle Oberfläche die bestehenden TYPO3-Prozesse für Workspaces, Rechte und Veröffentlichungen respektiert.
Technische Einschränkungen sind keine Architekturprinzipien
Einige heutige Grenzen resultieren sich aus der aktuellen technischen Umgebung und nicht aus der langfristigen Vision.
Headless- und Non-Fluid-Projekte sind derzeit keine First-Class-Integrationsziele, da die Implementierung stark auf Fluid-ViewHelper und serverseitig gerendertes HTML ausgerichtet ist. In der aktuellen Projektdokumentation wird für eine robuste Headless-Integration ausdrücklich die Notwendigkeit einer öffentlichen API. Langfristig sollen alternative Rendering-Wege über eine geeignete PHP-API angebunden werden können. Dabei muss jedoch entschieden werden, wie sie die notwendigen Informationen zu Record, Feld und Content Area zuverlässig bereitstellen.
Serverseitig gerendertes HTML und die Verwendung derselben Templates für Bearbeitung und Frontend bleiben dagegen Kernprinzipien. Würden separate Bearbeitungstemplates eingeführt, würde der Visual Editor eines seiner zentralen Versprechen aufgeben.
Auch Same-Origin- und Multi-Domain-Einschränkungen sind technische Grenzen, keine gewünschten Produkteigenschaften. Sie entstehen unter anderem durch Authentifizierung, Frame-Kommunikation und derzeitige Core-APIs. Sie sollten langfristig verbessert werden, ohne deshalb das Grundkonzept zu verändern.
Zusammenfassung der Architekturprinzipien
Der Visual Editor folgt diesen Grundsätzen:
- Es gibt nur ein Frontend-Rendering.
- Bearbeitet wird die tatsächlich gerenderte Website.
- Außerhalb des Editiermodus bleibt der Frontend-Output unverändert.
- Die Integration erfolgt schrittweise als Progressive Enhancement.
- Templates beschreiben korrektes TYPO3-Rendering, nicht eine spezielle Editor-Konfiguration.
- Records und Felder werden explizit und zuverlässig zugeordnet.
- TCA ist die zentrale Quelle für die Bedeutung und Darstellung von Feldern.
- Vorhandene TYPO3-Core-Mechanismen werden wiederverwendet.
- Der Visual Editor führt kein paralleles Content-, Layout- oder Persistenzmodell ein.
- Technische Einschränkungen werden klar von dauerhaften Architekturprinzipien getrennt.
Der Visual Editor ist also kein zweites System neben TYPO3. Vielmehr stellt er eine neue visuelle Bedienebene für das bestehende System dar.
Seine Stärke entsteht nicht dadurch, dass er möglichst viele TYPO3-Funktionen nachbaut. Seine Stärke liegt darin, dass er die vorhandenen Funktionen dort zugänglich macht, wo Redakteure ihr Ergebnis tatsächlich sehen: direkt im gerenderten Frontend.