Styx 4.3.2 und PHP 8.2.13

beats TEST blog

Mittwoch, 13. Dezember 2023

Styx 4.3.2 und PHP 8.2.13

Alle Plugins aktualisiert.
Trackback-URL für diesen Eintrag

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

  1. Beat Post author am :

    Nur als kleiner Hinweis (und damit es wieder einmal gesagt wurde): Auf beiden Servern (Hosttech & Manitu) gelange ich nach dem Klick auf "Klicken Sie hier um den eigentlichen Update-Prozess zu starten!" auf eine weisse Seite. Nach einen F5-Reload bin ich dann wieder am richtigen Ort.

  2. Ian Styx am :

    Kannst du denn dabei verfolgen wie der update ticker die Seite langsam auffüllt (also seine internen Funktionen durchläuft und dabei kontinuierlich Wasserstandsmeldungen abgibt) und derweilen ab und an automatisch weiter nach unten scrollt bis er schließlich am link "Klicken Sie hier, um den eigentlichen Serendipity Installer zu starten" auf dein abschließendes Kommando wartet? Oder ist das alles erst nach einer Weile des internen Tuns plötzlich da?

    Jenes Verhalten hat damit zu tun, dass manche Server keine flush Ausgaben "erlauben" oder "können", sie also immer erst das vollständige Ende eines Gesamtprozesses abwarten müssen bevor sie dessen Meldungen ausgeben können.

    🤓Aber das ist ja gar nicht dein Problem, oder ?!

    Der Link verweist auf den $serendipity['serendipityHTTPPath']. Ist der richtig, muss es auf die normale Frontend und damit "quasi" installer Seite fallen. Ich kann mir nur vorstellen, dass diese weiße Seite, die da einen F5 reload benötigt, nur auf den anwesenden Cache (der halt etwas zu lazy ist ) zurückzuführen ist. Wie ich dem begegnen kann ist unsicher... Vielleicht durch ein Abfangen des referers und dann konsequent ein doppeltes automatisches reload oder so... Ohne das am konkreten Verhalten zu testen ist das für mich eher schwer vorherzusagen. 🙄

  3. Beat Post author am :

    Auf dem Hosttech-Server sehe ich keine Wasserstandsanzeige. Da warte ich einfach, bis alles erledigt ist und die Seite komplett aufgebaut wird.

    Auf dem Manitu-Server sehe ich den aktuellen Fortschritt, bis alles soweit erledigt ist.

    In beiden Fällen sehe ich zum Schluss die komplette Seite, auf der unten der Link "Klicken Sie hier, um den eigentlichen Serendipity Installer zu starten" erscheint.

    Nach dem Klick auf den Link, werde ich sofort (in weniger als 1 sec.) auf die weisse Seite geworfen. Mit F5-Refresh sehe ich dann die Folgeseite.

  4. Ian Styx am :

    Aha.

    Das würde bestätigen dass Hosttech kein flush des Ausgabepuffers zuläßt und außerdem noch den "nginx"? cache nutzt.

    Warum das bei Manitu für letzteres ebenso wirkt kann vielleicht ebenfalls auf ein proxy-cache-artiges Gespinst zurückzuführen sein. Ist dir da was bekannt? Ansonsten kann ich mich nicht erinnern solche eine weiße Seite in diesem Zusammenhang je schon einmal selbst beobachtet zu haben... wiewohl Ersteres schon, zb bei Uberspace, wenn ich recht erinnere.

    Denn wie gesagt, es ist die Frontend URL des Blogs, aber eben im upgrade Modus...

  5. Ian Styx am :

    Denn wie gesagt, es ist die Frontend URL des Blogs, aber eben im upgrade Modus...

    Und das ja nur, wenn du den Wartungsmodus angestellt hast. Es ist also die 503 temporarily not available  Seite ... allerdings mit dem kleinen Unterschied, dass du durch sie hindurchstoßen kannst mit dem dort angegebenen link und der dich (wieder) auf die backend Startseite aber im Install-Modus führt, da, wo die einzelnen upgrade tasks auszuführen sind. Erst dessen submit bringt dich dann auf die Seite mit den zwei links für blog frontend oder blog backend, dem man dann brav ins Backend folgt, um dort noch weiter herumzustöbern und am Ende den Wartungsmodus wieder zu verlassen.

    Es ist also anzunehmender Weise die 503 Seite die dein F5 reload benötigt - oder ?!

  6. Beat Post author am :

    Und das ja nur, wenn du den Wartungsmodus angestellt hast.

    Öhm... Nein. Das mit dem Wartungsmodus mache ich so gut wie nie... 

  7. Ian Styx am :

    🙄Nun denn... dann ist es der automatische Umbieger per HTML header, wenn ich recht erinnere. Denn der Link vom autoupdate zielt definitiv auf das Frontend und ... ist dort kein Wartungs-STOP-modus gesetzt ... verbiegt sich an dieser Stelle wieder in das Backend in den dortigen Install (task) Modus.

    Das muss ich mir wohl nochmal ansehen ob es da nicht etwas expliziteres gibt, wenn ein Browser sich weigert kräftig durchzuladen.

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

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

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

  11. Ian Styx am :

    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.

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

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

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

  15. 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? 👻

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

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

  18. Ian Styx am :

    Ping! Ich habe dir was hinterlassen.😉

  19. Beat Post author am :

    👍 Funktioniert! ✔ Vielen Dank!

    Und ja, ich habe beim auto-update-Test vorher das zip von V4.3.2 gelöscht.

  20. Ian Styx am :

    Super! Ich habe es für nächstes Styx 4.3.3 oder 4.4 committet. 😊

  21. Ian Styx am :

    Ping. (Nachtrag.)

  22. Beat Post author am :

    Habe das neuste serendipity_plugin_history.php aufgespielt, das history_daylist.dat gelöscht und neu generiert. Sieht gut aus. 👍

  23. Ian Styx am :

    Ich habe es mal Plugin mit Langzeitbeobachtung betitelt. Wir werden aus diesem Modus wohl nicht herauskommen... 😁

  24. Beat Post author am :

    Mal sehen, was am 29.02. und 01.03. angezeigt wird...😏

  25. Ian Styx am :

    Gute Frage! ( rumspiel... )

    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?

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

  27. 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... 😉?

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

  29. Ian Styx am :

    Ping! ( Simsalabim. 😊)

  30. Beat Post author am :

    O.K. Nächste Version des serendipity_plugin_history.php aufgespielt. Der 29.02.2024 kann kommen! 😉

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

  32. Beat Post author am :

    O.K. Habe hier und auf beatsblog.ch die neuen Dateien aufgespielt. 👍

  33. Ian Styx am :

    Ich hoffe das war meinerseits nicht missverständlich ausgedrückt, denn das finetuning etc betraf grundlegend nur Daten mit gewisser Entfernung, wären also wohl nicht vor nächstem Update aufgetreten ...😊

  34. Beat Post author am :

    Kein Thema. Ich habe es schon richtig verstanden. Hatte einfach Zeit und Lust um die Änderungen aufzuspielen. 😉👋

  35. Beat Post author am :

    Die Spannung steigt...

  36. Ian Styx am :

    😊 Ja... denn die 4.4 ist nah... sehr nah!
    Hoffe alles ist gut soweit und fließt verstopfungsfrei in seinem vorgegebenen Keise!

  37. Ian Styx am :

    👍nur echte twentyniners! 😉

  38. Beat Post author am :

    TOP! :applaus:

  39. Beat Post author am :

    Auch die heutige Anzeige, 01.03. stimmt. Nun scheint das History-Plugin wirklich perfekt zu funktionieren. Egal ob Schaltjahr oder nicht. 👍

Kommentar schreiben

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