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 ich gerne mal so machen.
Beat Post author am |
OHA!
Nun in "Raw" Rechtsklick, abgespeichert und hochgeladen.
Nun keine Fehlermeldungen mehr. 👍
Also: Die neuste Version der functions_config.inc.php funktioniert. Jetzt kann ich also nicht mehr genau sagen, ob dies das Problem gelöst hat oder ob es das neue categorytemplates-Plugin war.
Übrigens, und auch nur bei Einzeländerungen, wenn man in FileZilla seinen Notepad++ als Editor hinterlegt, braucht man nicht mehr herunterladen, sondern kann direkt auf Bearbeiten gehen. Der lädt das temporäre file dann in den Editor - wo du nun deine Änderungen machst - und beim Speichern wird das gleich wieder quasi automatisch aufgespielt. Bzw, er fragt dich ob er es aktualisieren soll.
Sehr viel einfacher. 🙂
Beat Post author am |
Danke für den Tipp, Doch ich bin ein Schisser 😬. Direkt in Files etwas ändern, möchte ich nicht. Ich mache mir immer eine File-Kopie die ich dann bearbeite. Sollte ich Mist bauen, kann ich das Original-File wieder hochladen und gut ist. Ich kenne meine Grenzen...
Solange man diese temporäre Datei offen läßt kann man mit dem npp History Zurück ja immer auf den Ausgangspunkt zurückstellen. Aber vielleicht besser so wie du es machst, wenn auch umständlicher.
Nur dran denken im anderweitigen Fall die RAW Dateien als Ganzes mit Rechts abzuspeichern und dieses file dann heraufzuladen. (Siehe....) 😉
TestHorst am |
Kann man wieder kommentieren?
Ping am |
hopefully.😀
Bin noch da, siehe da, ... Oh! Du brauchst 4.1.2 !
Beat Post author am |
4.1.2 wurde mir nicht zur Installation vorgeschlagen. Habe es nun manuell installiert. Nach der Installation erhielt ich folgende Warnung:
Warning: Undefined array key "dbNames" in /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/functions_installer.inc.php: 109.
Administrative Login Error Warning only - not seen by visitors! Send us a note what happened where and when, please.
Ich habe jetzt Styx 4.1.2 und PHP 8.2.4. Im Backend kann ich keine neuen Beiträge schreiben oder bestehende editieren. Ich erhalte dann jeweils eine blanke, weisse Seite. Auch wenn ich auf Plugins updaten klicke, erhalte ich eine blanke Seite. Sonst sieht es eigentlich recht gut aus.
Auf www.beatsblog.ch habe ich noch 4.1.1 und ebenfalls PHP 8.2.4. Dort funktioniert alles bestens. (4.1.2 wird mir aber auch nicht zum Update vorgeschlagen).
Auf https://www.styx.dokumenzi.ch/ wurde mir 4.1.2 zum Update vorgeschlagen. Dieser lief ohne Warnung durch. Neue Einträge schreiben funktioniert. Doch bei Plugins updaten erhalte ich ebenfalls eine weisse Seite.
Blöd ist, dass ich jetzt nicht weiss, ob es mit den Serverproblemen (imunify360) zusammenhängt (die schrauben derzeit auch rum) oder ob es ein Styx-Problem ist.
Ian Styx am |
Was ist denn da los....🙄
Kannst du bitte mal in die error logs schauen.
Ich hoffe dass das nur mit dem manuellen Aufspielen zu tun hat und dies (wieder...?) Fehler produziert hat. Das müssen wir definitiv ausschließen.
Ansonsten wäre es schräg wenn es doch mit dem 4.1.2 fix zu tun hat. Dann sollten die errors etwa wie "Uncaught mysqli_sql_exception: Incorrect integer value: '' for column database.styx_config.authorid at row 1" lauten. Schau mal in die Styx issues #40 (schon geschlossen). Der Lösungsansatz müsste dann eventuell (versuchsweise) rückgängig gemacht werden...
Das mit dem dbNames hatten wir schon mal, meine ich. Meinen Vorschlag zur Lösung und Abklärung hattest du (damals) glaube ich nicht umgesetzt, siehe https://www.blog.dokumenzi.ch/2674-Styx-3.9.1-und-PHP-8.0.21.html
Beat Post author am |
In der config-Tabelle gab es tatsächlich keinen dbNames-Eintrag. Ich habe diesen nun mit dem Wert "true" eingefügt.
Ich kann leider gar nicht mehr auf das Backend zugreifen und lande sofort auf einer weissen Seite. Ich kann also Deine Reiseabsichten nicht sehen. Schreib mir diesbezüglich doch bitte eine E-Mail. Danke.
Beat Post author am |
Die Manitu-Seiten beatsblog.ch und styx.beatsblog.ch habe ich heute per Autoupdater auf 4.1.2 gebracht. Dort funktioniert alles einwandfrei. Es hat hier also schon etwas mit den Hostingeinstellungen zu tun.
Beat Post author am |
Wenn ich die Adminoberfläche aufrufe, erhalte ich folgende Fehlermeldung im Logfile:
AH01071: Got error 'PHP message: PHP 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\nStack trace:\n#0 /include/db/mysqli.inc.php(76): mysqli_query()\n#1 /include/db/db.inc.php(84): serendipity_db_query()\n#2 /include/functions_config.inc.php(123): serendipity_db_insert()\n#3 /include/functions_installer.inc.php(1408): serendipity_set_config_var()\n#4 /include/admin/overview.inc.php(73): serendipity_getCurrentVersion()\n#5 /serendipity_admin.php(252): include('...')\n#6 {main}\n thrown in /include/db/mysqli.inc.php on line 76'
Und das kann eigentlich nicht sein.... weder auf PHP 8.1 noch auf PHP 8.2. Das habe ich heute Morgen gerade noch mal alles durchgetestet. Ich nehme also stark an dass dein manuelles Update unvollständig bzw anderweitig falsch war.
Ich würde also vorschlagen du schnappst dir die
/include/db/db.inc.php
und zur Not falls das nicht klappt auch die
/include/functions_config.inc.php
von github, speicherst sie im RAW Modus (mit rechts: Speichern unter) und spielst diese Datei(en) dann mit FTP (im auto bzw binary Modus) auf. Vorerst nur die eine.
Falls das geht sollten wir dann nochmal alles soweit einstellen dass du doch noch einmal das autoupdate ziehen kannst, damit andere Fehler die beim Überspielen möglicherweise eingeflossen sind verschwinden.
Bevor ich nicht wirklich sicher bin das alles vorerst korrekt funktioniert ist an andere Vergnügungen nicht zu denken. 😱
Beat Post author am |
/include/db/db.inc.php
kopiert und aufgespielt. In Firefox den Cache geleert. Admin-Seite aufgerufen = weisse Seite.
/include/functions_config.inc.php
kopiert und aufgespielt. In Firefox den Cache geleert. Admin-Seite aufgerufen = weisse Seite.
Mir ist aufgefallen, dass beide Flies genau gleich viele Bytes gross waren, wie die, die schon dort waren.
So über den Daumen gepeilt ist die Error-Message im Logfile noch immer gleich.
AH01071: Got error 'PHP message: PHP Fatal error: Uncaught mysqli_sql_exception: Incorrect integer value: '' for column `styx3`.`styx_config`.`authorid` at row 1 in /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/db/mysqli.inc.php:76\nStack trace:\n#0 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/db/mysqli.inc.php(76): mysqli_query()\n#1 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/db/db.inc.php(84): serendipity_db_query()\n#2 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/functions_config.inc.php(123): serendipity_db_insert()\n#3 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/functions_installer.inc.php(1408): serendipity_set_config_var()\n#4 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/include/admin/overview.inc.php(73): serendipity_getCurrentVersion()\n#5 /var/www/vhosts/dokumenzi.ch/httpdocs/styx-master/serendipity_admin.php(252): include('...')\n#6 {main}\n thrown in include/db/mysqli.inc.php on line 76'
Ich denke deshalb immer noch, dass wir hier kein Styx-Problem haben, sondern dass uns irgend eine Hostingeinstellung dazwischenfunkt. Gemäss Hosttech-Support haben sie die "Domaine-Firewall" ausgeschaltet und dadurch kann man (hier) wieder kommentieren. Für mich macht das keinen wirklichen Sinn, denn früher war diese Firewall immer eingeschaltet und es hat trotzdem funktioniert (ausserdem hat die wohl nichts mit imunify360 zu tun).
Beat Post author am |
Bei Manitu funktioniert ja alles bestens. Nur bei Hosttech gibt es diese Probleme.
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.
Beat Post author am |
OHA!
Nun in "Raw" Rechtsklick, abgespeichert und hochgeladen.
Nun keine Fehlermeldungen mehr. 👍
Also: Die neuste Version der functions_config.inc.php funktioniert. Jetzt kann ich also nicht mehr genau sagen, ob dies das Problem gelöst hat oder ob es das neue categorytemplates-Plugin war.
Ian Styx am |
👍 Beides! Da sie unterschiedliche Probleme behandeln. Siehe 1. Issue und das 2. mit dem für futureentries.
Ian Styx am |
Übrigens, und auch nur bei Einzeländerungen, wenn man in FileZilla seinen Notepad++ als Editor hinterlegt, braucht man nicht mehr herunterladen, sondern kann direkt auf Bearbeiten gehen. Der lädt das temporäre file dann in den Editor - wo du nun deine Änderungen machst - und beim Speichern wird das gleich wieder quasi automatisch aufgespielt. Bzw, er fragt dich ob er es aktualisieren soll.
Sehr viel einfacher. 🙂
Beat Post author am |
Danke für den Tipp, Doch ich bin ein Schisser 😬. Direkt in Files etwas ändern, möchte ich nicht. Ich mache mir immer eine File-Kopie die ich dann bearbeite. Sollte ich Mist bauen, kann ich das Original-File wieder hochladen und gut ist. Ich kenne meine Grenzen...
Ian Styx am |
Solange man diese temporäre Datei offen läßt kann man mit dem npp History Zurück ja immer auf den Ausgangspunkt zurückstellen. Aber vielleicht besser so wie du es machst, wenn auch umständlicher.
Nur dran denken im anderweitigen Fall die RAW Dateien als Ganzes mit Rechts abzuspeichern und dieses file dann heraufzuladen. (Siehe....) 😉
TestHorst am |
Kann man wieder kommentieren?
Ping am |
hopefully.😀
Bin noch da, siehe da, ... Oh! Du brauchst 4.1.2 !
Beat Post author am |
4.1.2 wurde mir nicht zur Installation vorgeschlagen. Habe es nun manuell installiert. Nach der Installation erhielt ich folgende Warnung:
Ich habe jetzt Styx 4.1.2 und PHP 8.2.4. Im Backend kann ich keine neuen Beiträge schreiben oder bestehende editieren. Ich erhalte dann jeweils eine blanke, weisse Seite. Auch wenn ich auf Plugins updaten klicke, erhalte ich eine blanke Seite. Sonst sieht es eigentlich recht gut aus.
Auf www.beatsblog.ch habe ich noch 4.1.1 und ebenfalls PHP 8.2.4. Dort funktioniert alles bestens. (4.1.2 wird mir aber auch nicht zum Update vorgeschlagen).
Auf https://www.styx.dokumenzi.ch/ wurde mir 4.1.2 zum Update vorgeschlagen. Dieser lief ohne Warnung durch. Neue Einträge schreiben funktioniert. Doch bei Plugins updaten erhalte ich ebenfalls eine weisse Seite.
Blöd ist, dass ich jetzt nicht weiss, ob es mit den Serverproblemen (imunify360) zusammenhängt (die schrauben derzeit auch rum) oder ob es ein Styx-Problem ist.
Ian Styx am |
Was ist denn da los....🙄
Kannst du bitte mal in die error logs schauen.
Ich hoffe dass das nur mit dem manuellen Aufspielen zu tun hat und dies (wieder...?) Fehler produziert hat. Das müssen wir definitiv ausschließen.
Ansonsten wäre es schräg wenn es doch mit dem 4.1.2 fix zu tun hat. Dann sollten die errors etwa wie "Uncaught mysqli_sql_exception: Incorrect integer value: '' for column database.styx_config.authorid at row 1" lauten. Schau mal in die Styx issues #40 (schon geschlossen). Der Lösungsansatz müsste dann eventuell (versuchsweise) rückgängig gemacht werden...
Das mit dem dbNames hatten wir schon mal, meine ich. Meinen Vorschlag zur Lösung und Abklärung hattest du (damals) glaube ich nicht umgesetzt, siehe https://www.blog.dokumenzi.ch/2674-Styx-3.9.1-und-PHP-8.0.21.html
Beat Post author am |
In der config-Tabelle gab es tatsächlich keinen dbNames-Eintrag. Ich habe diesen nun mit dem Wert "true" eingefügt.
Ich kann leider gar nicht mehr auf das Backend zugreifen und lande sofort auf einer weissen Seite. Ich kann also Deine Reiseabsichten nicht sehen. Schreib mir diesbezüglich doch bitte eine E-Mail. Danke.
Beat Post author am |
Die Manitu-Seiten beatsblog.ch und styx.beatsblog.ch habe ich heute per Autoupdater auf 4.1.2 gebracht. Dort funktioniert alles einwandfrei. Es hat hier also schon etwas mit den Hostingeinstellungen zu tun.
Beat Post author am |
Wenn ich die Adminoberfläche aufrufe, erhalte ich folgende Fehlermeldung im Logfile:
Ian Styx am |
Und das kann eigentlich nicht sein.... weder auf PHP 8.1 noch auf PHP 8.2. Das habe ich heute Morgen gerade noch mal alles durchgetestet. Ich nehme also stark an dass dein manuelles Update unvollständig bzw anderweitig falsch war.
Ich würde also vorschlagen du schnappst dir die
und zur Not falls das nicht klappt auch die
von github, speicherst sie im RAW Modus (mit rechts: Speichern unter) und spielst diese Datei(en) dann mit FTP (im auto bzw binary Modus) auf. Vorerst nur die eine.
Falls das geht sollten wir dann nochmal alles soweit einstellen dass du doch noch einmal das autoupdate ziehen kannst, damit andere Fehler die beim Überspielen möglicherweise eingeflossen sind verschwinden.
Bevor ich nicht wirklich sicher bin das alles vorerst korrekt funktioniert ist an andere Vergnügungen nicht zu denken. 😱
Beat Post author am |
kopiert und aufgespielt. In Firefox den Cache geleert. Admin-Seite aufgerufen = weisse Seite.
kopiert und aufgespielt. In Firefox den Cache geleert. Admin-Seite aufgerufen = weisse Seite.
Mir ist aufgefallen, dass beide Flies genau gleich viele Bytes gross waren, wie die, die schon dort waren.
So über den Daumen gepeilt ist die Error-Message im Logfile noch immer gleich.
Ich denke deshalb immer noch, dass wir hier kein Styx-Problem haben, sondern dass uns irgend eine Hostingeinstellung dazwischenfunkt. Gemäss Hosttech-Support haben sie die "Domaine-Firewall" ausgeschaltet und dadurch kann man (hier) wieder kommentieren. Für mich macht das keinen wirklichen Sinn, denn früher war diese Firewall immer eingeschaltet und es hat trotzdem funktioniert (ausserdem hat die wohl nichts mit imunify360 zu tun).
Beat Post author am |
Bei Manitu funktioniert ja alles bestens. Nur bei Hosttech gibt es diese Probleme.
Ian Styx am |
Mit dem Unterschied auto und manuell 😉
Ian Styx am |
Öffne mal die aufgespielte db.inc. Sie sollte dem hier entsprechen:
https://github.com/ophian/styx/blob/master/include/db/db.inc.php#L73
bis Zeile 78
Ich glaube nicht das sie so da ist.
Mit der Firewall und immunify etc kann das nix zu tun haben.