Ausblick auf WoltLab Suite 6.0

Die Entwicklung von WoltLab Suite 5.5 hat mit der Veröffentlichung vor einigen Wochen ihren Abschluss gefunden und dank der enorm hohen Stabilität der Version können wir einen Teil unserer Aufmerksamkeit auf die Weiterentwicklung von WoltLab Suite lenken. Wir haben uns dazu bereits im Vorfeld viele Gedanken gemacht und dazu aus verschiedenen Quellen Feedback eingeholt, um zu entscheiden, welchen Schwerpunkt wir für die nächste Version wählen möchten.

Neuer WYSIWYG-Editor

Der bestehende Editor „Redactor II“ hat über viele Jahre relativ gute Dienste geleistet, weist allerdings einige konzeptionelle Schwächen auf und wird bereits seit einiger Zeit zu Gunsten einer komplett neuen Fassung nicht mehr vom Hersteller weiterentwickelt. Die kontinuierliche Weiterentwicklung der Web-Browser tragen auch immer wieder zu Verhaltensänderungen bei, durch die sich ein kontinuierlicher Wartungsbedarf ergibt.


Wir haben uns eine große Anzahl an WYSIWYG-Editoren angesehen, um den für unseren Anwendungsfall idealen Kandidaten zu finden. Neben einer ordentlichen Programmierung war uns insbesondere wichtig, dass dieser mit der freien Lizenz von WoltLab Suite Core vereinbar ist und wir mehr Kontrolle über das erzeugte HTML haben, um bessere Ergebnisse zu liefern. Mit dem Wechsel fällt ebenfalls eine größere Komponente weg, die auf dem Relikt „jQuery“ basiert.


Aktuell arbeiten wir an einem Entwurf eines neuen Editors auf Basis der Version 2 von TipTap, einem modernen Editor, der technisch auf ProseMirror aufbaut. ProseMirror ist indirekt kein Unbekannter, er stammt vom selben Entwickler wie CodeMirror, der in einer älteren Version mit anderer technischer Basis bereits seit vielen Jahren von uns für die Code-Ansichten in der Administrationsoberfläche im Einsatz ist. Die Erfahrungswerte mit CodeMirror konnten in die Entwicklung von ProseMirror einfließen, insbesondere die Handhabung auf Smartphones war ein wesentliches Kriterium bei der Entwicklung.

Umstieg auf Font Awesome 6

Bis heute setzen wir bei den Icons noch auf Font Awesome 4. Diese haben ebenfalls gute Arbeit geleistet und sind auch heute noch gut benutzbar, bleiben aber weit hinter den Möglichkeiten aktueller Icons zurück. Die teilweise Unschärfe und uneinheitliche Positionierung der Icons macht die Arbeit nicht immer leicht, darüber hinaus ist die Auswahl an Icons eher begrenzt und man wird immer wieder vergeblich nach passenden Icons suchen oder Kompromisse eingehen müssen.


Mit Font Awesome 6 können wir modernere Icons in die Software einfließen lassen und mehr Möglichkeiten bei der Auswahl von Icons liefern, beispielsweise für die Darstellung von Foren. Wir wollten diese Umstellung bereits vor einiger Zeit angehen, jedoch gibt es eine Reihe von technischen Änderungen bei den Icons, die weitgehende Auswirkungen auf die Kompatibilität haben. Damals fiel die Entscheidung, die Umstellung um eine Version zu verschieben, damit wir genügend Zeit haben die Änderungen gewissenhaft durchzuführen.

Technische Modernisierung und Bereinigung von Altlasten

Wir knüpfen nahtlos an die PSR-7/PSR-15-Implementierung an, die wir bereits mit WoltLab Suite 5.5 angekündigt und teilweise umgesetzt haben. Insbesondere die Arbeit mit Rückgaben an den Client sowie die Veränderung von Responses zur Laufzeit werden damit deutlich erleichtert. Die Verwendung eines einheitlichen Standards macht es auch leichter, auf bestehende Bibliotheken zurückzugreifen, die auf denselben Schnittstellen aufbauen und kommunizieren. Der Einsatz von Middlewares erlaubt darüber hinaus weitreichenden Einfluss auf die Verarbeitung von eingehenden Anfragen.


