Kommentare von

Doch, doch. Alles gut! 😊

Es ist so vorgesehen, dass du dich selbst dort umsehen kannst, und alles auf Fehlerfreiheit beliebig testen kannst, da du ja eingeloggt bist. Auch wenn es ein neues Tab ist. Hättest du zur Überprüfung aber einen anderen und unabhängigen Browser genommen wäre alles dicht gewesen.

Und das im wahrsten Sinne des Wortes..., oder?! 😉

Im dark mode ... 😁 unter bestimmten Vorausssetzungen.

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

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

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