Kommentare von

beats TEST blog

Styx für Bike Butler Homepage 2023

Beat Post author am |

Meine Interpretation ist, dass das Plugin diese Tabellen installiert hat und es danach nocheinmal versuchte. Anders kann ich mir das auch nicht erklären. Es ist eine völlige Neuinstallation.

Was ich noch erwähnen sollte. Nach der Installation stellte ich fest, dass ich (irrtümlich) die aktuelle Entwicklungsumgebung (styx-master) installierte und nicht die V3.9.1 stable Version. Vielleicht brachte das den Fehler?

Ian Styx am |

Nö, sollte gehen 😀

Dann kannst du mir auch gleich sagen ob das mit dem (neuer User) Passwort Vorschlag gut ist...

Ich habe mir das Plugin also installiert und erstmal so keine Fehlermeldungen erhalten, Erst nach einigem hin und her stellte sich dieser ein. Es liegt daran, dass zum Zeitpunkt der Installation und für kurze Zeit später noch kein echter Visitor eingetragen war, auf diesen aber gecheckt wird, ob es eine Neuinstallation ist oder nicht.

Ich habe das in 3.7.0 korrigiert.

Bevor du updatest kannst du also mal ins Frontend hopsen und (vielleicht sogar mit einem anderen Browser) einen echten Besucher generieren. Dann kannst du das Plugin wieder aktivieren bzw umbenennen und die Exception sollte weg sein.

Hattest du meine Fragen zum vorherigen Eintrag gelesen und kannst mir dazu etwas sagen?

Beat Post author am |

Dann kannst du mir auch gleich sagen ob das mit dem (neuer User) Passwort Vorschlag gut ist...

Kann ich leider nicht. Ist mir nicht aufgefallen. Habe Username und Passwort vorher in meinem Hosting-Excel definiert und von da übertragen.

Bevor du updatest kannst du also mal ins Frontend hopsen und (vielleicht sogar mit einem anderen Browser) einen echten Besucher generieren. Dann kannst du das Plugin wieder aktivieren bzw umbenennen und die Exception sollte weg sein.

Damit ich (mit einem anderen Browser) die Seite also besuchen kann, muss ich das Plugin umbenennen. Habe dann mit Chrome und Edge die Seite besucht, doch die visitors_count-Tabelle blieb leer. Sobald ich das Plugin wieder original benenne, erhalte ich erneut den Fatal error.

Habe nun die visitors_*-Tabellen und in der plugin-Tabelle den Statistic-Eintrag gelöscht. (Das Plugin vorerst aber nicht noch einmal installiert).

Hattest du meine Fragen zum vorherigen Eintrag gelesen und kannst mir dazu etwas sagen?

Ja, ich habe die Fragen gelesen, teilweise verstanden, konnte mich jedoch nie soweit motivieren, dass ich die vorgeschlagene Prozedur durchgeführt hätte. Mittlerweile hat die PHP-Version wieder geändert und ist nun bei V 8.0.24

Ian Styx am |

Beim deinstallieren werden auch die Tabellen gelöscht. Es ging auch um die visitors Tabelle.

Gib dir nen Ruck... 😉

Ian Styx am |

Sobald ich das Plugin wieder original benenne, erhalte ich erneut den Fatal error.

Das liegt aber nur daran dass du noch auf der Originalseite (die den Fehler aufrief) warst. Ein neu request auf die admin Startseite oder serendipity_admin.php?serendipity[adminModule]=plugins sollte aber gehen, ebenso wie anderes.

Styx 3.9.1 und PHP 8.0.21

Ian Styx am |

Guten Morgen

hmmm... das sollte (eigentlich) nicht sein!

Schau mal in deine Konfiguration - Datenbankeinstellungen - letzte Option

Datenbank-Zeichensatzkonvertierung aktivieren: default (Ja)

Für das "Problem" ist es eigentlich egal was du dort eingestellt hast. Es sollte aber mit dem Absenden des Formulares ein dbNames Eintrag in deiner config Datenbanktabelle unter name stehen, entweder mit dem value false oder true. Checke mal mit phpmyadmin ob der überhaupt da ist.

Ich vermute dass aus irgendwelchen (vielleicht historischen) Gründen kein Eintrag vorhanden ist.

Stelle also mal auf false (Nein) in der Konfiguration und sende ab. Unmittelbar danach rufst du die Konfiguration noch einmal komplett neu auf und stellst die Option auf Ja (mit absenden natürlich). Danach kontrolliere erneut mit phpmyadmin.

Ergebnis?

Ian Styx am |

Hast du das inzwischen mal gegengecheckt mit phpmyadmin, so dass du - folgend - das erzwingen über die Konfiguration ausprobieren kannst?

Ich hätte sonst noch was in der Pipe, aber das wäre eigentlich sinnlos, würde sich herausstellen, dass dies einigermaßen sicher nur auf deinem speziellen Setup bzw Migrationssetup beruht.

Styx 3.8.2 und PHP 8.0.16

Beat Post author am |

Nach dem Upgrade auf V3.9.0 kann ich hier keine neuen Beiträge erstellen. Ich erhalte 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/plugin_api.inc.php(1568): serendipity_set_config_var('serendipity_eve...', '\n\n <script t...') #4 /plugins/serendipity_event_emoticonchooser/serendipity_event_emoticonchooser.php(393): serendipity_plugin->set_config('serendipity_eve...', '\n\n <script t...') #5 /include/plugin_api.inc.php(1142): serendipity_event_emoticonchooser->event_hook('backend_entry_t...', Object(serendipity_property_bag), Array, NULL) #6 /include/functions_smarty.inc.php(646): serendipity_plugin_api::hook_event('backend_entry_t...', Array, NULL) #7 /templates_c/styx/14/c5/f4/14c5f4199105965b35b59ff15bcdb899b143ddde_1.file.entries.tpl.php(113): serendipity_smarty_hookPlugin(Array, Object(Smarty_Internal_Template)) #8 /bundled-libs/Smarty/libs/sysplugins/smarty_template_resource_base.php(123): content_62e3ae95f20334_01856437(Object(Smarty_Internal_Template)) #9 /bundled-libs/Smarty/libs/sysplugins/smarty_template_compiled.php(114): Smarty_Template_Resource_Base->getRenderedTemplateCode(Object(Smarty_Internal_Template)) #10 /bundled-libs/Smarty/libs/sysplugins/smarty_internal_template.php(217): Smarty_Template_Compiled->render(Object(Smarty_Internal_Template)) #11 /bundled-libs/Smarty/libs/sysplugins/smarty_internal_templatebase.php(232): Smarty_Internal_Template->render(false, 0) #12 /bundled-libs/Smarty/libs/sysplugins/smarty_internal_templatebase.php(116): Smarty_Internal_TemplateBase->_execute(Object(Smarty_Internal_Template), NULL, NULL, NULL, 0) #13 /include/functions_smarty.inc.php(1353): Smarty_Internal_TemplateBase->fetch('file:/var/www/v...') #14 /include/functions_entries_admin.inc.php(175): serendipity_smarty_showTemplate('/var/www/vhosts...') #15 /include/admin/entries.inc.php(551): serendipity_printEntryForm('?', Array, Array) #16 /serendipity_admin.php(208): include('/var/www/vhosts...') #17 {main} thrown in /include/db/mysqli.inc.php on line 76

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

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.

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:

  • 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

 

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

(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.

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:

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"...

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.

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. 😉

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.


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