Interssanterweise ist das nur hier so. www.beatsblog.ch habe ich ebenfalls auf V3.9.0 upgegradet und dort kann ich ohne Fehlermeldung neue Beiträge erstellen.
Ja das ist ein verzwicktes Ding. Ich habe tatsächlich an der
serendipity_set_config_var
Funtion geschraubt und vermeindlich die besseren (und korrekteren) Werte gesetzt. Allerdings ist es ja so, dass du selber sagst es würde auf dem LIVE Blog nicht auftreten. Ich kann es hier bei mir local mit PHP 8.2 auch nicht nachstellen.
Was genau unterscheidet deine Einstellungen und Platz des emoticonchooser Plugins von hier?
Meine Vermutung ist aber, dass es sich entweder um ein merkwürdiges Cache Problem des NGinx Proxys handelt (und sich damit möglicherweise bald in Luft auflöst) oder vermutlich eher eine Frage der PHP Version ist. Seit PHP 8 schrauben die Entwickler an den Typen herum, also int, string, array etc. PHP 8.0, 8.1, und 8.2 unterscheiden sich da in der Strenge bzw Genauigkeit. Grundsätzlich wird es strenger und genauer und damit tendenziell besser und sicherer, aber es können auch versionsabhängige Fehler unter bestimmten Vorraussetzungen auftreten.
Welche PHP Version fährt der LIVE Blog?
Als dritte Variante kann es sein, dass die
Incorrect integer value: '' for column `styx3`.`styx_config`.`authorid`
Fehlermeldung auf das vorherige value zurückzuführen ist. Dies ist in dem Fall ein javascript snippet des emoticonchooser Plugins und stellt eine Besonderheit unter den value strings dar, da es single quotes und double quotes beinhaltet und möglicherweise beim INSERT den darauf folgenden authorid Parameter in irgendeiner fehlerhaften Weise beeinflusst.
Um das weiter auszutesten muss ich aber erst die vorherigen Fragen beantwortet haben.
Möglichweise wird dann die Lösung des Problems in einem temporären workaround für dich, oder in einem Styx Bugfix und Point Update bestehen das unterschiedliche PHP Versionen berücksichtigen muss... mal sehen.
Auf alle Fälle lässt sich das Problem kurzfristig umgehen in dem man das emoticonchooser Plugin temporär deaktiviert.
Mist. Letzteres stimmt nur bedingt, denn das Problem tritt auch an anderer Stelle auf. Und erhärtet damit die PHP (Versions) Vermutung!
Frage(n): Lässt sich im LIVE Blog die Mediathek aufrufen? Und, kann man die Konfiguration fehlerfrei abspeichern?
Ach, eine weitere Frage hätte ich noch... Wurden beide Systeme mit dem autoupdate Plugin geladen und ausgeführt, oder hast du eventuell hier mit FTP gearbeitet?
Beat Post author am |
Also:
emoticonchooser steht in beiden Installationen an 6. Stelle und ist beides Mal V3.32
PHP ist bei beiden Installationen V8.0.20
D.h. Links wie rechts ist beides gleich... (was Dir nun so gar nicht weiter hilft).
Ja, auf www.beatsblog.ch kann ich die Mediathek aufrufen und sie wird korrekt angezeigt. Wenn ich das hier mache, kriege ich auch eine Error-Page (am Schluss: /include/db/mysqli.inc.php on line 76).
Und ja: Beide Upgrades wurden mit autoupdate durchgeführt und bei beiden waren alle Plugins aktuell.
Beat Post author am |
Nachtrag: Wenn ich emoticonchooser deaktiviere, kann ich einen neuen Beitrag schreiben. Rufe ich hingegen die Mediathek auf, erhalte ich immer noch folgende Fehlermeldung:
Fatal error: Uncaught mysqli_sql_exception: Incorrect integer value: '' for column `styx3`.`styx_config`.`authorid` at row 1 in /include/db/mysqli.inc.php:76 Stack trace: #0 /include/db/mysqli.inc.php(76): mysqli_query(Object(mysqli), 'INSERT INTO sty...') #1 /include/db/db.inc.php(78): serendipity_db_query('INSERT INTO sty...') #2 /include/functions_config.inc.php(115): serendipity_db_insert('config', Array) #3 /include/functions_images.inc.php(3241): serendipity_set_config_var('last_image_hash', '31dba9972dcfab3...', 0) #4 /include/functions_images.inc.php(6430): serendipity_displayImageList(1, true, NULL, false, NULL, Array) #5 /include/admin/images.inc.php(1042): showMediaLibrary() #6 /serendipity_admin.php(144): include('/var/www/vhosts...') #7 {main} thrown in /include/db/mysqli.inc.php on line 76
In der Tat! Das ist extrem erstaunlich. Ich hätte jetzt damit gerechnet dass du dort schon PHP 8.1 hättest. Denn das zwei exakt gleiche Versionen so unterschiedlich reagieren ist irgendwie wie ein Fehler in der Matrix.
Ich habe den Fehler inzwischen auch unter PHP 7 nachstellen können. Und der eigentliche Fix ist recht einfach.
Suche mal in der include/functions_config.inc.php nach
(int)$authorid));
ca Zeile 115 und ändere es mal in
(string)$authorid));
Ich muss also doch noch einmal verschiedene PHP Versionen auf ihr diesbezügliches Verhalten (Typisierung einer Variable über ein Array mit anschließendem DB INSERT unter Nutzung von MYSQLI_REPORT_* flags) untersuchen, damit solch ein Mißgeschick nicht noch einmal passiert.
Kannst du anschließend den fehlerfreien Betrieb damit bestätigen haue ich alsbald ein Update heraus.
EDIT: Bitte nicht wundern dass der Fehler jetzt auch beim Login auftritt, Er wird halt immer dann angezeigt, wenn eine Konfigurationsvariable neu geschrieben werden muss (in dem Fall die last update check Variable). Das Login funktioniert trotzdem, aber man muss dann von der Fehlerseite schnell mal woanders hin (im Backend) navigieren.
Beat Post author am |
Habe die Änderung in der include/functions_config.inc.php nun nachgeführt und kann bestätigen, dass ich nun keine Fehler mehr finde. Habe aber auch nicht lange getestet. Neuer Eintrag schreiben und Mediathek funktionieren wieder.
Wünsche einen schönen Sonntag!
Ian Styx am |
Jo... sieht gut aus. Herzlichen Dank. 🙏
Tut mir leid für die kleinen Unannehmlichkeiten mit dem Update.
Mich würde ja noch interessieren ob du es irgendwie herausbekommst was an den beiden 8.0.x Versionen so verschieden ist auf den beiden Servern. Vielleicht Fcgid vs apache2handler (als Modul) ? oder ähnliches. Hast du darüber keine Informationen vom Provider wäre ein Blick auf eine phpinfo Datei Ausgabe lohnenswert, aber so, dass nur du und ich sie mal einsehen können bevor du sie wieder löscht. Zb. in einem Order mit Auth Zugriffsschutz über htaccess und htpassw oder Ähnliches.
Beat Post author am |
Ich muss das hier noch einmal ausgraben, weil der nahezu gleiche Fehler wieder auftritt. Diesmal wollte ich eine neue Kategorie "Unsichtbar" erstellen. Beim speichern erhielt ich folgende Fehlermeldung:
Fatal error: Uncaught mysqli_sql_exception: Incorrect integer value: '' for column `styx3`.`styx_categorytemplates`.`futureentries` at row 1 in /include/db/mysqli.inc.php:76 Stack trace: #0 /include/db/mysqli.inc.php(76): mysqli_query(Object(mysqli), 'INSERT INTO sty...') #1 /include/db/db.inc.php(78): serendipity_db_query('INSERT INTO sty...') #2 /plugins/serendipity_event_categorytemplates/serendipity_event_categorytemplates.php(436): serendipity_db_insert('categorytemplat...', Array, 'execute') #3 /plugins/serendipity_event_categorytemplates/serendipity_event_categorytemplates.php(800): serendipity_event_categorytemplates->setProps(24, Array) #4 /include/plugin_api.inc.php(1143): serendipity_event_categorytemplates->event_hook('backend_categor...', Object(serendipity_property_bag), 24, NULL) #5 /include/functions.inc.php(1571): serendipity_plugin_api::hook_event('backend_categor...', 24) #6 /include/admin/category.inc.php(53): serendipity_addCategory('Unsichtbar', 'keine Anzeige i...', 0, '', '0') #7 /serendipity_admin.php(224): include('/var/www/vhosts...') #8 {main} thrown in /include/db/mysqli.inc.php on line 76
Aktuell: Styx 4.0.1 und PHP 8.0.27
Nicht lange grübeln. Das ist ein Problem, welches nur hier auftritt. Auf https://www.styx.dokumenzi.ch/ (Hosttech) und https://www.beatsblog.ch/ (Manitu) funktioniert es ohne Fehlermeldung. Bei dieser Installation ist irgendwie der Wurm drin. Und immer auf dieser "line 76"...
Diese "ominöse" Zeile 76 ist übrigens nur der Endpunkt an dem der Stack trace ausgegeben wird wenn es ein SQL error ist, nicht der eigentliche Verursacher.
Hast du hier vielleicht den production mode in der config local verändert oder allgemein auf dem Server ein strengeres Error reporting eingestellt? Ich bin ganz froh drüber... 😁
Beat Post author am |
Der Plugin-Update hat leider nicht gewirkt.
Fatal error: Uncaught mysqli_sql_exception: Incorrect integer value: '' for column `styx3`.`styx_categorytemplates`.`futureentries` at row 1 in /include/db/mysqli.inc.php:76 Stack trace: #0 /include/db/mysqli.inc.php(76): mysqli_query(Object(mysqli), 'INSERT INTO sty...') #1 /include/db/db.inc.php(78): serendipity_db_query('INSERT INTO sty...') #2 /plugins/serendipity_event_categorytemplates/serendipity_event_categorytemplates.php(436): serendipity_db_insert('categorytemplat...', Array, 'execute') #3 /plugins/serendipity_event_categorytemplates/serendipity_event_categorytemplates.php(800): serendipity_event_categorytemplates->setProps('24', Array) #4 /include/plugin_api.inc.php(1143): serendipity_event_categorytemplates->event_hook('backend_categor...', Object(serendipity_property_bag), '24', NULL) #5 /include/functions.inc.php(1611): serendipity_plugin_api::hook_event('backend_categor...', '24') #6 /include/admin/category.inc.php(74): serendipity_updateCategory('24', 'Unsichtbar', 'keine Anzeige i...', 0, '', '0', 'timestamp DESC', '1', '') #7 /serendipity_admin.php(224): include('/var/www/vhosts...') #8 {main} thrown in /include/db/mysqli.inc.php on line 76
Hast du hier vielleicht den production mode in der config local verändert oder allgemein auf dem Server ein strengeres Error reporting eingestellt?
Nicht dass ich wüsste. 🤔
Ich bin ganz froh drüber... 😁
Dann brauche ich mir immerhin nicht so ein schlechtes Gewissen zu machen. 😉
Gnrrrr!
Solange der error und stack immer derselbe ist brauchst du das nicht wiederholt zu posten. Hinweis genügt.
Was genau machst du da, damit das passiert?
Letztendlich kann es sogar sein, dass die/deine Tabellenstruktur falsch ist.
Aber erstmal muss ich klären WIE es dazu kommt.
Ich wähle im Backend unter Kategorien irgendeine Kategorie an (editieren) und drücke auf speichern. Dann folgt diese Fehlermeldung.
PS: Ich würde da echt keine Zeit mehr investieren. Wie oben schon geschrieben, funktioniert das auf allen anderen Styx-Installationen ohne Probleme. Egal ob Hosttech oder Manitu. Ich glaube wirklich, dass bei dieser Instanz etwas faul ist und es nicht am Styx-Code liegt.
Aber das ist doch zum verrücktwerden.... Ja schon... aber soetwas faules mit so einer spezifischen Errormeldung ist trotzdem extrem merkwürdig.
Bearbeite "Unsichtbar" und stelle bitte mal die "Zukünftige Einträge zeigen" Radio Option von Standard auf Nein oder Ja. Dann ist der Error weg. Wenn du wieder auf default gehst ist er wieder da.
Beat Post author am |
Nach dem Upgrade auf V3.9.0 kann ich hier keine neuen Beiträge erstellen. Ich erhalte folgende Fehlermeldung:
Interssanterweise ist das nur hier so. www.beatsblog.ch habe ich ebenfalls auf V3.9.0 upgegradet und dort kann ich ohne Fehlermeldung neue Beiträge erstellen.
Ian Styx am |
Moin Beat
Merkwürdig.... Das ist ja mal ein stack trace über 17 Stationen... Whow!
Moment....
Ian Styx am |
Ja das ist ein verzwicktes Ding. Ich habe tatsächlich an der
Funtion geschraubt und vermeindlich die besseren (und korrekteren) Werte gesetzt. Allerdings ist es ja so, dass du selber sagst es würde auf dem LIVE Blog nicht auftreten. Ich kann es hier bei mir local mit PHP 8.2 auch nicht nachstellen.
Was genau unterscheidet deine Einstellungen und Platz des emoticonchooser Plugins von hier?
Meine Vermutung ist aber, dass es sich entweder um ein merkwürdiges Cache Problem des NGinx Proxys handelt (und sich damit möglicherweise bald in Luft auflöst) oder vermutlich eher eine Frage der PHP Version ist. Seit PHP 8 schrauben die Entwickler an den Typen herum, also int, string, array etc. PHP 8.0, 8.1, und 8.2 unterscheiden sich da in der Strenge bzw Genauigkeit. Grundsätzlich wird es strenger und genauer und damit tendenziell besser und sicherer, aber es können auch versionsabhängige Fehler unter bestimmten Vorraussetzungen auftreten.
Welche PHP Version fährt der LIVE Blog?
Als dritte Variante kann es sein, dass die
Fehlermeldung auf das vorherige value zurückzuführen ist. Dies ist in dem Fall ein javascript snippet des emoticonchooser Plugins und stellt eine Besonderheit unter den value strings dar, da es single quotes und double quotes beinhaltet und möglicherweise beim INSERT den darauf folgenden authorid Parameter in irgendeiner fehlerhaften Weise beeinflusst.
Um das weiter auszutesten muss ich aber erst die vorherigen Fragen beantwortet haben.
Möglichweise wird dann die Lösung des Problems in einem temporären workaround für dich, oder in einem Styx Bugfix und Point Update bestehen das unterschiedliche PHP Versionen berücksichtigen muss... mal sehen.
Auf alle Fälle lässt sich das Problem kurzfristig umgehen in dem man das emoticonchooser Plugin temporär deaktiviert.
Ian Styx am |
Mist. Letzteres stimmt nur bedingt, denn das Problem tritt auch an anderer Stelle auf. Und erhärtet damit die PHP (Versions) Vermutung!
Frage(n): Lässt sich im LIVE Blog die Mediathek aufrufen? Und, kann man die Konfiguration fehlerfrei abspeichern?
Ach, eine weitere Frage hätte ich noch... Wurden beide Systeme mit dem autoupdate Plugin geladen und ausgeführt, oder hast du eventuell hier mit FTP gearbeitet?
Beat Post author am |
Also:
D.h. Links wie rechts ist beides gleich... (was Dir nun so gar nicht weiter hilft).
Ja, auf www.beatsblog.ch kann ich die Mediathek aufrufen und sie wird korrekt angezeigt. Wenn ich das hier mache, kriege ich auch eine Error-Page (am Schluss: /include/db/mysqli.inc.php on line 76).
Und ja: Beide Upgrades wurden mit autoupdate durchgeführt und bei beiden waren alle Plugins aktuell.
Beat Post author am |
Nachtrag: Wenn ich emoticonchooser deaktiviere, kann ich einen neuen Beitrag schreiben. Rufe ich hingegen die Mediathek auf, erhalte ich immer noch folgende Fehlermeldung:
Ian Styx am |
In der Tat! Das ist extrem erstaunlich. Ich hätte jetzt damit gerechnet dass du dort schon PHP 8.1 hättest. Denn das zwei exakt gleiche Versionen so unterschiedlich reagieren ist irgendwie wie ein Fehler in der Matrix.
Ich habe den Fehler inzwischen auch unter PHP 7 nachstellen können. Und der eigentliche Fix ist recht einfach.
Suche mal in der include/functions_config.inc.php nach
ca Zeile 115 und ändere es mal in
Ich muss also doch noch einmal verschiedene PHP Versionen auf ihr diesbezügliches Verhalten (Typisierung einer Variable über ein Array mit anschließendem DB INSERT unter Nutzung von MYSQLI_REPORT_* flags) untersuchen, damit solch ein Mißgeschick nicht noch einmal passiert.
Kannst du anschließend den fehlerfreien Betrieb damit bestätigen haue ich alsbald ein Update heraus.
EDIT: Bitte nicht wundern dass der Fehler jetzt auch beim Login auftritt, Er wird halt immer dann angezeigt, wenn eine Konfigurationsvariable neu geschrieben werden muss (in dem Fall die last update check Variable). Das Login funktioniert trotzdem, aber man muss dann von der Fehlerseite schnell mal woanders hin (im Backend) navigieren.
Beat Post author am |
Habe die Änderung in der include/functions_config.inc.php nun nachgeführt und kann bestätigen, dass ich nun keine Fehler mehr finde. Habe aber auch nicht lange getestet. Neuer Eintrag schreiben und Mediathek funktionieren wieder.
Wünsche einen schönen Sonntag!
Ian Styx am |
Jo... sieht gut aus. Herzlichen Dank. 🙏
Tut mir leid für die kleinen Unannehmlichkeiten mit dem Update.
Und ebenfalls schönen Sonntag noch! 😎
Ian Styx am |
Mich würde ja noch interessieren ob du es irgendwie herausbekommst was an den beiden 8.0.x Versionen so verschieden ist auf den beiden Servern. Vielleicht Fcgid vs apache2handler (als Modul) ? oder ähnliches. Hast du darüber keine Informationen vom Provider wäre ein Blick auf eine phpinfo Datei Ausgabe lohnenswert, aber so, dass nur du und ich sie mal einsehen können bevor du sie wieder löscht. Zb. in einem Order mit Auth Zugriffsschutz über htaccess und htpassw oder Ähnliches.
Beat Post author am |
Ich muss das hier noch einmal ausgraben, weil der nahezu gleiche Fehler wieder auftritt. Diesmal wollte ich eine neue Kategorie "Unsichtbar" erstellen. Beim speichern erhielt ich folgende Fehlermeldung:
Aktuell: Styx 4.0.1 und PHP 8.0.27
Nicht lange grübeln. Das ist ein Problem, welches nur hier auftritt. Auf https://www.styx.dokumenzi.ch/ (Hosttech) und https://www.beatsblog.ch/ (Manitu) funktioniert es ohne Fehlermeldung. Bei dieser Installation ist irgendwie der Wurm drin. Und immer auf dieser "line 76"...
Ian Styx am |
Plugin update commited!
Versuchs mal damit.
Diese "ominöse" Zeile 76 ist übrigens nur der Endpunkt an dem der Stack trace ausgegeben wird wenn es ein SQL error ist, nicht der eigentliche Verursacher.
Hast du hier vielleicht den production mode in der config local verändert oder allgemein auf dem Server ein strengeres Error reporting eingestellt? Ich bin ganz froh drüber... 😁
Beat Post author am |
Der Plugin-Update hat leider nicht gewirkt.
Nicht dass ich wüsste. 🤔
Dann brauche ich mir immerhin nicht so ein schlechtes Gewissen zu machen. 😉
Ian Styx am |
Wer lesen kann ist stark im Vorteil... 😉
Erneuter Versuch (Bitte!)
Beat Post author am |
Non capisco. 🙄
Ich kann nicht an einem Tag ein Plugin 2x updaten. Oder habe ich etwas grundsätzlich falsch verstanden?
Ian Styx am |
Spartacus Plugin einmal submitten löscht die XML files und damit ist die Röhre wieder frei.
Möönsch Beat das hatten wir doch schon öfter... :g 🙄
Beat Post author am |
Leider wird es auch mit Plugin Version 2.3.3 nicht besser.
Ian Styx am |
Saperlot! 🤪
Ich kann diesen "Fehler" bei mir auch überhaupt nicht provozieren....
So dass ich im Dunklen grabe ... und das hoffentlich auch an der richtigen Stelle. Again.
Irgendwie ist dein Server total empfindlich und ich schätze das auch, denn wir finden so Dinge die sonst immer untergehen würden.
Beat Post author am |
Leider Nein.
Bis morgen...
Ian Styx am |
Gnrrrr!
Solange der error und stack immer derselbe ist brauchst du das nicht wiederholt zu posten. Hinweis genügt.
Was genau machst du da, damit das passiert?
Letztendlich kann es sogar sein, dass die/deine Tabellenstruktur falsch ist.
Aber erstmal muss ich klären WIE es dazu kommt.
Ian Styx am |
Im categorytemplates Plugin gibt es in Zeile 795
Nimm bitte mal das (int) weg.
Beat Post author am |
Ich wähle im Backend unter Kategorien irgendeine Kategorie an (editieren) und drücke auf speichern. Dann folgt diese Fehlermeldung.
PS: Ich würde da echt keine Zeit mehr investieren. Wie oben schon geschrieben, funktioniert das auf allen anderen Styx-Installationen ohne Probleme. Egal ob Hosttech oder Manitu. Ich glaube wirklich, dass bei dieser Instanz etwas faul ist und es nicht am Styx-Code liegt.
Beat Post author am |
Der error bleibt.
Ian Styx am |
Aber das ist doch zum verrücktwerden.... Ja schon... aber soetwas faules mit so einer spezifischen Errormeldung ist trotzdem extrem merkwürdig.
Bearbeite "Unsichtbar" und stelle bitte mal die "Zukünftige Einträge zeigen" Radio Option von Standard auf Nein oder Ja. Dann ist der Error weg. Wenn du wieder auf default gehst ist er wieder da.
Im code steht
Sobald also gesendet wird, muss 0 für die folgende SQL query genommen werden. Ankommen laut Errormeldung
kommt aber ein integer value mit einem leeren String, so als ob die Null irgendwo unterwegs verloren geht...
Kontrolliert man ein Nein wird default angezeigt was eigentlich auch nicht richtig ist.