SITE_ORIGIN alone decides whether the site is www or not: CanonicalHostSubscriber
sends the other spelling there with 301, cms:site:origin writes the setting, the
system screen shows it. The roles now match the role help (editor: drafts,
publisher: live content, admin: design, settings, users, system). The installer no
longer reopens on an unreachable database, the session cookie follows ADMIN_PATH,
percent-encoded credentials no longer break the container, consent only accepts
same-site decisions, JSON-LD is HTML-safe, own CSS stays in its block, plus the
editor, updater, download and public-output findings from the full review
(ADR 099, ADR 100).
Co-Authored-By: Claude Fable 5.1 <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>
kantarciandClaude Fable 5.1