Fassung 1.4.4: Migrationen im Browser, und ein Fehlschlag sagt warum

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>

docs/UPDATE.md

@@ -81,6 +81,22 @@ Unberührt bleiben in jedem Fall `var/`, `.env` und `.env.local`. Scheitert das
 
 **Geprüft wird ohne Netz** (`tests/ArchiveUpdateTest.php`): eine Releaseseite im Speicher, echte Zip-Archive, echte Prüfsummen, echte Umbenennungen in einem Wegwerfverzeichnis. Ein Test hält zusätzlich die Ersetzungsliste gegen die Mitnahmeliste von `scripts/build-release.php`: Was neu ins Archiv kommt, muss beim Update auch ersetzt werden.
 
+## Der dritte Weg: von Hand über FTP
+
+Der Weg für den einen Fall, in dem die Karte im Bildschirm „System" noch nicht existiert: **das Update auf die Fassung, die sie mitbringt.** Eine Installation der Fassung 1.4.2 kennt sie nicht – sie muss einmal von Hand nachgezogen werden, danach gibt es den Knopf.
+
+1. **Sichern.** Verwaltung → System → „Sicherung anlegen". Zusätzlich per FTP `var/` und `.env` herunterladen. Migrationen sind nicht umkehrbar; der Rückweg ist die Sicherung.
+2. **Archiv holen und auspacken.** `kantsites-<fassung>.zip` von der Releaseseite, auf dem eigenen Rechner entpacken. Darin liegt ein Ordner `kantsites-<fassung>/`.
+3. **Wartungszustand einschalten.** Verwaltung → System → „Wartung". Sonst sieht ein Besucher währenddessen eine halb ersetzte Anwendung.
+4. **Diese Einträge hochladen und ersetzen:** `bin`, `config`, `migrations`, `src`, `templates`, `vendor`, `composer.json`, `composer.lock`, `migrations.php`, `cli-config.php`, `VERSION`. Verzeichnisse ersetzen, nicht hineinkopieren – eine Datei, die es in der neuen Fassung nicht mehr gibt, muss weg.
+5. **`public/` Datei für Datei** – und **`public/assets/fonts` und `public/assets/build` auslassen**. Dort liegen die hochgeladenen Schriften und das erzeugte Stylesheet-Bündel; beide gehören dem Betreiber und stehen in keinem Archiv.
+6. **Nicht anfassen:** `var/`, `.env`, `.env.local`. Dort stecken Inhalte, Medien und `APP_SECRET`.
+7. **`var/cache` vollständig löschen.** Sonst läuft die neue Fassung mit den Wegweisern der alten und antwortet mit 500, obwohl der Code richtig ist.
+8. **Migrationen ausführen.** Verwaltung → System → Karte „Migrationen stehen aus" → Knopf. Die Karte erscheint nur, wenn welche ausstehen. Wer eine Konsole hat, kann stattdessen `php vendor/bin/doctrine-migrations migrate --no-interaction` aufrufen.
+9. **Wartungszustand aus**, Startseite und Verwaltung einmal aufrufen, Fassungsnummer im Bildschirm „System" prüfen.
+
+Das ist einmalig: Ab 1.4.3 kennt jede Installation den Weg über das Archiv, und dann entfällt das alles. Dann steht im selben Bildschirm die Karte „Update aus dem Releasearchiv", und die Schritte 2 bis 8 erledigt sie selbst.
+
 ## Ein Release veröffentlichen
 
 `php scripts/build-release.php` baut auf einem Rechner mit Composer das Archiv – Anwendung plus `vendor/` ohne Entwicklungspakete – und schreibt die SHA-256-Summe in eine Kopie von `install.php`. Beides gehört anschließend an das Git-Release des passenden Tags: