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>
Arbeitspaket O. Der Teil, um den es geht, ist nicht das Sichern, sondern das
Zurueckspielen: eine Sicherungsfunktion, deren Wiederherstellung nie gelaufen
ist, ist eine Vermutung.
Die Datenbank wird nicht kopiert, sondern von SQLite ausgeschrieben (VACUUM
INTO). Ein copy() waehrend eines Schreibvorgangs ergibt eine Datei, die
vorhanden aussieht und sich am Tag der Wiederherstellung nicht oeffnen laesst.
Der Medienordner gehoert dazu - ohne die Dateien stellt die Sicherung eine
Website voller kaputter Bilder her. .env gehoert nicht dazu: darin steht
APP_SECRET, und eine Sicherung wird heruntergeladen und weitergereicht. Was
nicht drin ist, steht im Manifest.
Jede Sicherung traegt Zeitpunkt, Anlass, Fassung, Migrationsstand,
Inhaltszahlen und die SHA-256 der Datenbank. Die Uebersicht zeigt
"unversehrt" oder "Pruefsumme falsch" - eine Sicherung, von der man erst beim
Zurueckspielen erfaehrt, dass sie kaputt ist, waere schlimmer als keine.
Beim Zurueckspielen: neuere Fassung wird abgewiesen (mit --force geht es),
zuerst wird der aktuelle Stand gesichert, Wartungszustand an, Medien werden
ergaenzt statt ersetzt - eine Datei, die nach der Sicherung hochgeladen wurde,
bleibt liegen. Die Massnahme gegen Datenverlust darf nicht selbst welchen
verursachen. In der Verwaltung gibt es Liste und Anlegen-Knopf, aber kein
Zurueckspielen: ein Knopf, der die ganze Datenbank ersetzt, gehoert nicht
neben einen, der eine Seite speichert.
Nachgewiesen, zweimal: acht Tests gegen eine wegwerfbare Installation
(Sicherung, Seite und Bilddatei loeschen, zurueckspielen, beides wieder da) -
und von Hand auf der Entwicklungsinstallation mit einer eigens angelegten
Testseite: 5 Seiten, gesichert, geloescht (4), zurueckgespielt (5, Seite mit
ihrer Adresse wieder da), Testseite entfernt (4). Damit ist der aelteste
offene Punkt aus Paket I erledigt.
Ein Fall, den erst der Test zeigte: zwei Sicherungen in derselben Sekunde -
nicht akademisch, denn die Wiederherstellung legt selbst eine Sicherheitskopie
an. Der Name bekommt jetzt eine Nummer, statt dass die zweite scheitert.
Offen: MySQL (mysqldump fehlt) und ein Download ueber den Browser.
344 PHP-Tests / 1397 Assertions.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
kantarciandClaude Opus 5