Kommentare von

beats TEST blog

Weblog Kommentare

Styx 5.0.2 und PHP 8.3.27

Beat Post author am |

Ich kann keine neuen Blog-Kategorien mehr erstellen. Ich erhalte nach dem Abschicken des Formulars folgende Fehlermeldung:

Anscheinend gibt es ein Problem mit dieser Website

https://www.styx.beatsblog.ch/serendipity_admin.php?serendipity[adminModule]=category&serendipity[adminAction]=newSub&serendipity[cid]=1 hat möglicherweise ein temporäres Problem oder ist umgezogen.

Fehlercode: 500 Internal Server Error

Das ist auf beiden Servern (hosttech & Manitu) identisch.

Das steht im PHP-Error-Log:

[26-Nov-2025 20:07:00 UTC] PHP Fatal error:  Uncaught mysqli_sql_exception: Column count doesn't match value count at row 1 in /test/include/db/mysqli.inc.php:89
Stack trace:
#0 /test/include/db/mysqli.inc.php(89): mysqli_query()
#1 /test/include/functions.inc.php(1718): serendipity_db_query()
#2 /test/include/admin/category.inc.php(58): serendipity_addCategory()
#3 /test/serendipity_admin.php(238): include('...')
#4 {main}  thrown in /test/include/db/mysqli.inc.php on line 89

Ian Styx am |

Uh neee, warum fällt sowas immer erst nach Veröffentlichung auf..... Grrrr... 🤬

Mach mal in der functions.inc in Zeile 1706 aus dem

    $query = "INSERT INTO {$serendipity['dbPrefix']}category
                    (category_name, category_description, authorid, category_icon, parentid, category_left, category_right)
                  VALUES

ein

    $query = "INSERT INTO {$serendipity['dbPrefix']}category
                    (category_name, category_description, authorid, category_icon, parentid, category_left, category_right, sort_order, hide_sub)
                  VALUES

mit dem addierten ", sort_order, hide_sub" Feldern.

Die Fehlermeldung besagt (in diesem Fall) dass mehr Values eingetragen werden sollen als vorher Felder bezeichnet werden.

Dieser Fehler ist schon seit Juli da und ist eine Regression eines Methusalem fixes. 

Ich werde das baldmöglichst nachliefern.

Danke

Beat Post author am |

Mit diesem Zusatz funktioniert es wieder wie gewünscht. Vielen Dank! 👍

Ian Styx am |

Ich brauche einmal schnelle Hilfe, Beat und habe dir was hinterlassen. Danke.

Beat Post author am |

Nein, funktioniert nicht. Ich erhalte danach beim Aufruf des Frontend: Fehlercode: 500 Internal Server Error. Ich habe es deshalb wieder zurückgeändert.

Ian Styx am |

Hast du nachgesehen was da im log steht?

Beat Post author am |

Nichts

Ian Styx am |

Im server error log?

Dann kann da auch kein 500er Error gewesen sein. Verstehen würde ich ihn auch nicht, denn die Zeile müsste wenn vielleicht auch nicht im Ergebnis richtig, so doch fehlerfrei sein.

habe noch eine url verlinkt

Beat Post author am |

Ich habe die gestrige Aktion heute noch einmal durchgeführt, mit dem selben Resultat. Das Frontend meldet einen Fatal Error, doch im log ist nichts zu finden.

Dann versuchte ich das Ganze in Liveblog (auf dem Manitu-Server). Das Resultat ist das Selbe: Fatal error. Im PHP-error-log finde ich folgende Meldung:

[01-Dec-2025 14:42:03 Europe/Berlin] PHP Parse error:  syntax error, unexpected token "&" in /plugins/serendipity_event_spamblock/serendipity_event_spamblock.php on line 918

Ich schaue mir jetzt im Backend die neue URL an. Vielleicht hast Du ja in der Zwischenzeit noch etwas geändert. Melde mich wieder.

Beat Post author am |

