Blog-Update und Umaut-Patch
So, heute habe ich ein bisschen mehr Zeit, um mich mit meinem Blog zu beschäftigen. Gestern war ja ein wirklich kurzer Eintrag, sehr bilderlastig. Aber bevor ich mich mit weiteren Fotos von gestern beschäftigen konnte, musste ich mal endlich das Blog-Software-Update einspielen. Das wartete jetzt schon bestimmt einen halben Monat und die Release-Notes sagten eigentlich was von "zeitnahe" oder so. 
Also habe ich heute Morgen mal als erstes ein Backup gezogen, von allem, Datenbank und PHP und alle Uploads. Mittlerweile ist das ganze Blog 12 Gigabyte groß! Hallo?! Wie ist das denn passiert? Sollte ich vielleicht doch weniger Bilder hochladen? Oder zumindest nicht in 4k? Näää!
Aber gut zu wissen, wie viel Scheiß ich da mittlerweile abgeworfen habe, in den letzte 20 Jahren. Da scheint sich ja doch einiges angesammelt zu haben! Ich hatte ja immer mal vor, meine Tagebucheinträge aus den 1990ern zu sichten und mit hier rein zu stellen, aber ich glaube, das lasse ich mal lieber. Also, jetzt nicht nur aus Platzgründen, auch weil ich damals NAMEN GENANNT habe, nicht so wie heutzutage! Mal ganz davon abgesehen, dass ich das Zeug wahrscheinlich eh nicht mehre lesen kann.
Aber egal, zurück zu meinen Update-Problemen. Wie vorausgesehen, gestaltete sich das ein bisschen schwerer. Also, eigentlich nicht. Ich habe nach dem Backup einfach den Auto-Update-Button gedrückt, der funktioniert hervorragend und alles lief mehr oder weniger. An der Stelle hatte ich zwar direkt gesehen, dass das eine oder andere Style-Element im Template nicht mehr ganz so passend war, weil irgendetwas anders interpretiert wurde, aber im Großen und Ganzen lief alles.
Einer der Gründe, weshalb ich das Update grundsätzlich zeitnah machen wollte, war die Tatsache, dass das Blog jetzt offiziell auch PHP 8 unterstützt und new is always better. Wer weiß, wie lange 7.4 noch unterstützt wird. Auch wenn ich bei All Inkl bisher noch nie in entsprechende Probleme gelaufen bin, im Gegensatz zu meinen Freunden von den anderen Hostern, die einfach immer fröhlich Geld für einen "extended Support" berechnen. Muss ich auch mal endlich kündigen, fällt mir dabei ein.
Jedenfalls fingen meine Probleme dann an, als ich die Domains auf PHP 8.2 gestellt habe. Das Blog blieb einfach leer, was auf Template-Probleme hindeutet. Ist ja auch klar, außer dem CSS habe ich glaube ich in den letzten 10 Jahren das Template nicht angefasst, kein Wunder, dass das nicht mehr kompatibel ist. Also aus dem Standard-Template alle nötigen Dateien kopiert und angepasst, was einigermaßen flott ging. Ich mein, mein Template ist eigentlich nur das Standard-Teil mit einem angepassten Stylesheet. Könnte genau so gut das CSS-File im Standard-Template abwerfen und gut ist, nur dass es da bei jedem Update überschrieben würde.
Nach der Kopier- und Anpass-Aktion ging dann soweit auch wieder alles und das ganze hatte mich auch nur eine halbe Stunde Zeit gekostet. Bis auf dass das Datum mal wieder in UTF ausgegeben wird, obwohl die Seite in ISO kodiert ist, aus historischen Gründen. Ich glaube, das ist noch immer so von der aller aller ersten Installation so, die ich damals auf unserem Heim-Server laufen hatte. Und statt jetzt in jedem Eintrag die Kodierung zu ändern und dabei potenziell die Datenbank zu zerstören, lasse ich da mal lieber die Finger von. Meine preg_replace() waren noch nie vertauenswürdig!
Das Problem wäre mir ja auch gar nicht aufgefallen, wenn wir nicht gerade März hätten und jetzt da oben im Titel stattdessen "März" stünde. Irgendwo in den Untiefen des Systems ist ein date("F") versteckt, das ich nicht finden kann, so sehr ich auch danach suche. Stelle ich das Blog auf UTF-8, stimmt das wieder, aber die Einträge haben halt lauter falsche Umlaute und werden dadurch mehr oder weniger unlesbar. Also lieber erstmal mit dem kaputten März leben.
Irgendwo auf dem Weg vom Server durchs Template durch die Befüllung mit Inhalt und schließlich zum Anwender ist etwas falsch konfiguriert. (Ich vermute, das PHP ist der Meinung, dass es grundsätzlich UTF ausgeben sollte, solange niemand was anderes verlangt, und das passiert wohl nicht.) Ich weiß, dass ich nach irgendeinem Update das gleiche Problem schon mal hatte und ich irgendeinen wilden Hack angewandt habe, um das los zu werden. Ich kann mich aber nicht mehr erinnern. Insbesondere nicht daran, ob es irgendwas mit der Server-Config bei all inkl zu tun hatte, oder ob ich tatsächlich den Quellcode manipuliert hatte. Alles, was ich finde, ist ein kryptischer Eintrag von 2017. Ja, danke, past me, dass Du nicht ein bisschen ausführlicher geschrieben hast!
Jedenfalls: Habe ich gerade keine Zeit, mich näher damit zu beschäftigen. Ist ja auch mehr oder weniger egal, was da oben in der Titelleiste steht. Ich kann zumindest für kurze Zeit damit leben. Ich hoffe, der Rest des Internets auch!
EDIT 17:17 Uhr: Quick & dirty fix, /include/functions_smarty.inc.php, Zeilen 742ff:
Schön ist anders, aber zu mehr habe ich gerade keine Lust. Eigentlich sollte das automatisch passieren, denke ich, je nach gewähltem Output-Encoding. Muss ich da mal einen Bug Report auf machen oder ist das so eine spezielle Situation, dass das nur bei mir vorkommt...?
EDIT 16.3.2024, 17:36 Uhr: Nach ein bisschen Nachfragen im s9y-Forum habe ich das jetzt runterkondensiert auf einen einzeiler in der /include/functions.inc.php, Zeile 162:
Das patcht die function serendipity_strftime(), was sehr viel eleganter ist.
Also habe ich heute Morgen mal als erstes ein Backup gezogen, von allem, Datenbank und PHP und alle Uploads. Mittlerweile ist das ganze Blog 12 Gigabyte groß! Hallo?! Wie ist das denn passiert? Sollte ich vielleicht doch weniger Bilder hochladen? Oder zumindest nicht in 4k? Näää!
Aber gut zu wissen, wie viel Scheiß ich da mittlerweile abgeworfen habe, in den letzte 20 Jahren. Da scheint sich ja doch einiges angesammelt zu haben! Ich hatte ja immer mal vor, meine Tagebucheinträge aus den 1990ern zu sichten und mit hier rein zu stellen, aber ich glaube, das lasse ich mal lieber. Also, jetzt nicht nur aus Platzgründen, auch weil ich damals NAMEN GENANNT habe, nicht so wie heutzutage! Mal ganz davon abgesehen, dass ich das Zeug wahrscheinlich eh nicht mehre lesen kann.Aber egal, zurück zu meinen Update-Problemen. Wie vorausgesehen, gestaltete sich das ein bisschen schwerer. Also, eigentlich nicht. Ich habe nach dem Backup einfach den Auto-Update-Button gedrückt, der funktioniert hervorragend und alles lief mehr oder weniger. An der Stelle hatte ich zwar direkt gesehen, dass das eine oder andere Style-Element im Template nicht mehr ganz so passend war, weil irgendetwas anders interpretiert wurde, aber im Großen und Ganzen lief alles.
Einer der Gründe, weshalb ich das Update grundsätzlich zeitnah machen wollte, war die Tatsache, dass das Blog jetzt offiziell auch PHP 8 unterstützt und new is always better. Wer weiß, wie lange 7.4 noch unterstützt wird. Auch wenn ich bei All Inkl bisher noch nie in entsprechende Probleme gelaufen bin, im Gegensatz zu meinen Freunden von den anderen Hostern, die einfach immer fröhlich Geld für einen "extended Support" berechnen. Muss ich auch mal endlich kündigen, fällt mir dabei ein.
Jedenfalls fingen meine Probleme dann an, als ich die Domains auf PHP 8.2 gestellt habe. Das Blog blieb einfach leer, was auf Template-Probleme hindeutet. Ist ja auch klar, außer dem CSS habe ich glaube ich in den letzten 10 Jahren das Template nicht angefasst, kein Wunder, dass das nicht mehr kompatibel ist. Also aus dem Standard-Template alle nötigen Dateien kopiert und angepasst, was einigermaßen flott ging. Ich mein, mein Template ist eigentlich nur das Standard-Teil mit einem angepassten Stylesheet. Könnte genau so gut das CSS-File im Standard-Template abwerfen und gut ist, nur dass es da bei jedem Update überschrieben würde.
Nach der Kopier- und Anpass-Aktion ging dann soweit auch wieder alles und das ganze hatte mich auch nur eine halbe Stunde Zeit gekostet. Bis auf dass das Datum mal wieder in UTF ausgegeben wird, obwohl die Seite in ISO kodiert ist, aus historischen Gründen. Ich glaube, das ist noch immer so von der aller aller ersten Installation so, die ich damals auf unserem Heim-Server laufen hatte. Und statt jetzt in jedem Eintrag die Kodierung zu ändern und dabei potenziell die Datenbank zu zerstören, lasse ich da mal lieber die Finger von. Meine preg_replace() waren noch nie vertauenswürdig!
Das Problem wäre mir ja auch gar nicht aufgefallen, wenn wir nicht gerade März hätten und jetzt da oben im Titel stattdessen "März" stünde. Irgendwo in den Untiefen des Systems ist ein date("F") versteckt, das ich nicht finden kann, so sehr ich auch danach suche. Stelle ich das Blog auf UTF-8, stimmt das wieder, aber die Einträge haben halt lauter falsche Umlaute und werden dadurch mehr oder weniger unlesbar. Also lieber erstmal mit dem kaputten März leben.
Irgendwo auf dem Weg vom Server durchs Template durch die Befüllung mit Inhalt und schließlich zum Anwender ist etwas falsch konfiguriert. (Ich vermute, das PHP ist der Meinung, dass es grundsätzlich UTF ausgeben sollte, solange niemand was anderes verlangt, und das passiert wohl nicht.) Ich weiß, dass ich nach irgendeinem Update das gleiche Problem schon mal hatte und ich irgendeinen wilden Hack angewandt habe, um das los zu werden. Ich kann mich aber nicht mehr erinnern. Insbesondere nicht daran, ob es irgendwas mit der Server-Config bei all inkl zu tun hatte, oder ob ich tatsächlich den Quellcode manipuliert hatte. Alles, was ich finde, ist ein kryptischer Eintrag von 2017. Ja, danke, past me, dass Du nicht ein bisschen ausführlicher geschrieben hast!
Jedenfalls: Habe ich gerade keine Zeit, mich näher damit zu beschäftigen. Ist ja auch mehr oder weniger egal, was da oben in der Titelleiste steht. Ich kann zumindest für kurze Zeit damit leben. Ich hoffe, der Rest des Internets auch!
EDIT 17:17 Uhr: Quick & dirty fix, /include/functions_smarty.inc.php, Zeilen 742ff:
function serendipity_smarty_formatTime($timestamp, $format, $useOffset = true, $detectTimestamp = false, $useDate = false) {
if ($detectTimestamp !== false && stristr($detectTimestamp, 'date') === false) {
$out = $timestamp;
} else {
if (defined($format)) {
$out = serendipity_formatTime(constant($format), $timestamp, $useOffset, $useDate);
} else {
$out = serendipity_formatTime($format, $timestamp, $useOffset, $useDate);
}
}
return mb_convert_encoding($out, 'ISO-8859-1', 'UTF-8');
}Schön ist anders, aber zu mehr habe ich gerade keine Lust. Eigentlich sollte das automatisch passieren, denke ich, je nach gewähltem Output-Encoding. Muss ich da mal einen Bug Report auf machen oder ist das so eine spezielle Situation, dass das nur bei mir vorkommt...?
EDIT 16.3.2024, 17:36 Uhr: Nach ein bisschen Nachfragen im s9y-Forum habe ich das jetzt runterkondensiert auf einen einzeiler in der /include/functions.inc.php, Zeile 162:
if (LANG_CHARSET != "UTF-8") $out = mb_convert_encoding($out, LANG_CHARSET, 'UTF-8');Das patcht die function serendipity_strftime(), was sehr viel eleganter ist.