Zwei Nachtraege zu 1.4.5, beide aus der Generalprobe.
- Jeder Schritt des Archiv-Updaters geht sofort nach var/updates.log,
waehrend des Laufs und nicht am Ende. Auf Umuts Hosting war die
Ergebnisseite tot, und damit war auch verloren, was der Updater
berichtet hatte. Genau so wurde der naechste Fehlschlag dann doch
lesbar: "bin liess sich nicht beiseitelegen - der alte Stand wurde
zurueckgeschoben" (ein Windows-Artefakt der Testumgebung, und
zugleich der Beweis, dass der Rueckweg funktioniert).
- Die Ergebnisseite versteht auch die Schreibweise bis 1.4.4. Das ist
kein Nachgeben, sondern noetig: Beim Update schreibt der alte Code
die Schritte in die Sitzung und der neue zeigt sie an. Eine Fassung,
die nur die neue Schreibweise kennt, koennte das Update, das sie
selbst einspielt, nicht berichten.
Nachgestellt mit einer echten Installation aus dem Releasearchiv, die
ueber die Oberflaeche aktualisiert wurde - nicht ueber die Konsole.
Geprueft: 434 Tests auf PHP 8.2 und 8.4.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Alle drei von Umut auf seinem Hosting gefunden, keiner davon auf
meinem Rechner sichtbar.
- Der Updateknopf endete mit 500. Das Update lief vollstaendig durch -
alle neun Schritte, Dateien getauscht, var/ und .env unberuehrt -,
aber die Ergebnisseite starb daran: der Updater ueber Git nennt
einen Schritt "step", der ueber das Archiv nannte ihn "label", beide
legen ihn unter demselben Sitzungsschluessel ab, und die Vorlage
liest "step". Damit war auch der zweite Knopf unerreichbar. Zehn
Tests prueften das Rueckgabe-Array, keiner die Seite, die es
anzeigt; der neue Test rendert sie (ADR 071).
- Die Verwaltung zeigte Git-Fehler auf einer Installation ohne Git.
"git ist installiert" und "das hier ist eine Arbeitskopie" waren
derselbe Schalter; auf dem Hosting ist Git vorhanden, die
Installation kam aber aus dem Archiv. Dort stand "fatal: Not a git
repository" an der Stelle der Fassungsnummer. Ohne Arbeitskopie
verschwinden die Git-Karten jetzt (ADR 072).
- "Sicherung anlegen" endete mit 500: VACUUM INTO gibt es erst seit
SQLite 3.27, das Hosting hat eine aeltere Fassung - alt genug fuer
die Installation, zu alt fuer die Sicherung. Bei aelteren wird jetzt
unter einer Schreibsperre kopiert, und der Knopf faengt jeden Fehler
ab statt mit einer 500-Seite zu enden (ADR 072).
Nachgestellt wurde das mit einer echten 1.4.3-Installation aus dem
Releasearchiv, eigener Datenbank, eigenem Port. Der Archiv-Updater
laeuft dort vollstaendig durch: 1.4.3 -> 1.4.4, neun Schritte, var/
und .env unberuehrt.
Geprueft: 433 Tests auf PHP 8.2 und 8.4, Editor-Browsertest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Zwei Luecken, die erst das Veroeffentlichen von 1.4.3 gezeigt hat.
- Es gab keinen Weg, ausstehende Migrationen im Browser auszufuehren.
Wer die Dateien per FTP hochlaedt - und das muss genau einmal jeder
tun, dessen Installation die Updatekarte noch nicht kennt -, hatte
danach neuen Code und eine alte Datenbank, und dafuer nur die
Konsole. Also genau das, was auf geteiltem Hosting fehlt. Der
Bildschirm "System" zeigt jetzt eine Karte, sobald etwas aussteht,
nennt die Namen und fuehrt sie auf Knopfdruck aus.
- "Die Releaseseite antwortet nicht" waren drei Ursachen in einem
Satz. Beim Gegenpruefen des frischen Releases holte der Updater von
hier gar nichts - nicht weil die Leitung zu waere, sondern weil
diesem PHP der Zertifikatsspeicher fehlt. Auf einem Webhosting ist
das der haeufigste Grund und der einzige, den man in einer Minute
behebt; er steht jetzt in der Meldung. Bei genau diesem Fehler wird
zusaetzlich der Weg ueber den Dateizeiger versucht - damit
funktioniert der Abruf auf diesem Rechner. Abgeschaltet wird die
Pruefung nicht: ein Update ohne Zertifikatspruefung koennte
unterwegs ausgetauscht worden sein.
Dazu der manuelle Weg Schritt fuer Schritt in docs/UPDATE.md und ein
Test, der beides festhaelt: dass die Karte auffaellt und dass nur ein
angemeldeter Administrator mit gueltigem Formular migrieren kann.
Geprueft: 431 Tests auf PHP 8.2 und 8.4, Editor-, Browser- und
Linkpruefung, Editor-Modelltests.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vier Wuensche und ein Fund beim Nachmessen.
- Farbwaehler im Designbereich. Das Textfeld bleibt massgeblich, damit
"@akzent" ein Verweis auf die Palette bleibt und nicht beim ersten
Klick zu einem festen Hexwert erstarrt (ADR 066).
- Die Verwaltung auf dem Telefon: das Menue klappt unter 760 px zu und
nennt den Bereich, in dem man steht; Ziele 44 px, kein Skript.
- Eigene SVG-Symbole statt Unicode-Zeichen - ein Telefon ersetzt die
sonst durch Emoji in fremdem Stil. Zwei Eintraege trugen dabei
denselben Pfad; ein Test findet beides (ADR 067).
- Update aus dem Releasearchiv: der Weg fuer Installationen ohne Git.
Zwei Schritte, weil ein Prozess, der sich selbst ausgetauscht hat,
mit dem alten Code weiterarbeitet. var/, .env, hochgeladene
Schriften und das erzeugte Buendel bleiben unberuehrt; public/ wird
dazu Datei fuer Datei zusammengefuehrt. Geprueft ohne Netz gegen
eine Releaseseite im Speicher (ADR 068).
Beim Nachmessen der echten Startseite statt einer Testseite: das
groesste Element ueber der Falz ist dort kein <img>, sondern der
Hintergrund des ersten Abschnitts - und der steht nur im Stylesheet.
Drei Vorabverweise mit denselben Geraetegrenzen wie der Compiler holen
genau die Variante, die die Regel auch nimmt. LCP 1,3 s -> 1,1 s.
Dabei gefunden: dasselbe Bild wurde je Geraeteregel neu abgefragt -
Startseite 19 -> 15 Abfragen (ADR 069).
Geprueft: 428 Tests auf PHP 8.2 und 8.4, Editor-, Browser- und
Linkpruefung, Lighthouse auf drei echten Seiten (alles ausser der
Leistung der Startseite 100).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
kantarci
