OH YEAH ... wie immer ist es nützlich es zu beschreiben....
Bitte teste 2.3.5.
3 auf einen Streich! 🦄🐘🐁 🐓😄
Beat Post author am |
Tja... Würde ja gerne schreiben, dass der Fehler nun weg ist, doch so ist es leider auch bei Plugin V2.3.5 nicht. Ich erhalte immer noch die gleiche Fehlermeldung (habe zuvor auch den Browsercache und die dokumenzi-Cookies gelöscht).
Ian Styx am |
Tja das wäre nett gewesen... und auch schön wenn es denn so einfach wäre ... doch die 3 auf einen Streich gelten trotzdem immer noch. 😀
Inzwischen hatte ich nochmal nachgelesen und auch gesehen, dass der error des vorgehenden issues (und Auslöser des Threads) ja tatsächlich auch ein genau solcher war - das eben ein Integer erwartet, aber ein leerer String geliefert wird. Ich kann bislang nicht erkennen wo dies geschieht. weil die Möglichkeiten immens sind. So habe ich nochmal nachgeschaut, und den "damaligen" Fix als gar nicht mehr als soooo richtig und ebenfalls ein wenig spooky empfunden.
Deshalb habe ich gerade den Verdacht, dass es sich vielleicht um ein 64bit System vs 32bit System Problem handeln könnte, was wiederum den Unterschied (und damaligen string fix) für PHP7/~8 vs PHP8+ erklären könnte, denn da gibt es Unterschiede das PHP möglicherweise einen String type zurückgibt wo ein Integer type erwartet wird.
Ich werde also wahrscheinlich diesbezüglich noch auf weitere Test von Dir zugreifen müssen, wenn du erlaubst.
Bis dahin könntest du mir einen Gefallen tun und mal mit PhpMyAdmin die config Tabelle überprüfen, ob im letzten Feld - also authorid - auch immer eine Zahl drinnen steht. Sie darf nicht leer sein. Mittels der Sortierung (auf Klick/s) kann man das sehr leicht nachprüfen. Bitte noch nichts verändern falls du fündig wirst. Ebenso bitte in der categorytemplates Tabelle im Feld futureentries, welches ebenfalls nicht leer sein darf und ansonsten nur 0,1, oder 2 enthalten darf.
Beat Post author am |
config-Tabelle, authorid ist immer mit 0 oder 1 gefüllt.
categorytemplates-Tabelle, futureentries ist immer mit 0 gefüllt.
In beiden Tabellen/Spalten also keine leeren Felder.
Ian Styx am |
👍🙏
Ab jetzt kann ich mich nur noch auf den mühseligen Weg machen, jede einzelne serendipity_db_insert Anweisung auf Variablen und zwar überall zu überprüfen, die nicht direkt (denn das habe ich schon zufriedenstellend gemacht) und dabei möglichweise falsch gesetzt sind, sondern eben all jene auf eventuell falsche init fallbacks in den dazugehörigen stack traces zu überprüfen, die womöglich für diesen speziellen Fall ein leeres String setzen.
ODER
ich mache es mir/uns einfach und korrigiere den vorherigen fix in der functions_config.inc zurück nach (int) und setzte 1 Zeile weiter rauf an den Anfang
if ($authorid == '') $authorid = 0;
Das müsste reichen 1. um das erste Issue zu erschlagen, 2. auch jenes in futurentries zu erschlagen und 3. die Möglichkeit der falschen Typ Zuweisung zwischen 64/32bit System zu beherrschen und 4. weiteren solchen Fällen vorzubeugen.
Magst du das mal ausprobieren? 😀
Ich habe das mit PHP 7 schon getestet (jedenfalls bezüglich des ersten Issues).
Ian Styx am |
Beat du arbeitest in categorytemplates!
Du sollst aber in functions_config.inc arbeiten (siehe ganz oben im thread)! 😀
Beat Post author am |
??? das (int) habe ich gestern aus der serendipity_event_categorytemplates.php entfernt. Dort stimmt auch die Zeilennummer 795. Dort habe ich jetzt das (int) wieder eingefügt.
Die functions_config.inc "sieht nun ab Zeile 114 wie folgt aus:
Die Errormeldung beim Abspeichern einer Kategorie kommt aber immer noch. 😪
Beat Post author am |
Noch schlimmer: mit diesen Änderungen der functions_config.inc kann ich das Backend gar nicht mehr erreichen. Habe deshalb wieder die Originaldatei der V4.0.1 im Einsatz.
In Anlehnung an James Dean: "Denn er weiss nicht, was er tut"... 😢
Ian Styx am |
Du hattest aber inzwischen auf 2.3.5 upgedated. Deshalb Finger weg! 😉
In der ..._config - sehe ich gerade - muss das doch noch weiter rauf. Sorry. Also vor die erste serendipity_db_.. Anweisung, ca Zeile 109.
Ian Styx am |
..kann ich das Backend gar nicht mehr erreichen.
Ist in deinem FTP Programm (FileZilla?) vielleicht die Üertragungsmethode falsch? Falls es das genannte ist, unter Bearbeiten - Einstellungen, dann Verbindung - FTP - Verbindungsmodus = passiv (Empfohlen) und unter Übertragungen - FTP:Dateitypen = Automatisch aktivieren.
Beat Post author am |
Arggh...
Crasht immer noch. Die functions_config.inc sieht nun ab Zeile 106 so aus:
function serendipity_set_config_var($name, $val, $authorid = 0) {
global $serendipity;
if ($authorid == '') $authorid = 0;
serendipity_db_query("DELETE FROM {$serendipity['dbPrefix']}config WHERE name='" . serendipity_db_escape_string($name) . "' AND authorid = " . (int)$authorid);
if ($name == 'password' || $name == 'check_password') {
return;
}
$r = serendipity_db_insert('config', array('name' => serendipity_db_escape_string($name), 'value' => $val, 'authorid' => (string)$authorid)); // Some PHP versions below PHP 8.2 (/PHP 8.1?) need definite declared string integers
if ($authorid === 0 || (isset($serendipity['authorid']) && $authorid === $serendipity['authorid'])) {
if ($val === 'false') {
$serendipity[$name] = false;
} else {
$serendipity[$name] = $val;
}
}
if (is_string($r)) {
# if $r is a string, it is the error-message from the insert
echo $r;
}
}
Beat Post author am |
Ja, FileZilla und genau so eingestellt (Standard).
Beat Post author am |
Was mich als Laie etwas irritiert ist, dass Du nun an der "authorid" herumschraubst, der erste Teil der Fehlermeldung bezieht sich jedoch auch jetzt immer noch auf "futureentries":
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
Ian Styx am |
Aber das
(string)$authorid));
hattest du hier nicht auf (int) zurückgestellt. Bitte noch nachholen.
Damit müsste zumindest das Abspeichern der Konfiguration ohne Fehler gehen. BZW bei dir war es ja das Abspeichern eines Eintrages, wenn emoticonchooser aktiv war (meine ich). Und bei mir zusätzlich auch noch der Aufruf der Mediathek.
Und die Relevanz liegt im
for column `styx3`.`styx_config`.`authorid`
Wahrscheinlich habe ich es auch einfach miteinander verbaselt und die categorytemmplates
Incorrect integer value: '' for column `styx3`.`styx_categorytemplates`.`futureentries`
Meldung bezieht sich tatsächlich nur auf etwas Ähnliches, denn dieses Feld ist strukturell auch als INT Feld definiert, und müsste vielleicht ebenso abgefangen werden.
Obwohl ich mich dunkel erinnere es schon einmal so probiert zu haben... aber das war vor den andren Fixes.
Beat Post author am |
Aber das
(string)$authorid));
hattest du hier nicht auf (int) zurückgestellt. Bitte noch nachholen.
Habe ich auch bemerkt und in der Zwischenzeit geändert. Hat leider auch nichts gebracht.
Beat Post author am |
Warte besser mal mit weiteren Arbeiten zu diesem Thema.
Ich bin immer noch sehr irritiert, dass es hier https://www.styx.dokumenzi.ch/ problemlos funktioniert. Hey: Das ist auf dem gleichen Server! Auch sonst treten diese Fehler bei keiner anderen Installation auf! Es ist zum 🤮!
Ich werde morgen Nachmittag die offizielle Styx V 4.01 runterladen und darüber kopieren. Hat bei einem anderen Problem ja auch schon mal geholfen.
-> Schönen Abend!
Ian Styx am |
Bevor du schweres Geschütz auffährst....
Ich glaube ich habe es jetzt. Im Core in functions_config und in categorytemplates 2.3.6.
Oh meih, so spät schon. Jetzt aber Schluß! 🙂
Edit: Achtung Ich habe das (in der config) heute nochmal nachgebessert.
Beat Post author am |
Also. Ich habe die letzte Version der functions_config.inc.php (von ca. 11:00 Uhr) in RAW kopiert und dann auf den Server hochgeladen.
Dann wollte ich das Plugin updaten, doch nach dem Klicken auf Plugins updaten erhielt ich eine Error-Page.
Wieder eingeloggt, in der Plugin-Liste Spartacus geöffnet und beim Speichern wurde ich wieder auf eine Error-Page geworfen. Das war der Inhalt:
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(122): serendipity_db_insert('config', Array) #3 /include/plugin_api.inc.php(1569): serendipity_set_config_var('serendipity_eve...', 'true') #4 /include/admin/plugins.inc.php(136): serendipity_plugin->set_config('serendipity_eve...', 'true') #5 /serendipity_admin.php(162): include('/var/www/vhosts...') #6 {main} thrown in /include/db/mysqli.inc.php on line 76
Meine Folgerung: die letzte Version der functions_config.inc.php funktioniert nicht.
Dann kopierte ich die Original V 4.0.1 functions_config.inc.php von https://www.styx.dokumenzi.ch/ (gleicher Server) hier hin.
Plugins updaten funktioniert nun. Das categorytemplates-Plugin auf 2.3.6 upgedatet.
Und nun. Siehe da: 🎇 EIN WUNDER! 🎆 Nun kann ich Kategorien editieren und speichern, ohne dass ich auf eine Error-Page abgeworfen werde!
Was ich daraus folgere:
Das categorytemplates-Plugin V 2.3.6 hat den Fehler behoben oder
die hier (vorher) laufende functions_config.inc.php war korrupt.
Ian Styx am |
Hosianna! 🙄
Ich kann mir aber einfach kein Szenario denken in der ein korruptes file solch einen spezifischen Error schmeissen kann. Entweder ist es kaputt, hat das falsche Format oder es hat falsche Permissions. Beides kann nicht diesen genauen Fehler produzieren, außer vielleicht es ist - spooky enough - in irgendeiner Weise möglich, mittels eines gewissen Formats, ein andersartiges error reporting zu forcieren. Das einzige was sein kann ist, dass das file tatsächlich kaputt aufgespielt war, und der Nginx cache immer die allerletzte valide Kopie ausgespiehen hat... Aber da sind wir schon wieder im Esoterischen gelandet! Und von solchen Spielereien wollten wir ja eigentlich weg! 😏
Denn der Fehler ist valide! Wie ich habe lernen müssen, sendet ein array - in diesem Fall $vals aus dem categorytemplates folgendes, wenn das value von futureentries keinen (int) cast hat und die triple radio Option die 0 von default überträgt das Ganze korrekt ausgezeichnet als string (siehe die '0' hinter 'default'). Denn Arrays sind string Transporter.
auswirft. Dann versuchen die SQL Funktionen es auch so einzutragen. Die SQL Struktur der categorytemplates Tabelle verlangt aber ein INT für dieses Feld und dann meckert natürlich die SQL Exception. PHP 8.1/2 kann das abfangen und aus dem '' eine 0 machen. PHP 7/8.0 nicht.
Analog das ganze bei den beobachteten Issues mit emoticonchooser oder dem Abspeichern der Konfiguration.
Ich habe jetzt die POST Validation von array values mittels cast Auszeichnung entfernt und die POST Validation anders gelöst. Deshalb müssten in beiden Issues die Fehler jetzt weg sein.
Ich finde du hast absolut richtig reagiert und den einzig korrekten Schluß(strich) gezogen. Leider müssen wir nun doch an 🎇WUNDER🎆 glauben! 😚
Das entspräche dem was ich als Inhalt (alles markieren) KOPIEREN ansehen würde, um es woanders hin zu pasten. Sinn der RAW Funktion aber ist es, die Ausgabe mit (Maus) Rechtsklick mit Speichern unter direkt auf das lokale System abzuspeichern. Da ist sie dann gleich im richtigen Format, zB. ANSI oder UTF-8, usw. Und diese Datei dann einfach mit FTP rüberzuspielen.
Beat Post author am |
Kann es nachvollziehen und bestätigen aber keine Hilfe bieten. 🙄
Ian Styx am |
OH YEAH ... wie immer ist es nützlich es zu beschreiben....
Bitte teste 2.3.5.
3 auf einen Streich! 🦄🐘🐁 🐓😄
Beat Post author am |
Tja... Würde ja gerne schreiben, dass der Fehler nun weg ist, doch so ist es leider auch bei Plugin V2.3.5 nicht. Ich erhalte immer noch die gleiche Fehlermeldung (habe zuvor auch den Browsercache und die dokumenzi-Cookies gelöscht).
Ian Styx am |
Tja das wäre nett gewesen... und auch schön wenn es denn so einfach wäre ... doch die 3 auf einen Streich gelten trotzdem immer noch. 😀
Inzwischen hatte ich nochmal nachgelesen und auch gesehen, dass der error des vorgehenden issues (und Auslöser des Threads) ja tatsächlich auch ein genau solcher war - das eben ein Integer erwartet, aber ein leerer String geliefert wird. Ich kann bislang nicht erkennen wo dies geschieht. weil die Möglichkeiten immens sind. So habe ich nochmal nachgeschaut, und den "damaligen" Fix als gar nicht mehr als soooo richtig und ebenfalls ein wenig spooky empfunden.
Deshalb habe ich gerade den Verdacht, dass es sich vielleicht um ein 64bit System vs 32bit System Problem handeln könnte, was wiederum den Unterschied (und damaligen string fix) für PHP7/~8 vs PHP8+ erklären könnte, denn da gibt es Unterschiede das PHP möglicherweise einen String type zurückgibt wo ein Integer type erwartet wird.
Ich werde also wahrscheinlich diesbezüglich noch auf weitere Test von Dir zugreifen müssen, wenn du erlaubst.
Bis dahin könntest du mir einen Gefallen tun und mal mit PhpMyAdmin die config Tabelle überprüfen, ob im letzten Feld - also authorid - auch immer eine Zahl drinnen steht. Sie darf nicht leer sein. Mittels der Sortierung (auf Klick/s) kann man das sehr leicht nachprüfen. Bitte noch nichts verändern falls du fündig wirst. Ebenso bitte in der categorytemplates Tabelle im Feld futureentries, welches ebenfalls nicht leer sein darf und ansonsten nur 0,1, oder 2 enthalten darf.
Beat Post author am |
config-Tabelle, authorid ist immer mit 0 oder 1 gefüllt.
categorytemplates-Tabelle, futureentries ist immer mit 0 gefüllt.
In beiden Tabellen/Spalten also keine leeren Felder.
Ian Styx am |
👍🙏
Ab jetzt kann ich mich nur noch auf den mühseligen Weg machen, jede einzelne serendipity_db_insert Anweisung auf Variablen und zwar überall zu überprüfen, die nicht direkt (denn das habe ich schon zufriedenstellend gemacht) und dabei möglichweise falsch gesetzt sind, sondern eben all jene auf eventuell falsche init fallbacks in den dazugehörigen stack traces zu überprüfen, die womöglich für diesen speziellen Fall ein leeres String setzen.
ODER
ich mache es mir/uns einfach und korrigiere den vorherigen fix in der functions_config.inc zurück nach (int) und setzte 1 Zeile weiter rauf an den Anfang
Das müsste reichen 1. um das erste Issue zu erschlagen, 2. auch jenes in futurentries zu erschlagen und 3. die Möglichkeit der falschen Typ Zuweisung zwischen 64/32bit System zu beherrschen und 4. weiteren solchen Fällen vorzubeugen.
Magst du das mal ausprobieren? 😀
Ich habe das mit PHP 7 schon getestet (jedenfalls bezüglich des ersten Issues).
Ian Styx am |
Beat du arbeitest in categorytemplates!
Du sollst aber in functions_config.inc arbeiten (siehe ganz oben im thread)! 😀
Beat Post author am |
??? das (int) habe ich gestern aus der serendipity_event_categorytemplates.php entfernt. Dort stimmt auch die Zeilennummer 795. Dort habe ich jetzt das (int) wieder eingefügt.
Die functions_config.inc "sieht nun ab Zeile 114 wie folgt aus:
Die Errormeldung beim Abspeichern einer Kategorie kommt aber immer noch. 😪
Beat Post author am |
Noch schlimmer: mit diesen Änderungen der functions_config.inc kann ich das Backend gar nicht mehr erreichen. Habe deshalb wieder die Originaldatei der V4.0.1 im Einsatz.
In Anlehnung an James Dean: "Denn er weiss nicht, was er tut"... 😢
Ian Styx am |
Du hattest aber inzwischen auf 2.3.5 upgedated. Deshalb Finger weg! 😉
Sollte jetzt
sein und reichen.
In der ..._config - sehe ich gerade - muss das doch noch weiter rauf. Sorry. Also vor die erste serendipity_db_.. Anweisung, ca Zeile 109.
Ian Styx am |
Ist in deinem FTP Programm (FileZilla?) vielleicht die Üertragungsmethode falsch? Falls es das genannte ist, unter Bearbeiten - Einstellungen, dann Verbindung - FTP - Verbindungsmodus = passiv (Empfohlen) und unter Übertragungen - FTP:Dateitypen = Automatisch aktivieren.
Beat Post author am |
Arggh...
Crasht immer noch. Die functions_config.inc sieht nun ab Zeile 106 so aus:
Beat Post author am |
Ja, FileZilla und genau so eingestellt (Standard).
Beat Post author am |
Was mich als Laie etwas irritiert ist, dass Du nun an der "authorid" herumschraubst, der erste Teil der Fehlermeldung bezieht sich jedoch auch jetzt immer noch auf "futureentries":
Ian Styx am |
Aber das
hattest du hier nicht auf (int) zurückgestellt. Bitte noch nachholen.
Damit müsste zumindest das Abspeichern der Konfiguration ohne Fehler gehen. BZW bei dir war es ja das Abspeichern eines Eintrages, wenn emoticonchooser aktiv war (meine ich). Und bei mir zusätzlich auch noch der Aufruf der Mediathek.
Und die Relevanz liegt im
Wahrscheinlich habe ich es auch einfach miteinander verbaselt und die categorytemmplates
Meldung bezieht sich tatsächlich nur auf etwas Ähnliches, denn dieses Feld ist strukturell auch als INT Feld definiert, und müsste vielleicht ebenso abgefangen werden.
zB. so
Möchtest du das mal probieren?
Obwohl ich mich dunkel erinnere es schon einmal so probiert zu haben... aber das war vor den andren Fixes.
Beat Post author am |
Habe ich auch bemerkt und in der Zwischenzeit geändert. Hat leider auch nichts gebracht.
Beat Post author am |
Warte besser mal mit weiteren Arbeiten zu diesem Thema.
Ich bin immer noch sehr irritiert, dass es hier https://www.styx.dokumenzi.ch/ problemlos funktioniert. Hey: Das ist auf dem gleichen Server! Auch sonst treten diese Fehler bei keiner anderen Installation auf! Es ist zum 🤮!
Ich werde morgen Nachmittag die offizielle Styx V 4.01 runterladen und darüber kopieren. Hat bei einem anderen Problem ja auch schon mal geholfen.
-> Schönen Abend!
Ian Styx am |
Bevor du schweres Geschütz auffährst....
Ich glaube ich habe es jetzt. Im Core in functions_config und in categorytemplates 2.3.6.
Oh meih, so spät schon. Jetzt aber Schluß! 🙂
Edit: Achtung Ich habe das (in der config) heute nochmal nachgebessert.
Beat Post author am |
Also. Ich habe die letzte Version der functions_config.inc.php (von ca. 11:00 Uhr) in RAW kopiert und dann auf den Server hochgeladen.
Dann wollte ich das Plugin updaten, doch nach dem Klicken auf Plugins updaten erhielt ich eine Error-Page.
Wieder eingeloggt, in der Plugin-Liste Spartacus geöffnet und beim Speichern wurde ich wieder auf eine Error-Page geworfen. Das war der Inhalt:
Meine Folgerung: die letzte Version der functions_config.inc.php funktioniert nicht.
Dann kopierte ich die Original V 4.0.1 functions_config.inc.php von https://www.styx.dokumenzi.ch/ (gleicher Server) hier hin.
Plugins updaten funktioniert nun. Das categorytemplates-Plugin auf 2.3.6 upgedatet.
Und nun. Siehe da: 🎇 EIN WUNDER! 🎆 Nun kann ich Kategorien editieren und speichern, ohne dass ich auf eine Error-Page abgeworfen werde!
Was ich daraus folgere:
Ian Styx am |
Hosianna! 🙄
Ich kann mir aber einfach kein Szenario denken in der ein korruptes file solch einen spezifischen Error schmeissen kann. Entweder ist es kaputt, hat das falsche Format oder es hat falsche Permissions. Beides kann nicht diesen genauen Fehler produzieren, außer vielleicht es ist - spooky enough - in irgendeiner Weise möglich, mittels eines gewissen Formats, ein andersartiges error reporting zu forcieren. Das einzige was sein kann ist, dass das file tatsächlich kaputt aufgespielt war, und der Nginx cache immer die allerletzte valide Kopie ausgespiehen hat... Aber da sind wir schon wieder im Esoterischen gelandet! Und von solchen Spielereien wollten wir ja eigentlich weg! 😏
Denn der Fehler ist valide! Wie ich habe lernen müssen, sendet ein array - in diesem Fall $vals aus dem categorytemplates folgendes, wenn das value von futureentries keinen (int) cast hat und die triple radio Option die 0 von default überträgt das Ganze korrekt ausgezeichnet als string (siehe die '0' hinter 'default'). Denn Arrays sind string Transporter.
string(70) "fetchlimit,template,categoryid,lang,futureentries,pass,sort_order,hide"
string(56) "'6', '', '14', 'default', '0', '', 'timestamp DESC', '1'"
während es mit einem (int) cast im $val array von categorytemplates
string(70) "fetchlimit,template,categoryid,lang,futureentries,pass,sort_order,hide"
string(55) "'6', '', '14', 'default', '', '', 'timestamp DESC', '1'"
auswirft. Dann versuchen die SQL Funktionen es auch so einzutragen. Die SQL Struktur der categorytemplates Tabelle verlangt aber ein INT für dieses Feld und dann meckert natürlich die SQL Exception. PHP 8.1/2 kann das abfangen und aus dem '' eine 0 machen. PHP 7/8.0 nicht.
Analog das ganze bei den beobachteten Issues mit emoticonchooser oder dem Abspeichern der Konfiguration.
Ich habe jetzt die POST Validation von array values mittels cast Auszeichnung entfernt und die POST Validation anders gelöst. Deshalb müssten in beiden Issues die Fehler jetzt weg sein.
Ich finde du hast absolut richtig reagiert und den einzig korrekten Schluß(strich) gezogen. Leider müssen wir nun doch an 🎇WUNDER🎆 glauben! 😚
Ian Styx am |
..In RAW kopiert oder mit rechts abgespeichert (speichern unter) ? Das ist ein wesentlicher Unterschied !
Beat Post author am |
Wie erkläre ich das in wenigen Worten???
Ich kann es gerne noch einmal machen.
Ian Styx am |
Das entspräche dem was ich als Inhalt (alles markieren) KOPIEREN ansehen würde, um es woanders hin zu pasten. Sinn der RAW Funktion aber ist es, die Ausgabe mit (Maus) Rechtsklick mit Speichern unter direkt auf das lokale System abzuspeichern. Da ist sie dann gleich im richtigen Format, zB. ANSI oder UTF-8, usw. Und diese Datei dann einfach mit FTP rüberzuspielen.
Beat Post author am |
Kann ich gerne mal so machen.