Das verstehe ich nicht, in welchem Kontext meinst du das? Wer verwendet Plugins als Ausrede für iregnd was?
Woltlab hat klar in einem Statement gesagt das ein Grund dafür war das sie die Live Aktualisierung nicht umgesetzt haben weil es dafür ja schon ein Drittanbieter Plugin gäbe.
Tom Ich finde es gravierende Drittanbieter Plugins als Ausrede zu verwenden, man sollte es immer vermeiden wenn möglich auf solche Plugins zu verzichten. Wir haben ja in den letzten zwei Jahren gesehen wie schnell Es gehen kann das Entwickler auf hören.
Mal davon habe ja auch selbst Woltlab davor warnt zu viele Plugins zu nutzen, was man ja gern machen würde wenn es im Standard Umfang wäre … in dem Punkt wieder sprechen sie sich also.
Ja es gibt einiges was da verbessert werden könnte oder gänzlich fehlt also es gibt eigentlich noch so viel was da gemacht werden könnte aber allgemein bei dem verschiedenen Apps. Da frage ich mich wirklich warum das so stagniert.
Jaja diese Ausrede nervt mich auch tierisch vor allem woher sie wohl wissen wie viele eigene Server haben oder interessiert sind ich habe keine Umfrage diesbezüglich gesehen….
ja das mit den Textzeilen nervt mich auch, er muss auf eine Meute Version aktualisieren dann geht das erst.
ja ich hätte auch massig Ideen aber wofür damit sie gleich wieder auf nicht geplant gesetzt werden? Ne das macht kein Spaß habe schon einige Ideen eingereicht die andere CMS schon seit Jahren können aber daran ist Woltlab nicht interessiert lieber Alt backen.
Neuerungen in WoltLab Suite 5.5: Live-Aktualisierung
Sehr gut, aber als Benutzer eines Webspaces ist man davon ausgeschlossen.
ja das vermisse ich auch ich finde schade das man hier sinnlos die Zeit verschwendet hat und das nur für sich umgesetzt hat. Dabei ist genau das eine Neuerung die überzeugen würde/könnte aber an sowas wird dann nicht gedacht.
Hallo,
dann würde ich in einen Webhoster investieren, der den Server sinnvoll konfiguriert. Wenn es um die Seite aus deiner Signatur geht, dann ist beispielsweise HTTP/2 nicht im Einsatz, was durch den Overhead für einzelne Requests und die große Menge von Plugin-JavaScript die Ladezeiten deutlich erhöht. Die fast 4 MB an Hintergrundbild tun ihr übriges.
Moin ich verwalte den Server selber der läuft einwandfrei bin gerade erst umgezogen auf SSD. Stimmt den HTTP/2 habe ich vergessen stelle ich heute direkt mal um. Das mit dem Logo ist auch bekannt das würde aber auch nicht so extreme Verzögerung sorgen bei den heutigen Geschwindigkeit aber das werde ich auf jeden Fall verkleinern.
ich habe nur 63 Pakete installiert davon sind einige dabei die bei Plugins mit installiert wurden, da gibt es welche die bei weitem mehr installiert haben, also daran kann es auch nicht liegen. Glaube mir ich Rätsel da schon ewig rum vor allem ich nutze Redis für den cash etc. Auf meinem Server läuft noch eine Website von einem anderen Projekt (nicht meins ) das läuft Performer auch mit 5.3. ich weis nicht ob die 5.3 irgendwelche Anfälligkeit hat aber ich bekomme es auch nicht so richtig raus.
Ich persönlich nutze unsere Website aktuell zu 99% Mobil und bei den meisten Neuerungen im Designe graut es mit allein schon das das Burger Menü jetzt rechts ist ist ein Graus. Sowas sorgt dafür das ich alles wieder rückgängig machen muss ein Haufen unnötiger Arbeit. Hier wurde einfach verschlimmbessert. Somit ist bleibt bei 5.5 nur noch das was unter der Haube ist. Das blöde ist auch noch das ich schon zwei Versionen zurück hänge wollte eigentlich jetzt auf 5.5 gehen aber hinsichtlich der Änderungen fällt es mir schwer.
zum Thema 2sec gebe ich dir recht hier wäre eher zu sagen 0,002. bei den letzten Updates habe ich in der Hinsicht aber nie was war genommen im Gegenteil so extrem langsam wie die aktuelle mobil läuft hatte ich’s noch nie. Es macht echt kein Spaß auf unsere Seite Mobil.
Alles anzeigenHallo,
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.
Deinen Worten zufolge hast du dies also bereits ausgiebig getestet?
Auch wenn dieser Beitrag inhaltlich nur durch mehrfaches lesen einigermaßen verständlich wird, verstehe ich aber dennoch nicht den Kern des Beitrags.
Das braucht man nicht testen, das weis man zumindest wenn man sich mit php auskennt und auch die entsprechende Erfahrungswerte hat.
Entschuldige ich schreibe vom Handy irgendwie will das dann nicht immer so wie ich will.
Worauf ich hinaus will ist. Das es nicht kommerzielle Anbieter gibt, die kostenlos ihre Plugins bereit stellen (außerhalb des Woltlab PluginStores). Aber ihre eigene Seite nicht zwangsläufig auf der Aktuellsten Woltlab Version haben, somit auch nicht an eine Beta Version kommen. Was zur Schlussfolgerung führt das sie ihr Plugin nur bedingt auf die neue Version an passen können. Sprich User die ihre Plugins nutzen aber gern aktuell bleiben wollen müssen also warten, bis es dem Entwickler möglich ist oder aber das Plugin löschen.
Ich hoffe ich konnte das ganze jetzt etwas verständlicher rüberbringen.
Jau in Bezug auf die cloud Hast du natürlich recht. Ein Schelm wer Böses denkt.