Mit WoltLab Suite 6.0 werden wir die Systemanforderungen auf PHP 8.1 anheben, womit neben einer besseren Performance auch zahlreiche Erleichterungen für Entwickler eingehen. Eine stärkere Typisierung und Konstrukte wie Enums erlauben besseren und stabileren Code zu schreiben, von dem sowohl Anwender als auch Entwickler profitieren. Ebenfalls werden wir einige sehr alte Komponenten entfernen, für die es bereits seit längerem besseren Ersatz gibt. Für diesen Zweck pflegen wir bereits während der Entwicklung die Dokumentation und informieren damit frühzeitig über derartige Änderungen: https://docs.woltlab.com/5.6/m…55/deprecations_removals/

Was WoltLab Suite 6.0 nicht ist

Die Änderungen an den Icons sowie der Austausch des Editors wird weitreichende Inkompatibilitäten nach sich ziehen, von denen voraussichtlich die Mehrzahl an Erweiterungen betroffen sein wird. Auch wenn der Änderungsaufwand in den meisten Fällen eher vergleichsweise gering ausfallen wird, so stellt dies dennoch eine gewichtige Änderung dar. Die Wahl der Versionsnummer 6.0 statt der 5.6 soll die Bedeutung dieser Änderung unterstreichen.


Wir möchten an dieser Stelle jedoch mit Nachdruck unterstreichen, dass es sich weder um eine komplette Überarbeitung der Software handelt, noch dass wir von unseren bisherigen Release-Zyklen abweichen werden. Ein direktes Upgrade über die Administrationsoberfläche von WoltLab Suite 5.5 wird möglich sein.


Zum aktuellen Zeitpunkt streben wir eine Veröffentlichung für das 1. Quartal 2023 an.

