WoltLab Suite 6.0: Vorschau auf die neuen Funktionen

    • Teambeitrag

    So, ich habe für die Stile schnell eine Option zusammen gefummelt damit sich keiner mit Javascript rumschlagen muss das ist nämlich echt eklig. Nebenbei hab ich das auch gleich in alle Stile eingebaut 😬

    Das wars dann für dieses Jahr 🥳 Hab keine Lust mehr 🌝



    Aze /..


    ich hoffe ich leake kein Geheimnis, aber es soll ein Menü-Icon-Plugin für 6.0 geben 🥸 Ansonsten ist es auch kein Problem das selbst zu machen, das ist mit Javascript kaum aufwendiger als mit CSS.

  • ist der Editorwechsel mit WSC 6.0 eigentlich gestorben?

    Der Austausch des Editors ist weiterhin aktuell.

    Auf GitHub ist aber nach wie vor nicht ein Commit oder Issue bezüglich des Editors zu sehen.

    Die Entwicklung des Editors erfolgt in einem (noch) privaten Repository und bleibt auch zukünftig dauerhaft getrennt. Der Editor wird also wie jede andere „externe“ Abhängigkeit betrachtet.

    Im Gegenteil, es finden sich explizit im master-Branch (kann man den nicht mal umbenennen?) Commits, die Redactor-Probleme beheben:

    Das ist nicht korrekt. Der Commit ist in 5.5. GitHub blendet in der Commit-Ansicht alle anderen Branches aus, wenn der Commit im Standard-Branch ist.

    Ich glaube sie passen erst die Umgebung für den neuen Editor an, anders kann ich mir die Aktuellen Anpassungen nicht erklären.

    Ganz falsch ist das nicht: Der Editor ist effektiv in sich geschlossen und auch nur für wenige Plugins unmittelbar relevant (für die meisten Plugins kann der einfach als Blackbox betrachtet werden), entsprechend hatten Dinge Priorität, die deutlich elementarer sind – etwa die Icons und die PSR-7/-15-Anpassungen.

    Fehlende Icons, fehlende Sprachvariablen

    Nicht sicher, ob ich das richtig verstehe, aber, wenn noch irgendwo Icons oder Sprachvariablen fehlen, dann ist das selbstverständlich ein Fehler. Siehe auch:


    https://www.woltlab.com/community/thread/298081-entscheidung-des-editors-f%C3%BCr-wsc-6-0/?postID=1912277#post1912277

    Für mich sieht die dev wie eine ganz frühe Alpha aus und bei den großen umbauten wären ein paar mehr Infos von Woltlab echt hilfreich.

    Für mich sieht das nicht wie eine Alpha aus, alles was schon an Änderungen erfolgt ist, ist im Großen und Ganzen als fertig zu betrachten. Sicherlich ist das nichts, was man schon veröffentlichen würde (es ist ja schließlich noch was geplant), aber mit einer frühen Alpha würde ich das nicht vergleichen. Grundsätzlich ist das Ziel, dass der aktuelle Entwicklungsbranch dauerhaft so stabil ist, dass man ihn theoretisch jederzeit veröffentlichen könnte.

    Und ein wenig unscharf sind sie noch.

    Bei mir sind die Icons scharf.

    Jo 👀 Ich denke mal die Implementierung ist noch nicht ganz fertig. Oder werden die wirklich so unscharf bleiben 🤔

    Wenn mit den Icons noch etwas nicht passt, dann ist das ein Fehler, siehe: https://www.woltlab.com/commun…ostID=1909530#post1909530


    Melde die unscharfen Icons also bitte als Fehler (siehe erster Link oben) – natürlich mit entsprechenden Informationen wie Browser, Betriebssystem und was auch immer alles dazu gehört.

    Die Dialoge sehen nun auch anders aus, ich dachte erst das sind Systemdialoge von macOS 😬

    Hinweis zu den Screenshots: Deine Instanz ist kaputt, auf dem ersten Screenshot sieht man noch den „Missing Texture“-Platzhalter, der auf veraltete Templates hindeutet.

    ich habe da nur Bahnhof verstanden, aber wie es aussieht beteiligt sich WoltLab jetzt auch an der PHP-Entwicklung:

    Eigentlich war geplant, dass der Artikel auch für Laien grundsätzlich verständlich ist – aber ja, dein Fazit ist korrekt. Wir haben Features an PHP 8.2 beigetragen, ich privat auch schon für PHP 8.3.

    An der Darstellung der Icons muss definitiv noch gearbeitet werden, zumindest im User Menu. Da passt der Abstand zum Text noch nicht.

    Auch das ist dann bitte, mit ein paar zusätzlichen Details, als Fehler zu melden.

    Ich hoffe mal das es bei künftigen Versionen dann wieder einfacher und schneller geht.

    Das hoffe ich auch. Durch den neuen {icon}-Helper bzw. die WebComponent für die Icons, haben wir jetzt dann aber theoretisch die Möglichkeit irgendwelche Logik zur Kompatibilität zu implementieren. Mit Icons, die im CSS direkt referenziert werden, geht das nicht wirklich (abgesehen von all den anderen Nachteilen von Icons im CSS).

    Sieht mir schon nach latest shit aus:

    😬


    Zumindest hängen da noch so einige Hoster hinterher. MariaDB ist aber wohl wesentlich älter.

    Die Systemanforderungen orientieren sich jeweils an den Linux-Distributionen. Im Falle von MySQL 8 ist das irgendeine Ubuntu LTS, die ebenjene Patch-Version von MySQL 8.0 inkludiert. Grundsätzlich ist MySQL 8 jetzt aber auch schon über 4 Jahre alt, ich verstehe ja, dass man mit dem Wechsel auf eine Major-Version ggf. ein wenig wartet, aber zumindest die Patch-Versionen sollten zeitnah eingespielt werden. Die kommen bei MySQL regelmäßig alle 3 Monate und sind damit planbar. MySQL 5.7 ist übrigens im Oktober EOL.

    Der SASS-Compiler ist noch drin, Stile laufen also weiter ohne Änderung, man muss nur die Templates aktualisieren. Ob das so bleibt?

    Der SCSS-Compiler bleibt uns auf absehbare Zeit erhalten. Zur Erinnerung: Man bricht die Kompatibilität ja nicht zum Spaß und eine Entfernung des SCSS-Compilers bringt keinen unmittelbaren Vorteil.

    bis Heilige Drei Könige wie alle anderen auch

    Wer ist „alle anderen“? Die heiligen drei Könige sind nur in 3 Bundesländern und für etwa ein Drittel aller Einwohner ein Feiertag :)

  • und bleibt auch zukünftig dauerhaft getrennt. Der Editor wird also wie jede andere „externe“ Abhängigkeit betrachtet.

    Ich verstehe dich richtig, dass es in Zukunft ein eigenes WSC-Paket wird?

    Wie verhält sich das dann zwecks Auslieferung? Analog zu Impressum oder analog zum Verwarnsystem? Und wie verhält sich das mit Integrationen wie bei Artikeln oder im FormBuilder?

    Oder wird der Editor als angepasste Version in einem eigenen Repo betreut (privat oder öffentlich?) und dann per Composer oder TS respektive npm im WSC bereitgestellt?


    GitHub blendet in der Commit-Ansicht alle anderen Branches aus, wenn der Commit im Standard-Branch ist.

    Ah, hätte ich in der IDE schauen sollen. Dann habe ich nichts gesagt. ^^


    entsprechend hatten Dinge Priorität, die deutlich elementarer sind

    Wenn das Experiment zugänglich wäre, könnte man hier aber auch outsourcen. ;)

    Wobei man das dann auch wollen muss, sonst läuft es wie mit der Aussage, dass gerne ein Wechsel auf den FormBuilder im ACP beigetragen werden kann. ^^


    Nicht sicher, ob ich das richtig verstehe, aber, wenn noch irgendwo Icons oder Sprachvariablen fehlen, dann ist das selbstverständlich ein Fehler. Siehe auch:

    Vor einigen Wochen waren noch sehr viele Sprachvariablen plain angezeigt, wobei ich eher der Meinung war, dass die nicht korrekt geladen wurden, da es mir primär bei Dialogen (gerade in den DevTools) aufgefallen ist. Inzwischen sind aber die Icons und Sprachvariablen eigentlich auf normalem Niveau würde ich behaupten. Ich denke, dass sich das inzwischen erledigt hat.


    Der SCSS-Compiler bleibt uns auf absehbare Zeit erhalten. Zur Erinnerung: Man bricht die Kompatibilität ja nicht zum Spaß und eine Entfernung des SCSS-Compilers bringt keinen unmittelbaren Vorteil.

    Was wäre denn überhaupt die Alternative? Plain-CSS? Oder verstehe ich euch falsch?