Vorausschicken muss ich, dass ich trotzdem das geschilderte Verhalten nie gehabt habe und auch in meinen tests nicht zu Gesicht bekomme....
Ich habe ja den schrecklichen Verdacht dass das der eigentliche Verursacher ist... bzw sein könnte... und dieser Link und Weg auf das frontend per se unnötig ist. Denn wenn die autoupdate Seite durchgelaufen ist wird automatisch die Folgeseite "Backend Installer" für die upgrade task geladen - bzw ist es diese schon von Anfang an, nur mit vorgeschalteten autoupdate Plugin Ausgaben. Ein (Zwischen-) Umweg über das Frontend ist gar nicht vorgesehen, außer für den Nicht-Wartungsmodus-Fall ganz am Ende als Abschluss des Upgrades.
Das ist alles schon so lange her.... jedenfalls, irgendwann schien es nötig dieser autoupdate Seite einen vorläufigen Halt mit diesem "end-" link zu geben, damit man wenigstens die Chance hatte die Ausgaben zu lesen und zu verstehen, auch wenn es einen zusätzlichen Link (Eingriff) für den Admin bedeutet. Auch für eventuelle Fehlermeldungen und ihre Behandlung war dies nötig. Sonst wäre die Seite einfach zur install tasks Prozedur Seite durchgeladen worden. Das autoupdate, das ja eigentlich mehr ein automatisch geladenes Überstülpungs-Update ist, läuft ja so schnell, dass es schon viel Erfahrung braucht, um überhaupt lesend mitzuhalten.
Man kann das Verhalten des durchladens sogar heute noch provozieren, in dem man statt auf den link einfach auf F5 drückt oder sich den Quellcode der Seite anzeigen lassen möchte; der zeigt nämlich schon den zweiten Teil, sobald alles erfolgreich geschehen ist. Ich würde also fast sagen, dass der Link eigentlich auf das Backend statt auf das Frontend zeigen müsste, habe aber gerade Sorge, dass ich da was übersehen habe, dass diesen Umweg dann doch nötig machte.... 🤔
Ich habe das jetzt mal in autoupdate v.2.0.1 committet. Wenn du es beim auffälligen Server mal testweise ausprobieren möchtest, ob damit die weiße Erscheinung weg ist und sonst keine weiteren Probleme zu erkennen sind, müssten die beiden config(+_local) Dateien auf Styx 4.3.1 zurückgesetzt werden.
Ansonsten wünsche ich schöne Festtage mit leckeren Zutaten! 🎄Wohl bekomms! 😊
Beat Post author am |
Top! 👍 Keine White-Page mehr! Weder bei Hosttech noch bei Manitu.
Was mir aufgefallen ist, dass früher die White-Page auf die Frontpage des Blogs zeigte und nun wird man (richtig) zur Backend-Admin-Page weitergeleitet.
und sonst keine weiteren Probleme zu erkennen sind
Das kann ich nicht beantworten, da ich hier https://www.styx.dokumenzi.ch/ (Hosttech) und auch hier https://styx.beatsblog.ch/ (Manitu) nicht wirklich aktiv am testen bin. Auf den ersten Blick sieht alles wie immer und in Ordnung aus.
Was mir aufgefallen ist, dass früher die White-Page auf die Frontpage des Blogs zeigte und nun wird man (richtig) zur Backend-Admin-Page weitergeleitet.
Super. Danke.
Ja, denn wie schon beschrieben, war der kurzzeitige Umweg über das Frontend ziemlich unnötig und die Ausgabe brauchte nur den kleinen Stubs um auf sich selbst bzw das Backend für den weiteren Fortgang zu zeigen.
Beat Post author am |
Lieber Herr Styx
Vielen Dank für die tolle Weiterentwicklung der Styx-Edition im ablaufenden Jahr. Ich weiss Ihre Arbeit wirklich sehr zu schätzen! 👍
Ich wünsche Ihnen einen einen guten Rutsch ins neue Jahr! 🚀 🎆 🎇 Bleiben Sie gesund und innovativ!
Ich wünsche Ihnen, nebst Gespielin (🐈) und Gemahlin einen ebensolchen.✨
Der niederschwellige Druck funktioniert ja allerliebst und produziert doch allerlei lesenswerte Berichte aus Ihrem Leben. Leider gilt das nicht für Ihre Leser, denn mit den Leser-Kommentaren ist es ja eher flau... Was können wir dagegen tun?
Ich kann den ja nicht auch noch bespielen... und halte meine gelegentlichen Einwürfe daher streng reglementiert.
🥌
Obwohl, einen hätte ich.... getsol.us (meine Lieblingsdistribution). Und bald erscheint die 4.5 Version und ich würde sagen da lohnt vielleicht das warten. 😄
AHOI
Beat Post author am |
Oh! Das history-Plugin hat den Sprung ins neue Jahr nicht sauber hingekriegt. Es werden vorwiegend Beiträge des 31.12. und wenige 01.01. angezaigt.
Das Löschen der history_daylist.dat hat leider keine Verbesserung gebracht.
Es ist mal wieder der running Gag, das Schaltjahr. 🤬Ich finde durchaus einen workaround für heute, aber ... es scheint wurmstichig allemal wenn ich weiter ins Jahr vorschaue. Das Problem ist, dass ich mich auf die Daten nicht verlassen kann um dem Problem grundlegend auf den Grund zu gehen, denn immer wieder purzeln einzelne 23.59 Uhr Einträge hinein, die die Verlässlichkeit wegen dem möglichen Offset verunsichern. Jage ich also Gespenster oder Reales? 👻
Beat Post author am |
Ein Workaround via DB-Tabelle-Export-Ersetzen-Import geht vermutlich auch nicht, da meines Wissens die Veröffentlichungszeiten der entries nicht in hh:mm sondern in einem anderen Zahlensalat gespeichert sind. Ersetze 23:59 durch 22:59 wird deshalb wohl nicht gehen.
Ich warte mal ab, denn vielleicht sieht die History-Welt morgen schon wieder anders aus. 😉
Sie sind als UNIX Timestamp - als der Anzahl Sekunden seit 01.01.1970 gespeichert und das als UTC time, wo dann der offset dazu bzw abkommt und berechnet wird. Wir hatten ja den offset Schlamassel mit dem historischen und aktuellem Server offset(s) und den daraus resultierenden falschen Berechnungen von deinen Einträgen zwischen 23:00 und 23:59, welches wir dann korrigiert hatten. (Ob das nun hier (Server) und auch da (Server) und/oder auch noch bei mir (mit meinen test Daten) ergibt allemal so viel Unsicherheiten, dass mir der Kopf raucht.) Ich rechne ja mit plus 366 bzw plus 365 Tagen je nach Schaltjahr über einen range von X Jahren um die richtigen timestamp ranges zwischen 00.00 und 23:59 für den entries fetch zu berechnen für all diese Tage.
Also irgendwas mache ich nicht richtig, mit der Unsicherheit über die Verlässlichkeit der zugrunde liegenden Daten.
Das kann ich dir jetzt schon sagen (mit älterem Datensatz) :
2024-02-29 bool(false) = 365 Tage
Fr., 01.03.2019 23:36 Tag 7 - nach Gambassi Terme
Do., 01.03.2018 14:06 Saisonstart?
Mo., 29.02.2016 21:46 mal etwas anderes
Sa., 01.03.2014 23:59 Fehlstart?
Mi., 29.02.2012 11:46 Geduldspiel
Mo., 01.03.2010 23:59 Hammer-Februar!
So., 01.03.2009 20:31 ZüriCarneval
Mi., 01.03.2006 22:29 von Radtouren träumen
Mi., 01.03.2006 20:13 die Sache mit den Umlauten
Mi., 01.03.2006 09:29 NEU: Domaine-Registrierung [...]
2024-03-01 bool(true) = 366 Tage
Fr., 01.03.2019 23:36 Tag 7 - nach Gambassi Terme
Do., 01.03.2018 14:06 Saisonstart?
Sa., 01.03.2014 23:59 Fehlstart?
Do., 01.03.2012 23:38 Strassenzulassung
Mo., 01.03.2010 23:59 Hammer-Februar!
So., 01.03.2009 20:31 ZüriCarneval
Sa., 01.03.2008 22:36 Februar-März
Sa., 01.03.2008 22:05 Emma sagt nein
Mi., 01.03.2006 22:29 von Radtouren träumen
Mi., 01.03.2006 20:13 die Sache mit den Umlauten
Mi., 01.03.2006 09:29 NEU: Domaine-Registrierung [...]
Es ist natürlich auch die Frage was man da (29. Feb,) eigentlich erwartet..., denn die Schaltjahre ergeben natürlich den 29. und die anderen den 01.
Schaltjahre sind 2024, 2020, 2016, 2012, 2008.
Wie würdest du das sehen?
Beat Post author am |
Es ist natürlich auch die Frage was man da (29. Feb,) eigentlich erwartet..., denn die Schaltjahre ergeben natürlich den 29. und die anderen den 01.
In der Theorie würde ich sagen, dass der 29.02. eben genau der 29.02. ist und somit nur Beiträge aus den entsprechenden Schaltjahren angezeigt werden. Doch das würde wohl zu viel Aufwand für einen einzelnen Tag -der nur alle vier Jahre mal auftaucht- bedeuten. Ist wohl die Mühe nicht wert.
Ich kann sehr gut mit der obigen Anzeige für den 29.02. leben, wenn danach am 01.03. die Anzeige wieder stimmt.
Es ist mehr die Frage ob explizit oder nicht, denn stimmen tun m.E. ja auch die 01.03 Anzeigen, denn sie sind in den normalen Jahren eben genau 1, 2, 3, x Jahre zurück und daher nicht unbedingt falsch. Anzunehmenderweise sind auch generell Blogbeiträge am 29 in Schaltjahren höchstwahrscheinlich weniger als 1. März Einträge zu finden... schon allein quantitativ, so dass es anzeigenmäßig wohl eher vorkommt, dass es am 29. zu leeren Anzeigen kommt. ( Außer bei Herrn Menzi. Und das ist toll! 😄)
Die 01.03. Einträge am 29. Feb. zu unterdrücken bzw herauszurechnen ist aber kein Ding. Es wird ja außerdem gecached, aber spielt selbst ohne keine wesentliche Rolle für die Routinen.
Also, wie belieben zu haben... 😉?
Beat Post author am |
Also wenn ich wünschen kann, so nehme ich Tor 2! 😁 denn der 29.02. ist eben nicht der 01.03. 😉
Nur zur Info... Ich habe noch ein paar Tage daran weitergebastelt um den test-case Ungereimheiten auf die Spur zu kommen. Deshalb sind noch allerlei Verbesserungen entstanden. ( Vorher konnte ich mich Anderem nicht zuwenden...🙃)
Ich glaube, dass diese Verbesserungen dich im aktuellen Schaltjahr nicht treffen werden, bevor das nächste Styx mit dem letzten Stand released wird. Solltest du trotzdem herumspielen wollen, müsstest du allerdings diesmal auch die Sprachdateien [UTF-8/de] bzw [en] erneuern.
Ian Styx am |
Vorausschicken muss ich, dass ich trotzdem das geschilderte Verhalten nie gehabt habe und auch in meinen tests nicht zu Gesicht bekomme....
Ich habe ja den schrecklichen Verdacht dass das der eigentliche Verursacher ist... bzw sein könnte... und dieser Link und Weg auf das frontend per se unnötig ist. Denn wenn die autoupdate Seite durchgelaufen ist wird automatisch die Folgeseite "Backend Installer" für die upgrade task geladen - bzw ist es diese schon von Anfang an, nur mit vorgeschalteten autoupdate Plugin Ausgaben. Ein (Zwischen-) Umweg über das Frontend ist gar nicht vorgesehen, außer für den Nicht-Wartungsmodus-Fall ganz am Ende als Abschluss des Upgrades.
Das ist alles schon so lange her.... jedenfalls, irgendwann schien es nötig dieser autoupdate Seite einen vorläufigen Halt mit diesem "end-" link zu geben, damit man wenigstens die Chance hatte die Ausgaben zu lesen und zu verstehen, auch wenn es einen zusätzlichen Link (Eingriff) für den Admin bedeutet. Auch für eventuelle Fehlermeldungen und ihre Behandlung war dies nötig. Sonst wäre die Seite einfach zur install tasks Prozedur Seite durchgeladen worden. Das autoupdate, das ja eigentlich mehr ein automatisch geladenes Überstülpungs-Update ist, läuft ja so schnell, dass es schon viel Erfahrung braucht, um überhaupt lesend mitzuhalten.
Man kann das Verhalten des durchladens sogar heute noch provozieren, in dem man statt auf den link einfach auf F5 drückt oder sich den Quellcode der Seite anzeigen lassen möchte; der zeigt nämlich schon den zweiten Teil, sobald alles erfolgreich geschehen ist. Ich würde also fast sagen, dass der Link eigentlich auf das Backend statt auf das Frontend zeigen müsste, habe aber gerade Sorge, dass ich da was übersehen habe, dass diesen Umweg dann doch nötig machte.... 🤔
Ian Styx am |
Ich habe das jetzt mal in autoupdate v.2.0.1 committet. Wenn du es beim auffälligen Server mal testweise ausprobieren möchtest, ob damit die weiße Erscheinung weg ist und sonst keine weiteren Probleme zu erkennen sind, müssten die beiden config(+_local) Dateien auf Styx 4.3.1 zurückgesetzt werden.
Ansonsten wünsche ich schöne Festtage mit leckeren Zutaten! 🎄Wohl bekomms! 😊
Beat Post author am |
Top! 👍 Keine White-Page mehr! Weder bei Hosttech noch bei Manitu.
Was mir aufgefallen ist, dass früher die White-Page auf die Frontpage des Blogs zeigte und nun wird man (richtig) zur Backend-Admin-Page weitergeleitet.
Das kann ich nicht beantworten, da ich hier https://www.styx.dokumenzi.ch/ (Hosttech) und auch hier https://styx.beatsblog.ch/ (Manitu) nicht wirklich aktiv am testen bin. Auf den ersten Blick sieht alles wie immer und in Ordnung aus.
Ian Styx am |
Super. Danke.
Ja, denn wie schon beschrieben, war der kurzzeitige Umweg über das Frontend ziemlich unnötig und die Ausgabe brauchte nur den kleinen Stubs um auf sich selbst bzw das Backend für den weiteren Fortgang zu zeigen.
Beat Post author am |
Lieber Herr Styx
Vielen Dank für die tolle Weiterentwicklung der Styx-Edition im ablaufenden Jahr. Ich weiss Ihre Arbeit wirklich sehr zu schätzen! 👍
Ich wünsche Ihnen einen einen guten Rutsch ins neue Jahr! 🚀 🎆 🎇 Bleiben Sie gesund und innovativ!
Liebe Grüsse aus der Schweiz
Beat Menzi
Ian Styx am |
Dass freut mich sehr, ...lieber Herr Menzi! 🙂
Ich wünsche Ihnen, nebst Gespielin (🐈) und Gemahlin einen ebensolchen.✨
Der niederschwellige Druck funktioniert ja allerliebst und produziert doch allerlei lesenswerte Berichte aus Ihrem Leben. Leider gilt das nicht für Ihre Leser, denn mit den Leser-Kommentaren ist es ja eher flau... Was können wir dagegen tun?
Ich kann den ja nicht auch noch bespielen... und halte meine gelegentlichen Einwürfe daher streng reglementiert.
🥌
Obwohl, einen hätte ich.... getsol.us (meine Lieblingsdistribution). Und bald erscheint die 4.5 Version und ich würde sagen da lohnt vielleicht das warten. 😄
AHOI
Beat Post author am |
Oh! Das history-Plugin hat den Sprung ins neue Jahr nicht sauber hingekriegt. Es werden vorwiegend Beiträge des 31.12. und wenige 01.01. angezaigt.
Das Löschen der history_daylist.dat hat leider keine Verbesserung gebracht.
Ian Styx am |
Oh du fröhliche .... Schönes Neues Jahr!
Es ist mal wieder der running Gag, das Schaltjahr. 🤬Ich finde durchaus einen workaround für heute, aber ... es scheint wurmstichig allemal wenn ich weiter ins Jahr vorschaue. Das Problem ist, dass ich mich auf die Daten nicht verlassen kann um dem Problem grundlegend auf den Grund zu gehen, denn immer wieder purzeln einzelne 23.59 Uhr Einträge hinein, die die Verlässlichkeit wegen dem möglichen Offset verunsichern. Jage ich also Gespenster oder Reales? 👻
Beat Post author am |
Ein Workaround via DB-Tabelle-Export-Ersetzen-Import geht vermutlich auch nicht, da meines Wissens die Veröffentlichungszeiten der entries nicht in hh:mm sondern in einem anderen Zahlensalat gespeichert sind. Ersetze 23:59 durch 22:59 wird deshalb wohl nicht gehen.
Ich warte mal ab, denn vielleicht sieht die History-Welt morgen schon wieder anders aus. 😉
Ian Styx am |
Sie sind als UNIX Timestamp - als der Anzahl Sekunden seit 01.01.1970 gespeichert und das als UTC time, wo dann der offset dazu bzw abkommt und berechnet wird. Wir hatten ja den offset Schlamassel mit dem historischen und aktuellem Server offset(s) und den daraus resultierenden falschen Berechnungen von deinen Einträgen zwischen 23:00 und 23:59, welches wir dann korrigiert hatten. (Ob das nun hier (Server) und auch da (Server) und/oder auch noch bei mir (mit meinen test Daten) ergibt allemal so viel Unsicherheiten, dass mir der Kopf raucht.) Ich rechne ja mit plus 366 bzw plus 365 Tagen je nach Schaltjahr über einen range von X Jahren um die richtigen timestamp ranges zwischen 00.00 und 23:59 für den entries fetch zu berechnen für all diese Tage.
Also irgendwas mache ich nicht richtig, mit der Unsicherheit über die Verlässlichkeit der zugrunde liegenden Daten.
Ian Styx am |
Ping! Ich habe dir was hinterlassen.😉
Beat Post author am |
👍 Funktioniert! ✔ Vielen Dank!
Und ja, ich habe beim auto-update-Test vorher das zip von V4.3.2 gelöscht.
Ian Styx am |
Super! Ich habe es für nächstes Styx 4.3.3 oder 4.4 committet. 😊
Ian Styx am |
Ping. (Nachtrag.)
Beat Post author am |
Habe das neuste serendipity_plugin_history.php aufgespielt, das history_daylist.dat gelöscht und neu generiert. Sieht gut aus. 👍
Ian Styx am |
Ich habe es mal Plugin mit Langzeitbeobachtung betitelt. Wir werden aus diesem Modus wohl nicht herauskommen... 😁
Beat Post author am |
Mal sehen, was am 29.02. und 01.03. angezeigt wird...😏
Ian Styx am |
Gute Frage! ( rumspiel... )
Das kann ich dir jetzt schon sagen (mit älterem Datensatz) :
Es ist natürlich auch die Frage was man da (29. Feb,) eigentlich erwartet..., denn die Schaltjahre ergeben natürlich den 29. und die anderen den 01.
Schaltjahre sind 2024, 2020, 2016, 2012, 2008.
Wie würdest du das sehen?
Beat Post author am |
In der Theorie würde ich sagen, dass der 29.02. eben genau der 29.02. ist und somit nur Beiträge aus den entsprechenden Schaltjahren angezeigt werden. Doch das würde wohl zu viel Aufwand für einen einzelnen Tag -der nur alle vier Jahre mal auftaucht- bedeuten. Ist wohl die Mühe nicht wert.
Ich kann sehr gut mit der obigen Anzeige für den 29.02. leben, wenn danach am 01.03. die Anzeige wieder stimmt.
Ian Styx am |
Es ist mehr die Frage ob explizit oder nicht, denn stimmen tun m.E. ja auch die 01.03 Anzeigen, denn sie sind in den normalen Jahren eben genau 1, 2, 3, x Jahre zurück und daher nicht unbedingt falsch. Anzunehmenderweise sind auch generell Blogbeiträge am 29 in Schaltjahren höchstwahrscheinlich weniger als 1. März Einträge zu finden... schon allein quantitativ, so dass es anzeigenmäßig wohl eher vorkommt, dass es am 29. zu leeren Anzeigen kommt. ( Außer bei Herrn Menzi. Und das ist toll! 😄)
Die 01.03. Einträge am 29. Feb. zu unterdrücken bzw herauszurechnen ist aber kein Ding. Es wird ja außerdem gecached, aber spielt selbst ohne keine wesentliche Rolle für die Routinen.
Also, wie belieben zu haben... 😉?
Beat Post author am |
Also wenn ich wünschen kann, so nehme ich Tor 2! 😁 denn der 29.02. ist eben nicht der 01.03. 😉
Ian Styx am |
Ping! ( Simsalabim. 😊)
Beat Post author am |
O.K. Nächste Version des serendipity_plugin_history.php aufgespielt. Der 29.02.2024 kann kommen! 😉
Ian Styx am |
Nur zur Info... Ich habe noch ein paar Tage daran weitergebastelt um den test-case Ungereimheiten auf die Spur zu kommen. Deshalb sind noch allerlei Verbesserungen entstanden. ( Vorher konnte ich mich Anderem nicht zuwenden...🙃)
Ich glaube, dass diese Verbesserungen dich im aktuellen Schaltjahr nicht treffen werden, bevor das nächste Styx mit dem letzten Stand released wird. Solltest du trotzdem herumspielen wollen, müsstest du allerdings diesmal auch die Sprachdateien [UTF-8/de] bzw [en] erneuern.