Kommentare 44

  • Ließe sich zukünftig vielleicht auch ermöglichen, dass der Forenbetreiber den oftmals etwas überfordernden Funktionsumfang des Texteditors abhängig vom jeweiligen Plugin anpasst, um beispielsweise im Forum wie auch in sozialen Netzwerken nur die reine Texteingabe inklusive Links und Mentions zu ermöglichen?

    • Das ist potentiell möglich, hängt aber auch ein Stückweit davon ab, wie praktikabel die Modularität des Editors im Einsatz tatsächlich ist. Wir planen mindestens die Möglichkeit eines funktionsreduzierten Editors, beispielsweise für Kommentare oder vergleichbare Einsatzzwecke, aber ob wir dieses Konzept noch weiter ausbauen können, ist gegenwärtig nicht klar. Dies ist etwas, dass sich erst im Verlauf der weiteren Entwicklung herauskristallisieren wird.

      Gefällt mir 1
    • Alexander Ebert

      Wichtig wäre es, dass Betreiber oder Entwickler über den Funktionsumfang des Editors bestimmen können.* Ich habe beispielsweise Anwendungen, welche auf Kommentare aufbauen und dabei den maximalen Editor-Umfang benötigen. Wenn die Suite 6 pauschal alle Kommentar-Editoren reduziert wäre das ein Problem. Bei anderen Anwendungen hingegen (z.B. Chronik/Timeline) ist ein reduzierter Umfang die bessere Wahl.


      * unabhängig davon ob einzelne Buttons/Funktionen konfiguriert werden, oder einfach zw. reduziert/erweitert gewählt wird.

  • Wird man mit dem neuen Editor auch die standart-Farbpalette ändern können?
    Ich muss immer die Hex-Werte in 2 js Datein manuell ändern, da die standart-Farben nicht sehr schön aussehen und auch nicht ganz zu meinem Farbthema passen.

    • Das Ändern der Schriftfarbe ist generell eine sehr problematische Funktion, einerseits auf Grund der Lesbarkeit und natürlich auch im Hinblick auf die Barrierefreiheit. Ein Klassiker ist die Verwendung von Schwarz oder Grautönen, die dann bei einem Dark-Theme praktisch unsichtbar sind. Eventuell macht es mehr Sinn, mit „Textmarkern“ zu arbeiten, die eine vorgegebene Formatierung erlaubt um so bestimmte Hervorhebung zu erreichen, die gleichzeitig per CSS anpassbar sind.


      Etwas spruchreifes gibt es zum gegenwärtigen Zeitpunktes nicht, dafür sind die Arbeiten am neuen Editor noch nicht ausreichend fortgeschritten.

      Gefällt mir 1
  • Ist eigentlich auch geplant alle vorhandenen Formen auf FormBuilder umzubauen? Wenn ja, würde ich gerne mit ein paar PRs unterstützen.

    • Wir planen mittelfristig eine Migration der bestehenden Formulare auf den FormBuilder. Es gibt jedoch noch einige andere Projekte, die wir vorher angehen möchten, beispielsweise die Umstellung der Controller auf PSR7/PSR15 (aktuell geplant für 6.1).


      Die Frontend-Formulare sind ein relativ „sensibles“ Thema, weil diese durch bestehende Plugins erweitert werden und eine Umstellung hier zu Inkompatibilitäten führen. Wir möchten es vermeiden, mit 6.0 diese Formulare zu ändern, nur um diese (nach aktuellem Stand) mit 6.1 erneut anzupassen.


      Die ACP-Formulare sind deutlich bessere Kandidaten für eine vorherige Migration, da diese nur selten von Plugins erweitert werden und daher ein Bruch der Kompatibilität dort meist keine Folgen hat. Allerdings ist das eine eher „trockene Angelegenheit“, die mit viel manuellem Aufwand verbunden ist und ich nicht gerade zu den dankbaren Aufgaben zähle. Solltest du dennoch Interesse haben, uns bei der Migration dieser Formulare zu unterstützen, so nehmen wir jede Hilfe dankbar an ;)

      Gefällt mir 2
  • Wie wird man die Pro-Icons einbinden können?

    • CSS
      /* Muss auf `html` oder `:root` gesetzt sein. */
      html {
        --fa-font-family: "Font Awesome 6 Pro";
        --fa-font-weight: 300; /* oder 100 für thin */
      }


      Wobei die Lizenzbestimmungen von Font Awesome 6 fürchterlich sind. Für den Eigenbedarf ist das kein Problem, aber für ein Produkt, dass man weiterverkauft, zahlt man vergleichsweise hohe Gebühren pro Jahr. Anders als bei Font Awesome 5 gibt es keine OEM- oder Theme-Lizenzen…

      Gefällt mir 1
    • Also wird die Suite erstmal mit der Free-Version geliefert. Man kann die Pro aber selbst hochladen und einfach per CSS-Schnipsel einsetzen. Habe ich das richtig verstanden?

    • Das ist korrekt. Die Pro-Version muss lediglich als @font-face eingebunden werden und anschließend über obigen CSS-Schnipsel „aktiviert“ werden.


      Bei der Umsetzung habe ich darauf geachtet, dass die Nutzung der „Solid“-Versionen nur als expliziter Opt-In stattfindet und ansonsten der Schriftschnitt entsprechend der font-weight ausgewählt wird.


      Es gibt jedoch eine Einschränkung: Die meisten Icons existieren in der Free-Version nur als „Solid“-Variante. Dies bedeutet, dass das System implizit diese Variante erzwingt, weil es keine „Regular“-Version gibt. Dafür und zur Vermeidung von Fehlern gibt es eine explizite Validierung der Icon-Namen auf Basis einer fest definierten Liste von Iconnamen (sowohl in PHP als auch im Template bzw. TS/JS). Es ist damit nicht möglich, Icons auszuwählen, die es generell nur in der Pro-Version gibt.


      Die Brand-Icons stehen vollständig zur Verfügung, allerdings kann auf diese ausschließlich über den neuen {icon}-Template-Helper zugegriffen werden. Dies liegt darin begründet, dass die Web-Font 102 kB groß ist (WOFF2, bereits komprimiert) und dies unverhältnismäßig hoch ausfällt. Brand-Icons werden daher als Inline-SVG eingefügt, so dass beispielsweise für eine Handvoll Brand-Icons (z. B. Facebook oder Twitter) nur einige kB benötigt werden.

  • Wie wird das mit den Upgradekosten aussehen? Erhält man mit aktiven Updatezugang das Update auf die 6.0 oder muss man ein extra Upgrade kaufen um auf die 6.0 updaten zu dürfen? Ist da schon was beschlossen?

    • Mit aktivem Updatezugang zum Zeitpunkt des Erscheinens von Version 6.0 hat man automatisch Zugang zu der Version.

      Gefällt mir 2
  • Lass euch Zeit und macht es anständig! 1. Quartal erscheint mir, als wolltet ihr euch selbst Druck machen!

  • Da höre ich einige meiner Teamler schon Freudenschreie machen, wenn der von einigen unbeliebte Editor ausgewechselt wird.

    Ich selbst freue mich auf die neuen FA6 Icons. Viele davon verwende ich bereits in Drucksachen und dann auch endlich Online.

    Gefällt mir 1
  • Ich finde das Wort Cloud nicht. Kann mir wer helfen?

    OK 3
  • Freue mich irgendwie besonders auf FA6 und den neuen Editor. Bin gespannt, wo die Reise noch hin geht. :)

  • Die Änderungen klingen spannend, ich freue mich auf TipTap 🤤

  • Gehe ich richtig der Annahme aus, das für euch Redactor/X (die neuen Versionen) aufgrund der Lizenzen nicht in betracht kommen?

    • Nein, ausschlaggebend für unsere Entscheidung ist primär die Funktionalität und ob ein Editor zu unseren Anforderungen passt.

    • Mit dem CKEditor 5 habt ihr euch sicherlich auch befasst, das wäre ja eine naheliegende Option gewesen. Was Funktionalität betrifft, bietet der natürlich eine Menge. Von TipTap auf der anderen Seite habe ich noch nie gehört. Mich würde interessieren, welche Anforderungen TipTap besser erfüllt.


      Vielleicht ist das sogar eine Idee für einen etwas Blog-Artikel? Es geht hier ja um eine grundlegende Architektur-Entscheidung, welche vermutlich die Basis für die nächsten Jahre sein soll. Bei so etwas ist es immer gut, die geprüften Optionen, die Kriterien sowie den Entscheidungsprozess zu dokumentieren. Vielleicht ist das intern sogar passiert. Sowas kann aber auch für andere interessant sein. Die Zielgruppe für so einen Artikel wäre natürlich etwas spezieller, aber ich fände das sehr interessant. Wie generell Artikel, die etwas Einblicke in die Gedanken der Entwickler geben. ;)

    • Die Entscheidung für TipTap ist effektiv auf Grund von ProseMirror getroffen wurden. Bis vor wenigen Monaten war ProseMirror noch vollständig „JavaScript“ und TipTap bot eine durchgehende Implementierung auf Basis von TypeScript. Inzwischen wurde ProseMirror fast vollständig auf TypeScript umgestellt, so dass ich aktuell einen Wechsel direkt zu ProseMirror nicht ausschließe.


      CKEditor 5 und ProseMirror haben eines gemeinsam: Die Verwendung von contenteditable rein als I/O-Layer, wobei die Verarbeitung von Interaktionen sowie das DOM komplett dem Browser entzogen wird. Generell gilt, dass contenteditable in allen Browsern durchgehend einen Totalschaden darstellt und für fast alle Bugs von WYSIWYG-Editoren verantwortlich ist. Im direkten Vergleich konnte mich ProseMirror stärker überzeugen, auch wenn es relativ nah beieinander liegt.


      Ein Beispiel wäre Froala: Einfach mal mit Strg/Cmd+A alles markieren, auf „More Paragraph“ klicken und dann bei „Paragraph Format“ auf „Code“. Jetzt die Selektion aufheben, erneut alles per Tastatur markieren und jetzt immer wieder auf „Code“ klicken. Erst ändert sich der untere Teil, dann wird die Bildunterschrift verändert und ab dem 3. Mal werden mitten drin neue Zeilen eingefügt. Und ja, ein nachträgliches „Als Code formatieren“ ist ein typischer Anwendungsfall, der mir auch beim Redactor immer wieder Schweiß auf die Stirn getrieben hat…

      Gefällt mir 1
    • Interessant ^^ ich bin auf den neuen Editor auf alle Fälle mal gespannt.

    • Der CKEditor wird ebenfalls auf TypeScript umgestellt. Die heute veröffentlichte Version 35 beinhaltet bereits die erste migrierte Komponente. Da das offensichtlich ein Argument war, der CKEditor im Test sowieso sehr dicht bei TipTap lag, mir der CKEditor allerdings sehr, sehr viel mächtiger erscheint und bei mir sogar die offizielle Demo von TipTap mehrere Sekunden (!) benötigt, bis sie fertig initialisiert ist, hoffe ich, dass diese Entscheidung noch nicht final ist.

  • ein verschachteltes Hauptmenü im Desktop-Modus wäre der Hit :D

    • Was ist mit dem „verschachtelten Hauptmenü“ gemeint? Aufklappbare Untermenüs?

    • genau :)

  • Verstehe ich das richtig, dass die geplante Version 5.6 übersprungen wird und es gleich zu Version 6 gehen wird? :/


    Auf jeden Fall coole Verbesserungen! :)

    • Ja, das ist korrekt. Damit möchten wir deutlich machen, dass es zu – wenn auch wahrscheinlich meist überschaubaren – Inkompatibilitäten kommt. Ebenso nutzen wir die Gelegenheit um ein paar veraltete und überflüssige Komponenten zu entfernen und auf moderne PHP-Versionen umzustellen.

  • Find ich super. In dem Zuge könntet ihr auch, neben den Icons, ein paar weitere Design Anpassungen vornehmen. Ich denke hier an nichts großem, aber wenn sich der Standardstil etwas an eure Website orientiert würde das der Software frischen Wind geben. (Ich mag die Farbverläufe und die abgerundeten Ecken)

    Gefällt mir 3
  • Finde das eine Lizenz für einen höherpreisigen Editor doch die bessere Option für Woltlab ist, eine Option auf einen neuen umzuschalten ab der kostenpflichtigen, falls man dies für die kostenfreie Core nicht möchte, wäre eindeutig die bessere Lösung aus meiner Sicht. Besonders nachhaltig und langfristig

    • Die Lizenz-Kosten für einen Editor sind nachrangig (*), viel wichtiger ist, dass ein Editor am Ende das leistet, was dieser soll. Wir haben uns eine ganze Reihe kostenpflichtiger Lösungen angesehen und keine davon konnte uns überzeugen. Unsere Entscheidung basiert primär darauf, was das Beste ist und nicht wie viel es kostet.


      (*) Der Hauptkostenfaktor ist die Integration in die Software mit allem was dazu gehört, zugleich stellt der Editor eine wichtige Komponente in unserer Software dar.

      Gefällt mir 1
  • Ist davon auszugehen, dass das WSC 6 auch weiterhin stellenweise noch jQuery nutzt?

    • Ja, jQuery und jQuery UI werden in unveränderter Fassung zur Verfügung stehen.


      Wir arbeiten kontinuierlich daran, die verbleibenden jQuery-basierten Komponenten durch moderne Lösungen zu ersetzen, dies ist allerdings mit erheblichem Aufwand verbunden und daher nur schrittweise möglich.

    • Jetzt hab ich die Befürchtung dass gewisse Plugins bereits mit der nächsten Version nicht mehr funktionieren werden.


      #rettetdencommunitybot ;(


      Hab aufs falsche Kommentar geantwortet, sry

      Gefällt mir 1