Was sind denn alte Kopien von CMS Seiten?
Meinst du das Änderungsprotokoll?
WoltLab Suite 5.5: Vorschau auf die neue Version
-
-
Was sind denn alte Kopien von CMS Seiten?
Meinst du das Änderungsprotokoll?
Genau, diese "vorherigen Versionen".
Die nehmen bei mir zur Zeit unnötig >20Mb in der Datenbank ein.
-
Um nochmals auf diese bisher nicht beantwortete Frage einzugehen. ...
Ich schreibe ja hin und wieder mehr als drei Zeilen Text in meinem Magazin: https://twentymag.net/ und das Formatieren klappt halt einfach nicht zuverlässig dabei sind die Formatierungen alles andere als Umfangreich oder anspruchsvoll- Ständig ist man am Löschen und Einfügen von Leerzeilen. Das nachträgliche Einfügen von Inhalten in bereits formatieren Text ist jedes mal ein Risiko weil man nie weiß wie die Formatierungen übertragen werden. Es gibt keine Möglichkeiten Formatierungen zuverlässig wieder zu entfernen.
Dann gibt es weitere unpraktische Dinge wie das Bilder in Originalgröße eingesetzt nicht im Imageviewer enthalten sind. Ich will häufig eine größere Ansicht im Text einfügen, aber wenn ich das mache läßt sich das Bild nicht mehr zum Vergrößern anklicken.
-
Als Hotfix könnte man die Match-Klasse umbenennen
Das habe ich mal gemacht und bis jetzt funktioniert sogar alles.
sicherstellen, dass er trotzdem die richtige Tabelle nimmt.
wie macht sich das bemerkbar?
Pakete neu hoch laden geht ohne Probleme, auch wird der Paketserver als online angezeigt mit Paketen.
-
Das macht höchstens Probleme beim Aufruf via WSC, wenn geprüft wird, ob eine IP Adresse zu einem Account gemappt werden soll. Sprich im Zweifelsfall setzt man bei einem Fehler einfach $databaseTableName statt sich auf den Automatismus im WSC fallen zu lassen. Solange der Server funktioniert, sollte das aber nicht notwendig sein.
-
Danke dir, ich werde es im Auge behalten, wenn nicht muss ich dich noch mal nerven.
-
Hallo,
Stand jetzt ist, dass 5.5 für den Endkunden gefühlt nicht wirklich einen Mehrwert in Bezug auf 5.4 bietet.
Ich finde schon, dass allein die neue mobile Benutzeroberfläche einen deutlichen Mehrwert gegenüber WoltLab Suite 5.4 bietet. Damit man das aber merkt, muss man die Community auch (intensiv) mobil nutzen, da ist man als Administrator möglicherweise einfach die falsche Person, wenn man das eigene Forum meist am Rechner sieht.
Ansonsten finde ich es aus Sicht einer Person mit technischem Verständnis auch problematisch, den Mehrwert eines Upgrades rein anhand der sichtbaren Änderungen zu beurteilen, denn es fließen auch jedes Mal viele unsichtbare Änderungen ein, die mindestens genau so wichtig sind, in einem Vorstellungsartikel aber gar nicht sinnvoll und attraktiv erklärt werden können. Das sind abstrakte Dinge, wie Performance-Verbesserungen oder Verbesserungen an der Sicherheit. Oder es sind einfach notwendige Aufräumarbeiten in über 15 Jahre altem Code, die unmittelbar keine Wirkung zeigen, aber zukünftige Anpassungen erleichtern, dazu ist der Artikel für Entwickler wohl ein gutes Beispiel: https://www.woltlab.com/articl…ler-in-woltlab-suite-5-5/
Diese Änderung erhöht die Systemanforderungen nicht. Attribute sind in PHP vorwärts- und rückwärtskompatibel. Wolltest du den PR für die 64-Bit-Anforderungen verlinken?
Ansonsten ist auch dieser PR ein gutes Beispiel für „unsichtbare“ Änderungen: Das dem PR zugrundeliegende neue „SensitiveParameter“-Attribut habe ich in PHP im Rahmen meiner regulären Arbeitszeit („on company time“) als RFC eingereicht: https://wiki.php.net/rfc/redact_parameters_in_back_traces. Diese Arbeitszeit kommt nicht unmittelbar der Weiterentwicklung von WoltLab Suite zu Gute, stattdessen profitiert das PHP-Ökosystem im Ganzen von einer verbesserten Sicherheit, wovon dann mittelbar irgendwann auch Kunden der WoltLab Suite profitieren. In diesem konkreten Fall, weil etwaige Kennwörter zuverlässig in Fehlermeldungen unterdrückt werden.
Ich tippe darauf, dass das auch gar nicht das Forum an sich war, sondern elasticsearch.
Das war tatsächlich ein Bug im Forum, der aber nur in Kombination mit Redis sichtbar wurde. Elasticsearch ist seit WoltLab Suite 5.5 komplett async angebunden: https://www.woltlab.com/articl…-verwaltung-des-suchindex
Zum Editor möchte ich auf diesen Beitrag verweisen: https://www.woltlab.com/commun…ostID=1872412#post1872412. Hier besteht das Problem von Schrödingers Rückwärtskompatibilität. Die Kompatibilität muss gleichzeitig gewahrt und gebrochen werden: Es wird erwartet, dass die Kompatibilität unter allen Umständen gewahrt wird, damit die verwendeten Plugins nicht kaputt gehen. Wenn das aber dazu führt, dass der eigene Vorschlag nicht oder nicht kurzfristig umgesetzt werden kann, dann muss natürlich mit der Kompatibilität gebrochen werden, egal was mit den Plugins ist. Egal für was man sich entscheidet: Irgendjemand ist hinterher immer unzufrieden.
Korrigierbare Probleme werden aber mehrmals monatlich (https://github.com/WoltLab/WCF…les/js/3rdParty/redactor2) auch mit dem aktuellen Editor korrigiert. Das setzt natürlich voraus, dass diese (a) zuverlässig reproduzierbar sind und (b) auch tatsächlich gemeldet werden. Ich stolpere auch hin und wieder darüber, dass der Editor nicht so möchte, wie ich möchte. Aber meist habe ich dann schon längst vergessen, was ich gemacht habe um die Situation herbeizuführen, dann ist der Fehler leider auch nicht korrigierbar.
Dann gibt es weitere unpraktische Dinge wie das Bilder in Originalgröße eingesetzt nicht im Imageviewer enthalten sind. Ich will häufig eine größere Ansicht im Text einfügen, aber wenn ich das mache läßt sich das Bild nicht mehr zum Vergrößern anklicken.
Ich glaube das ist in WoltLab Suite 5.5 bereits angepasst (aber don't quote me on this). Ansonsten ist es natürlich notwendig, dass Wünsche auch als Wünsche im Forum eingebracht werden, statt sich still darüber zu Ärgern. Hellsehen kann man nicht
-
Alles anzeigen
Hallo,
Ich finde schon, dass allein die neue mobile Benutzeroberfläche einen deutlichen Mehrwert gegenüber WoltLab Suite 5.4 bietet. Damit man das aber merkt, muss man die Community auch (intensiv) mobil nutzen, da ist man als Administrator möglicherweise einfach die falsche Person, wenn man das eigene Forum meist am Rechner sieht.
Ansonsten finde ich es aus Sicht einer Person mit technischem Verständnis auch problematisch, den Mehrwert eines Upgrades rein anhand der sichtbaren Änderungen zu beurteilen, denn es fließen auch jedes Mal viele unsichtbare Änderungen ein, die mindestens genau so wichtig sind, in einem Vorstellungsartikel aber gar nicht sinnvoll und attraktiv erklärt werden können. Das sind abstrakte Dinge, wie Performance-Verbesserungen oder Verbesserungen an der Sicherheit. Oder es sind einfach notwendige Aufräumarbeiten in über 15 Jahre altem Code, die unmittelbar keine Wirkung zeigen, aber zukünftige Anpassungen erleichtern, dazu ist der Artikel für Entwickler wohl ein gutes Beispiel: https://www.woltlab.com/articl…ler-in-woltlab-suite-5-5/
Diese Änderung erhöht die Systemanforderungen nicht. Attribute sind in PHP vorwärts- und rückwärtskompatibel. Wolltest du den PR für die 64-Bit-Anforderungen verlinken?
Ansonsten ist auch dieser PR ein gutes Beispiel für „unsichtbare“ Änderungen: Das dem PR zugrundeliegende neue „SensitiveParameter“-Attribut habe ich in PHP im Rahmen meiner regulären Arbeitszeit („on company time“) als RFC eingereicht: https://wiki.php.net/rfc/redact_parameters_in_back_traces. Diese Arbeitszeit kommt nicht unmittelbar der Weiterentwicklung von WoltLab Suite zu Gute, stattdessen profitiert das PHP-Ökosystem im Ganzen von einer verbesserten Sicherheit, wovon dann mittelbar irgendwann auch Kunden der WoltLab Suite profitieren. In diesem konkreten Fall, weil etwaige Kennwörter zuverlässig in Fehlermeldungen unterdrückt werden.
Das war tatsächlich ein Bug im Forum, der aber nur in Kombination mit Redis sichtbar wurde. Elasticsearch ist seit WoltLab Suite 5.5 komplett async angebunden: https://www.woltlab.com/articl…-verwaltung-des-suchindex
Zum Editor möchte ich auf diesen Beitrag verweisen: https://www.woltlab.com/commun…ostID=1872412#post1872412. Hier besteht das Problem von Schrödingers Rückwärtskompatibilität. Die Kompatibilität muss gleichzeitig gewahrt und gebrochen werden: Es wird erwartet, dass die Kompatibilität unter allen Umständen gewahrt wird, damit die verwendeten Plugins nicht kaputt gehen. Wenn das aber dazu führt, dass der eigene Vorschlag nicht oder nicht kurzfristig umgesetzt werden kann, dann muss natürlich mit der Kompatibilität gebrochen werden, egal was mit den Plugins ist. Egal für was man sich entscheidet: Irgendjemand ist hinterher immer unzufrieden.
Korrigierbare Probleme werden aber mehrmals monatlich (https://github.com/WoltLab/WCF…les/js/3rdParty/redactor2) auch mit dem aktuellen Editor korrigiert. Das setzt natürlich voraus, dass diese (a) zuverlässig reproduzierbar sind und (b) auch tatsächlich gemeldet werden. Ich stolpere auch hin und wieder darüber, dass der Editor nicht so möchte, wie ich möchte. Aber meist habe ich dann schon längst vergessen, was ich gemacht habe um die Situation herbeizuführen, dann ist der Fehler leider auch nicht korrigierbar.
Ich glaube das ist in WoltLab Suite 5.5 bereits angepasst (aber don't quote me on this). Ansonsten ist es natürlich notwendig, dass Wünsche auch als Wünsche im Forum eingebracht werden, statt sich still darüber zu Ärgern. Hellsehen kann man nicht
Unsichtbare Änderungen lassen sich aber nicht gut verkaufen und sollten daher immer Hand in Hand mit sichtbaren Änderungen laufen, damit ein Update auch gerechtfertigt werden kann. Es gibt ein Haufen weise guter Vorschläge die eine sichtbare Veränderung herbei führen würden, also am Mangel an Ideen kann es nicht liegen.Aktuell ist bei 5.5 einfach 0 bei was einem das Update schmackhaft machen könnte und da nur auf die Performance zu verweisen macht aus dem oben genannten Grund kein Sinn mal abgesehen davon das die Version 5.4 auch ordentlich läuft und kaum ein normaler User wird da irgendwas merken nur weil die Reaktionszeit sich um 2sec verbessert.
-
Hallo,
Unsichtbare Änderungen lassen sich aber nicht gut verkaufen und sollten daher immer Hand in Hand mit sichtbaren Änderungen laufen, damit ein Update auch gerechtfertigt werden kann.
Ja, vollkommen richtig. Deswegen enthält WoltLab Suite 5.5 auch sichtbare Änderungen, die in den Vorstellungsartikeln vorgestellt wurden. Es mag sein, dass diese Änderungen für deinen Einsatzzweck weniger interessant sind, etwa, weil deine Nutzer primär am Rechner unterwegs sind und deswegen nicht von der verbesserten mobilen Ansicht profitieren. Naturgemäß kann aber nicht jede Änderung für jeden gleichermaßen interessant sein. Ich persönlich kann mit der Funktion zum Ignorieren von Themen beispielsweise nicht viel anfangen, habe ich nie vermisst. Ich sehe aber, dass andere Nutzer diese sehnsüchtig erwarten.
und da nur auf die Performance zu verweisen macht aus dem oben genannten Grund kein Sinn mal abgesehen davon das die Version 5.4 auch ordentlich läuft und kaum ein normaler User wird da irgendwas merken nur weil die Reaktionszeit sich um 2sec verbessert.
Ich habe ja auch nicht ausschließlich („nur“) auf die Performance verwiesen. Direkt daneben steht beispielsweise die Verbesserung der Sicherheit. Und natürlich die vorgenannten deutlich sichtbaren Verbesserungen.
Zum konkreten Punkt der Performance: Selbstverständlich bemerkt ein normaler Nutzer eine Verbesserung von 2 Sekunden. 2 Sekunden ist eine halbe Ewigkeit! Wenn ich bei jedem Klick zwei Sekunden darauf warten muss, dass die Seite lädt, dann bin ich spätestens nach dem dritten Klick so sehr genervt, dass ich die Seite schließe und mich anderen Dingen widme. Bereits zweistellige Millisekunden Unterschied machen einen deutlich spürbaren Effekt aus, das kann den Unterschied zwischen „Die Seite ist sofort nach dem Klick auf dem Link da“ und „Ich muss warten“ ausmachen.
-
Ich finde schon, dass allein die neue mobile Benutzeroberfläche einen deutlichen Mehrwert gegenüber WoltLab Suite 5.4 bietet.
Es fühlt sich teilweise seltsam an - wenn man auf die Action-Buttons und das User-Panel schaut. Das Menü selbst ist aber eine deutliche Verbesserung.
Diese Änderung erhöht die Systemanforderungen nicht. Attribute sind in PHP vorwärts- und rückwärtskompatibel. Wolltest du den PR für die 64-Bit-Anforderungen verlinken?
Nein, das war durchaus so beabsichtigt zwecks Perspektive auf PHP 8.2. Die 64-Bit-Anforderung hatte ich schon wieder ganz verdrängt.
der aber nur in Kombination mit Redis sichtbar wurde.
Gut, knapp vorbei.
Hier besteht das Problem von Schrödingers Rückwärtskompatibilität. Die Kompatibilität muss gleichzeitig gewahrt und gebrochen werden
Ich denke meine Ansicht dazu ist zur Genüge bekannt. Das was ohne Bruch geht, jetzt und dann mit 6.0 mal wieder ordentlich alles überarbeiten und einen klaren Schnitt setzen. Das ist nur schwierig zu vermarkten denke ich.
Hellsehen kann man nicht
Nicht? :o
Ich gehe dann mal einkaufen
