Weblog Kommentare
Editor-Test-Beitrag
Ian Styx am |
Wir sprechen hier von der Beta1 und image builds generell mit GD.
Soweit so gut.... Für den Test hätte ich ja zumindest die RC1 installiert. die nochmal klüger in der Auswahl von fehlgebildeten Variationen ist und auch im Editor Fenster (als Galerie) besser ausschaut. Auch die Anmerkung zum Scrollen und Springen ist ja mit der RC nochmal besser geworden. Beim Scrollen muss man wie gesagt etwas warten bis die HIT BOX für die red magic line von selber verschwindet, das ist so wie diese verdammten Cookie Zustimmungs Layer überall, solange aktiv (also darübergelegt) kann man nicht zum Eigentlichen durchdringen. 😉
Allerdings ist ein
502 Bad Gateway error etwas das ich auch mit Styx nicht fixen kann. Das, sowohl als auch der proxy.error.log mit seiner Aussage, liegt außerhalb meiner Möglichkeiten und hängt mit den internen Umleitungen (V-Caches) deines Hosters zusammen.
Mich würde wundern wenn sie dir da konkret helfen könnten/würden, denn dazu müsstest du ihnen genau erklären was du da tust, dass das eigentlich nichts Ungewöhnliches ist, und das sie soetwas eigentlich flicken und supporten müssten.
Auch der error der auftritt wenn man die Variationen löscht und dann für dieses Bild neu bilden lässt ist darauf zurückzuführen. Da führt irgendetwas auf deren Seite ins Nirwana oder reagiert auf einen (in ihren Augen) etwas zu langen Request und blockt dann das was ansonsten funktioniert.
Styx 5.1-beta1 und PHP 8.3.30
Ian Styx am |
Solange dein Manitu GD nicht neu kompiliert wurde bleibt das auch so. ABER !!! Du könntest dortens auf ImageMagick umstellen und dann sollte dein Imagick Modul greifen.😀
Beat Post author am |
Nein, das funktioniert leider auch nicht. ImageMagick schreibt dann zwar ein avif-File, dieses ist jedoch korrupt (nur 145kb gross). Dieses Problem habe ich am 19.11.2025 hier beschrieben und daran hat sich bis heute nichts geändert. Ich bleibe also dabei: Manitu kann kein avif. Weder mit GD noch mit ImageMagick.
Ian Styx am |
Hmmm. Das war aber eines der Gründe warum ich die MediaLibrary endlich für Imagick erweitert habe. Sollte diese AVIF unterstützen sehe ich keinen Grund kläglich in einem 145 b file zu verenden. Manitus Imagick kann AVIF, laut eigener Aussage, siehe https://www.manitu.de/webhosting/phpinfo/#module_imagick. Vielleicht musst du mal das error Log bemühen um vielleicht den Grund näher zu bestimmen. Ansonsten kannst du durchaus noch einmal nachfragen ob sie es je richtig getestet haben. Wenn es eine fehlende Dependency wäre sollte eigentlich beim Upload im Erfolgsmessage soetwas wie
Imagick Error: no encode delegate for this image format `AVIF' @ error/constitute.c/WriteImage/1412
stehen. Dies deutet dann auf fehlende Schreibberechtungen und fehlende Pakete hin... Aber das hattest du wohl nicht, oder?
Nach all der Mühe fände ich es gut wenn wir das Problem lösen könnten.
lg
PS: Ich freue mich schon auf eure Fahrt. Die Gegend ist toll. Und vor ein paar Tagen gabs im TV einen Bericht darüber mit all den schönen Vulkanen und leckeren Genüßlichkeiten.
Beat Post author am |
Ich habe nun den ganzen avif-Käse auf dem Manitu-Testblog noch einmal durchexerziert. Das geht nicht und auch in den logs ist bezüglich ImageMagick nichts zu finden.
Ich fühle mich da wirklich sehr hilflos. Wie Du diesem (https://styx.beatsblog.ch/2667-naechster-AVIF-Test.html) Beitrag entnehmen kannst, habe ich sogar den Pfad zu ImageMagick angezweifelt und dass das Ergebnis bei zwei unterschiedlichen Pfadangaben zum Schluss identisch ist, macht mich noch ratloser. Ich bin einfach zu wenig in dieser Materie zuhause und offen gestanden auch zu wenig interessiert daran, als dass ich da noch weitere Stunden investieren will. Falls Du meinst, dass ich erneut eine Supportanfrage bei Manitu starten soll, so bitte ich Dich, mir den Text dafür vorzugeben.
Ian Styx am |
Für´n Schweizer ist halt alles Käse.... 😋
Da ich annehme das wir nicht mit dem Binary von ImageMagick direkt spielen können ist der Pfad zu diesem auch relativ egal. Da aber lt. Manitu PHP das Imagick Modul geladen ist, dient das als Ersatz und wird von Styx dem Ersteren auch immer vorgezogen.
Die Unterscheidung sollte Styx selbst vornehmen wenn die ImageMagick Option aktiv gesetzt wurde. Für den Fall dass das Modul selbst Abhängigkeiten (für AVIF) vermisst (out-of-the-box zb Debian), kann man die interne Unterscheidung durch eine private Serendipity Variable aber auf das Binary zurücksetzen, solange der Zustand so anhält. Aber das ist lösbar. Dieser Fall ist aber bei dir nicht ... der Fall.
Die PHP Version liest sich aus meiner Sicht so: Nimm immer die höchste Version solange dein System (wie Styx) es unterstützt ! Styx ist PHP8.5 ready. Die Empfehlung für 8.2 bezieht sich m.E. nur darauf für nicht PHP affine Personengruppen die am wenigsten Meldungskritische Variante für ihre Programme zu empfehlen.
Jetzt zur Frage warum AVIF trotzdem nicht funktioniert. Das ist - mit Verlaub - per Ferndiagnose Spökenkickerei, also mit Vorsicht zu genießen.
Zum ersten wäre die Frage ob wir nicht in den angelegten AVIF Dateien im internen Header irgendwelche Aussagen zur Fehlerursache finden. Du müsstest mir also beide bitte mal per Mail zuschicken.
Ich werde ein testscript schreiben müssen das uns vielleicht größere Klarheit bringen kann. Ich sag Bescheid wenn es fertig ist.
Du schreibst, dass wenn du ImageMagick abstellst, also die GD benutzt, folgende error Meldung in Styx beim upload bzw dem Schreiben der Variationen aufpoppt.. "Call to undefined function imageavif()... " Wie wir schon festgestellt hatten ist Manitus GD Kompilierung z.Z. noch unvollständig und kann kein AVIF. Allerdings ist diese Meldung doch merkwürdig. Sie sollte eigentlich so nicht vorkommen, denn ihre Nutzung ist als "verstecke-potentielle-Fehler" Nutzung geschrieben. Vielleicht aber ist das auch nur mein Unverständnis und die unvollständige GD Kompilierung hat tatsächlich PHP die imageavif() Methode noch gar nicht zur Verfügung gestellt, vielleicht muss sie dann trotzdem Bescheid geben...
Du hast in deinem Manitu System schon geschaut, ob du nicht eventuell das Imagick Modul bzw ImageMagick Binary irgendwie erst noch aktivieren musst, ...oder?
Ian Styx am |
Meldung 📯Ich habe dir was hinterlassen..,
aber halt ! Erst Frage(n) beantworten...
Beat Post author am |
📬 You've got mail.
Du hast in deinem Manitu System schon geschaut, ob du nicht eventuell das Imagick Modul bzw ImageMagick Binary irgendwie erst noch aktivieren musst, ...oder?
Ich habe die Manitu-Bedieneroberfläche abgesucht und nichts Dementsprechendes gefunden. Auch die FAQ und das Help-Wiki haben keine nützlichen Einträge zu ImageMagick. Ich kann da also so überhaupt gar nichts aktivieren oder einstellen. 😟
Beat Post author am |
Ich habe das File erstellt und auf den Manitu-Testblog hochgeladen. Bezüglich Pfad gab es da noch eine Unklarheit.
Ian Styx am |
Danke. Ich glaube das script wird uns mehr helfen, aber ich muss die files Morgen mal zerflücken. Es sind 145 b nicht kb. Ich habe dir zum Pfad noch was geschrieben.
Beat Post author am |
Falls ich konkret etwas tun sollte, dann brauche ich klarere Anweisungen. Kein "entweder-oder".
Ian Styx am |
Dann bitte das Entweder 😁
Beat Post author am |
Ich habe das jetzt gemacht. Wenn ich das File aufrufe, erhalte ich einen 500er Error. Im Logfile wird Folgendes angemäkelt: unexpected variable "$outputDir" 🤔 Da scheint das sys_get_temp_dir(); nicht zielführend.
Ian Styx am |
Ist wohl abgestellt - also neuer Vorschlag.
Beat Post author am |
Leider ohne Erfolg. Ich habe mit dem outoutDir noch etwas rumgespielt, doch der PHP-error in line 18 bleibt sich immer gleich.
Ian Styx am |
ich habe das script noch ein wenig angepasst.
Beat Post author am |
Leider wieder der gleiche Fehler im php-error-log. 😭
Und ja, ich habe das File neu heruntergeladen und den output-Pfad vor dem Hochladen wie beschrieben angepasst.
Ian Styx am |
zeigst du mir - hinter den Gardinen - mal den genauen error und was du selbst wie geändert hast?
Beat Post author am |
Wirf mal einen Blick hinter den Vorhang 🤓
Ian Styx am |
ping🚨
Beat Post author am |
Jetzt funktioniert das Test-Script.
Von wegen: Manitu unterstützt avif in Imagick... 🙄
PS: Ich sehe bei mir in Notpad++ überhaupt keine mysteriösen Sonder- oder Leerzeichen. (ja, ich habe Ansicht-Smbole-alle anzeigen eingeschaltet. Ausser ein LF am Ende jeder Zeile sehe ich da gar nichts). Ich habe jetzt in Zeile 17 + 18 zwischen dem ; und dem // einfach jegliche Leerzeichen entfernt.
Beat Post author am |
avif-Test-Script
Lass uns für eine bessere Lesbarkeit hier weitermachen. Der aktuelle Stand ist, dass das Test-Script nun funktioniert.
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.