Jetzt ist das V2.9.4-File aktiv. (ohne Error im Frontend) 😉

Ian Styx am |

Ist ja merkwürdig... vielleicht hattest du da irgendeinen fehler hineingezaubert.

Aber wenn dieser Kommentar jetzt durchkommt klappt es wohl und ich danke vielmals!

🤩👌

Beat Post author am |

Ja, habe mittlerweile auch rausgefunden, was falsch lief. Beim kopieren der Code-Zeile wurde aus "&&" plötzlich "&&" und ich habe es nicht bemerkt. Sorry! 🙄

Ian Styx am |

das erklärt es...☺️

das blöde ist das mein fix für ein tatsächliches Problem sich jetzt möglichweise auf andere Plugins auswirkt die Captchas (bzw abgeschaltete) benutzen...

AVIF-Test

Ian Styx am |

Ja das ist sehr strange....

ImageMagick ist übrigens gar nicht mehr mein unbedingter Favorit seit PHP 8.2++ sehr gut mit allem umgehen kann in der eigenen GD library. 

Ich habe es hier mit diesem image probiert und habe dasselbe Ergebnis (es wird gar kein AVIF erzeugt) Mach mal ein paar tests mit anderen Bildern. Sollten die das gleiche zeigen gibt es wohl irgendwo Inkonsistenzen und du kannst AVIF wieder ausstellen. Das ich broken avifs erzeugen konnte ist mir nur in der Entwicklung dieses Features passiert, und da war es bei PHP auch noch in der Entwicklung, seitdem läuft es bei mir - überall wo verwendet - glatt... Hmmm. 🧐

Ian Styx am |

Es liegt auch nicht am Bild selbst. Ich habe es bei mir  heraufgeladen und dass Ergebnis ist 


    MIME-Typ: image/jpeg
    Originalbild: 2048x1536
    Vorschaubild: 400x300
     
    Dateigröße: 971,60 KB
    Vorschau-Dateigröße: 165,08 KB
    AVIF-Dateigröße: 582,19 KB
    AVIF-Vorschau-Dateigröße: 36,82 KB
    WebP-Dateigröße: 740,64 KB
    WebP-Vorschau-Dateigröße: 40,79 KB
     
    Pfad: ""
    Datum: 19.11.2025 16:39

Beat Post author am |

Mach mal ein paar tests mit anderen Bildern. Sollten die das gleiche zeigen gibt es wohl irgendwo Inkonsistenzen und du kannst AVIF wieder ausstellen.

Habe auf styx.beatsblog.ch (Manitu) noch drei neue Bilder hochgeladen. Das Ergebnis ist immer gleich. Es werden jeweils zwei .avif-Dateien geschrieben, diese sind jedoch immer nur 145 Bites gross.

Ich werde im LiveBlog die Avif-Konvertierung also wieder ausschalten.

Ian Styx am |

Bei mir waren in der frühen Phase immer ~25KB Avifs korrupt. Da schrieb die Avif Kodierung irgendetwas in den image header und brach ab, wahrscheinlich ein Fehlercode der auf ein fehlendes oder korruptes Begleitlibrary verwies, oder so. 
Ansonsten läuft AVIF auf verschiedenen Servern ganz wunderbar.

Was das bei dir ist kann ich nicht sagen, leider... Verwunderlich dass das auf zwei unterschiedlichen Servern "gleich" ist.

Beat Post author am |

Verwunderlich dass das auf zwei unterschiedlichen Servern "gleich" ist.

Das stimmt so nicht.

styx.beatsblog.ch und beatsblog.ch laufen beide auf dem Manitu-Server.

Hier, auf dem Hosttech-Server, werden überhaupt keine .avif geschrieben. Ich vermute dass es daran liegt, dass ich hier ImageMagick nie richtig zum laufen gekriegt habe und das deshalb ausgeschalten ist. (Denn auf dem Manitu-Server kriege ich ja einen FatalError beim Neugenerieren der Bild-Varianten, wenn ich ImageMagick ausschalte). Es könnte aber auch sein, dass PHP 8.3.27 avif noch gar nicht unzterstützt.

