Styx 3.8.2 und PHP 8.0.16

beats TEST blog

Donnerstag, 14. April 2022

Styx 3.8.2 und PHP 8.0.16

alle Plugins aktualisiert
Trackback-URL für diesen Eintrag

Dieser Link ist nicht aktiv. Er enthält eine kopierbare Trackback-URI, um manuell ein Ping- und Trackback zu diesem Eintrag für ältere Blogsysteme zu generieren; zB (immer noch valide) über das zur Verfügung gestellte Eintragsfeld des serendipity_event_trackback Plugins. Serendipity und andere Blogsysteme erkennen die Trackback-URL heutzutage aber automatisch anhand der Artikel-URL. Die Trackback-URI für ihren Link des Sender-Eintrages lautet daher wie folgt: »https://www.blog.dokumenzi.ch/2672-Styx-3.8.2-und-PHP-8.0.16.html«

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

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

  2. Ian Styx am :

    Moin Beat

    Merkwürdig.... Das ist ja mal ein stack trace über 17 Stationen... Whow!

    Moment....

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

  4. 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?

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

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

     

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

  8. 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!

  9. 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! 😎

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

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

  12. 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... 😁

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

  14. Ian Styx am :

    Wer lesen kann ist stark im Vorteil... 😉

    Erneuter Versuch (Bitte!)

  15. Beat Post author am :

    Non capisco. 🙄

    Ich kann nicht an einem Tag ein Plugin 2x updaten. Oder habe ich etwas grundsätzlich falsch verstanden?

  16. 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 🙄

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

     

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

  19. Beat Post author am :

    Leider Nein.

    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('15', Array) #4 /include/plugin_api.inc.php(1143): serendipity_event_categorytemplates->event_hook('backend_categor...', Object(serendipity_property_bag), '15', NULL) #5 /include/functions.inc.php(1611): serendipity_plugin_api::hook_event('backend_categor...', '15') #6 /include/admin/category.inc.php(74): serendipity_updateCategory('15', 'Uebriges', 'f\xC3\xBCr Men\xC3\xBC "\xC3\x9Cb...', 0, '', '14', 'timestamp DESC', '0', '') #7 /serendipity_admin.php(224): include('/var/www/vhosts...') #8 {main} thrown in /include/db/mysqli.inc.php on line 76

    Bis morgen...

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

  21. Ian Styx am :

    Im categorytemplates Plugin gibt es in Zeile 795

                            'futureentries' => !empty($serendipity['POST']['cat']['futureentries']) ? (int)$serendipity['POST']['cat']['futureentries'] : 0,

    Nimm bitte mal das (int) weg.

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

  23. Beat Post author am :

    Der error bleibt.

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

    <input id="futureentries_default" class="input_radio" name="serendipity[cat][futureentries]" type="radio" value="0">

    Sobald also gesendet wird, muss 0 für die folgende SQL query genommen werden. Ankommen laut Errormeldung

    Incorrect integer value: '' for column `styx3`.`styx_categorytemplates`.`futureentries`

    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.

  25. Beat Post author am :

    Kann es nachvollziehen und bestätigen aber keine Hilfe bieten. 🙄

  26. Ian Styx am :

    OH YEAH ... wie immer ist es nützlich es zu beschreiben....

    Bitte teste 2.3.5.
    3 auf einen Streich! 🦄🐘🐁    🐓😄

  27. 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).

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

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

  30. 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).

  31. Ian Styx am :

    Beat du arbeitest in categorytemplates!
    Du sollst aber in functions_config.inc arbeiten (siehe ganz oben im thread)! 😀

  32. 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:

    if ($name == 'password' || $name == 'check_password') {
      return;
    }
