Donnerstag, 16. April 2026
Styx 5.1-rc1 und PHP 8.3.30
Alle Plugins aktualisiert (auch imagesidebar).
Habe das Bild 202411_04.jpg kopiert, umbenannt in 202411_94.jpg und versuchte es wieder in die Mediathek hochzuladen. Gleiches Ergebnis. Das Backend stürzt ab, auf einer weissen Seite wird mir 502 Bad Gateway angezeigt und wenn ich wieder im Backend in die Mediathek schaue, dann ist das Bild zwar hochgeladen, es wurden jedoch keine .avif-Varianten erzeugt.
Dann habe ich das Bild um ca. 100kB weiter komprimiert, umbenannt in 202411_95.jpg und erneut hochgeladen. Nun hat es funktioniert und es wurden korrekte .avif erzeugt. (so ist es jetzt im vorhergehenden Beitrag implementiert). 👍
Ich denke, dass meine Vermutung "es liegt an Bild 04, weil die anderen 6 problemlos funktionierten" wohl stimmt. Was jedoch an diesem Bild anders ist, kann ich nicht sagen. Wenn Du willst, kann ich es Dir zumailen.
Tolles Wetter hier. Gehe nun aufs Bike und bin bis abends nicht mehr vor der Tastatur. 
Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2714-Styx-5.1-rc1-und-PHP-8.3.30.html«
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Ian Styx am :
Ich hatte den Zusatz mit den 6 anderen Bildern gar nicht so recht bedacht. Aber ja deine Schlussfolgerung ist wohl richtig. Vielleicht ist es genau in einer der zwei Größen die ich im development cycle zwischen PHP 8.1 und 8.2 vor Jahren als problematisch ausgemacht hatte und deren Restriktion ich jetzt erst mit der 5.1.rc1 entfernt habe. Bis aufs Byte genau wäre allerdings fast wie ein Großtreffer im Lotto... 😄 Wir werden es sehen.
Ich habe mir dein hochgeladenes 202411_94.jpg kopiert und bei mir installiert. Kein Problem mit AVIF. Nun ist das natürlich nicht dein Original Upload file, da schon beim hochladen komprimiert, aber nur an das komme ich heran.
Besser ist also wenn du es mir in deinem Originalformat (in dem du es hochgeladen hast) einmal per mail zuschickst. Vielleicht ebenso zusätzlich mal das Smartphone ORGIN bevor du es zugeschnitten hast.
Ich habe heute noch ein paar weitere editor iframe content CSS in die custom content css eingepflegt, denn die Art wie du Bildgalerien erstellst hatte ich in der rc1 nicht berücksichtigt. Auch in der pure backend preview musste noch etwas für solche geändert werden damit sich die Bilder nicht über 100% Breite überspannen. Allerdings gibts da dann noch ein paar Fragen, denn irgendetwas ist bei dir anders als bei mir. Das sollten wir dannj auf einem Test Blog mit Original pure theme überprüfen.
Ian Styx am :
Ich habe beide überprüft und kein ungewöhnliches Verhalten oder Größe feststellen können. Sie waren von Letzterer, die vielleicht hätte problematisch sein könnte, auch meilenweit entfernt, selbst wenn man die unterschiedlichen Serverkonfigurationen für das encoding einmal abzieht.
Das einzige was bleibt ist, ob du es mit der RC1 einfach noch einmal in deiner Serverkonfiguration versuchst, da ich ja die beiden genannten fixen Größen für die broken Rückmeldung von früher darin entfernt habe. Auch ist es nicht die Uploadgröße selbst, sie könnte also auch größer sein. Wahrscheinlich hätte es also auch ein weniger starke Kompression deinerseits getan.
Allerdings und das bezieht sich auf der genannten Errormeldung ist dies eine immer wieder auftauchende Errormeldung in NGinx Konstellationen und eventuellen Nodejs Servern und bezieht sich irgendwie aber wahrscheinlichst auf einen (zu kurz gesetzten) timeout (eines auslagernden Prozeßes) der nicht lange genug warten will und sich selbst schließt, während der upstream Prozeß noch zu lesen versucht
; also nichts was ich beeinflussen könnte.