Ian Styx am |

Ich meinte im Ergebnis... das man avif nicht nutzen kann.

Nee. PHP 8 unterstützt avif seit PHP 8.1 (eigentlich) aber erst richtig seit PHP 8.2, denn vorher fehlte eine wichtige Komponente beim Zusammenbau.

Hast du mal geschaut was der Fatal error im error log denn dazu sagt?

Ich vermute einfach dass das mal wieder ein Fall ist wo die GD bzw eine Library irgendwie unabhängig von einem PHP release vom Server Betreiber gebildet wurde um irgendwelche Backward Kompatibilitäten zu erfüllen. Oder so.... Ich kenne das von SSL.

Ian Styx am |

Der beschriebene error 

...Call to undefined function imageavif()...

in deinem Styx beatsblog test blog beschreibt es ziemlich genau. Eigentlich ist es so dass GD mit PHP als default compiled wird. Dies scheint bei dir entweder alt, oder disabled oder gar nicht vorhanden zu sein, denn imageavif() ist eine PHP GD function. Das sind äußerst merkwürdige Providereinstellungen ... (wie schon gesagt). Ich verstehe den Sinn nicht daran herumzumurksen....

Beat Post author am |

Ich habe das jetzt mit Styx 5.0.2 noch einmal probiert, doch das Ergebnis ist das Gleiche wie zuvor.

Hier (hosttech) wird gar nie ein AVIF-File erzeugt. Weder mit, noch ohne ImageMagick.

Auf dem Manitu-Server wird mit ImageMagick ein korruptes 145 Bytes grosses AVIF erzeugt. Ohne ImageMagick stürzt das Backend ab und zeigt den FatalError.

Ich werde wohl bei webp bleiben.

Ian Styx am |

Tja! Äußerst schade, denn du mit deinen regelmäßigen bebilderten Einträgen wärst ein idealer Kandidat zur Beobachtung.

Und zu fragen warum AVIF nicht erlaubt (

--with-avif
) oder die GD nicht (oder unvollständig) inkludiert ist wäre zuviel? Vielleicht wissen die es gar nicht? Wie gesagt seit PHP 8.1 Standard und seit PHP 8.2 vollständig nutzbar über GD. ImageMagick liegt ein wenig anders. IM 7+ sollte funktionieren. Bei den alten 6er versionen bin ich gerade nicht sicher.

Ian Styx am |

https://www.manitu.de/webhosting/phpinfo/

Manitu hat kein AVIF in GD dafür aber IM 7.1,+ aber nur als Imagick Modul welches wiederum Serendipity nicht nutzen kann.
IMagick als Modul war und ist über lange Zeit nur schwierig nutzbar gewesen weshalb viele darauf verzichteten.
Das ist natürlich super wenn es da ist, aber ist definitiv blöd wenn man dann auf GD mit AVIF als fallback verzichtet.
Für Imagick müsste man die gesamten Image Funktionen komplett umschreiben.
Dies war einer der Gründe warum Serendipity von jeher IM nur als Binary verwendete. Es war überall viel einfacher nachzuinstallieren. Und ich nehme an wenn IMagick als Modul vorhanden, wird es auch kein zusätzliches Binary geben. (oder?)
Du könntest also nachfragen ob sie nicht trotzdem das AVIF in GD erlauben könnten.

(Für hostech kann ich nichts sagen)

Ian Styx am |

Du könntest also nachfragen ob sie nicht trotzdem das AVIF in GD erlauben könnten.

Hast du das mal gemacht? Es müsste also nur mit --with-avif compiliert werden und wäre als library die default fallback image library mit allen nötigen image Funktionen die höhere PHP 8 Versionen seit PHP 8.2 bereitstellen. Oder muss Manitu irgendwas davor berücksichtigen?