if ($authorid == '') $authorid = 0;
$r = serendipity_db_insert('config', array('name' => serendipity_db_escape_string($name), 'value' => $val, 'authorid' => (int)$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;
        }
    }

    Die Errormeldung beim Abspeichern einer Kategorie kommt aber immer noch. 😪

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

  34. Ian Styx am :

    Du hattest aber inzwischen auf 2.3.5 upgedated. Deshalb Finger weg! 😉

    Sollte jetzt

    'futureentries' => (int)($serendipity['POST']['cat']['futureentries'] ?? 0),

    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.

     

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

  36. 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;
    }
}

     

  37. Beat Post author am :

    Ja, FileZilla und genau so eingestellt (Standard).

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

     

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

    zB. so

                            'futureentries' => (int)(!empty($serendipity['POST']['cat']['futureentries']) ? $serendipity['POST']['cat']['futureentries'] : 0),

    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.

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

  41. 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!

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

  43. 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:

    1. Das categorytemplates-Plugin V 2.3.6 hat den Fehler behoben oder
    2. die hier (vorher) laufende functions_config.inc.php war korrupt.

  44. 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! 😚

  45. Ian Styx am :

    in RAW kopiert und dann auf den Server hochgeladen.

    ..In RAW kopiert oder mit rechts abgespeichert (speichern unter) ? Das ist ein wesentlicher Unterschied !

  46. Beat Post author am :

    Wie erkläre ich das in wenigen Worten???

    1. Die functions_config.inc.php mit FileZilla vom Server nach lokal kopiert.
    2. Mit Notepad++ das File geöffnet, mit Ctrl+A und Del das File geleert.
    3. https://github.com/ophian/styx/blob/master/include/functions_config.inc.php geöffnet und in "Raw" anzeigen lassen.
    4. Mit Ctrl+A und Ctrl+C alles kopiert
    5. In Notepad++ in die leere Datei mit Ctrl+V eingefügt.
    6. functions_config.inc.php gespeichert und mit FileZilla wieder auf den Server hochgeladen.

    Ich kann es gerne noch einmal machen.

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

  48. Beat Post author am :

    Kann ich gerne mal so machen.

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

  50. Ian Styx am :

    👍 Beides! Da sie unterschiedliche Probleme behandeln. Siehe 1. Issue und das 2. mit dem für futureentries.

  51. 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. 🙂

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

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

  54. TestHorst am :

    Kann man wieder kommentieren?

  55. Ping am :

    hopefully.😀

    Bin noch da, siehe da, ... Oh! Du brauchst 4.1.2 !

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

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

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

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

  60. 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'

     

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

    /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. 😱

  62. 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).

  63. Beat Post author am :

    Bei Manitu funktioniert ja alles bestens. Nur bei Hosttech gibt es diese Probleme.

  64. Ian Styx am :

    Mit dem Unterschied auto und manuell 😉

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

  66. Beat Post author am :

    Habe ich überprüft. Ja, diese Zeilen sind gleich. (Ich frage jetzt nur zu meiner Sicherheit: Das ist doch der gleiche Inhalt wie in der oben beschriebenen include/db/db.inc.php. Oder?)

  67. Beat Post author am :

    Ich glaube, das ist nicht matchentscheidend. Auf styx.dokumenzi.ch habe ich die Autoupgrade-Funktion benutzt. Da kann ich mich zwar im Backend einloggen Beiträge und Kommentare schreiben, doch wenn ich auf "Plugins updaten" klicke, erhalte ich auch dort eine weisse Seite.

  68. Ian Styx am :

    Wie meinen..? Ja, die aufgezeigte github db inc muss auch der 4.1.2 release db.inc entsprechen.

    Wie hast du die dokumenzi Datei denn überprüft?
    D.h. wirklich diejenige die du schon auf den Server aufgeladen hast ? Oder die die du benutzt hast zum Upload ?

  69. Ian Styx am :

    Da kann ich mich zwar im Backend einloggen Beiträge und Kommentare schreiben, doch wenn ich auf "Plugins updaten" klicke, erhalte ich auch dort eine weisse Seite.

    Dann musst du dort auch noch mal im error log graben. Das kann dann vielleicht ein Fehler sein der ähnlich ist und/aber unter Umständen nicht durch den Fix abgedeckt ist.

  70. Beat Post author am :

    Zuerst habe ich die db.inc.php von 4.1.2-github in raw per Rechtsklick gespeichert und dann auf den Hosttech-Server geladen. Weil Du nun die Zeilen 73-78 angesprochen hast, habe ich diese Zeilen der blob-githib-Version per Auge mit denen verglichen, die ich zuvor aufgespielt hatte. Da erkannte ich keinen Unterschied. Trotzdem habe ich diese Zeilen dann kopiert und das File (welches wieder exakt 6'005 Bytes gross war) wieder hochgespielt. Wie zu erwarten: Kein Unterschied.

    Ich stelle jetzt noch eine ganz blöde Frage. Könnte das irgendwie mit einem falschen Zeichensatz zu tun haben? Achte Dich mal auf die Mitteilung nach Absenden eines Kommentars. Da steht: Kommentar %swurde hinzugefügt. Also %s und nicht die Nummer des Kommentars. Wir hatten doch auf dem Hosttech-Server grosse Mühe um utf8mb4 einzubringen. Vielleicht spukt die Zeichenübertragung zur DB? Nur so ein Gedanke...

  71. Ian Styx am :

    Nee das habe ich dir gerade geschrieben. Das ist etwas anderes.

    Ich habe dir doch mal geschrieben wie man Notepad++ im FileZilla als Editor hinterlegt. Dann mit FileZilla auf den Server gehen und die Datei suchen und im FileZilla auf Bearbeiten gehen. Diese Datei wird dann in den temp dein OS heruntergeladen und im NPP geöffnet. Jede darin gemachte Änderung wird beim Speichern auf wieder (korrekt) hochgeladen.

  72. Ian Styx am :

    mail ping 📧

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
▲