sufw-webseite-terminplanung/development-system/database

Versionierter Contao-Seitenzustand

contao-baseline.sql ist der versionierte Ausgangszustand für Theme, Layout, Seiten, Artikel, Inhaltselemente und später auch Formulare. Er ist für eine frische Contao-Datenbank bestimmt und enthält keine Benutzer, Passworthashes, Sitzungen, Logs, Cache-Daten oder Zugangsdaten.

Nach der Umstellung auf Contao 4.13.58 ist der mitgelieferte Seed absichtlich leer. Nach dem Anlegen der ersten Seiten im Contao-Backend erzeugt Export-ContaoBaseline.ps1 den ersten versionierten Inhaltsstand.

Nach einer redaktionellen Änderung exportieren

cd development-system
.\scripts\Export-ContaoBaseline.ps1
git diff -- database/contao-baseline.sql

Bei einer vorhandenen Datei fragt das Skript vor dem Überschreiben nach. Für einen bewusst nicht-interaktiven Export, z. B. in einer Automatisierung, -Force ergänzen. Den Diff vor dem Commit prüfen. Die Exportdatei enthält keine tl_user-Daten.

In eine frische Datenbank importieren

Nach contao-setup und contao:migrate:

cd development-system
.\scripts\Import-ContaoBaseline.ps1
docker compose exec app vendor/bin/contao-console contao:user:create --admin

Der Import bricht ab, wenn die versionierten Contao-Tabellen bereits Inhalte enthalten. Das verhindert ein versehentliches Überschreiben. Nur für ein bewusstes Zurücksetzen auf den Git-Stand ist Folgendes vorgesehen:

.\scripts\Import-ContaoBaseline.ps1 -ReplaceExisting

-ReplaceExisting löscht ausschließlich Theme-, Layout-, Modul-, Seiten-, Artikel-, Inhaltselement- und Formulardaten. Benutzerkonten bleiben erhalten.

Medien

Medien gehören als Dateien nach development-system/files/ und werden in Git eingecheckt. Sobald Contao-Medien verwendet werden, muss der Seed zusätzlich die Metadaten aus tl_files enthalten. Das ist absichtlich noch nicht automatisiert, weil die aktuelle Datenbank nur Verweise auf nicht versionierte lokale Dateien enthält.

Terminbuchungs-Migrationen

Die Terminbuchung verwendet absichtlich keine Contao-Tabellen. Ihre separat versionierten SQL-Migrationen liegen unter database/migrations/. Jede Datei ist eigenständig und idempotent; sie kann deshalb auch später einzeln auf dem Produktivsystem ausgeführt werden.

Lokal werden alle Migrationen in Dateireihenfolge ausgeführt mit:

.\scripts\Invoke-BookingMigrations.ps1

Für ein Produktivsystem wird die jeweilige Datei mit einem dort berechtigten MariaDB-/MySQL-Client ausgeführt. Zugangsdaten gehören dabei in die Betriebskonfiguration und niemals in die SQL-Datei oder das Repository. Die erste Migration erstellt sufw_booking_events und sufw_booking_registrations sowie neun ungefährliche Demo-Termine für beide Instanzen. 002_booking_workflow.sql ergänzt Bestätigungstoken, den später entfernten Test-Mailausgang und pro Projekt einen beim Import zufällig erzeugten, widerrufbaren ICS-Feed-Token. 003_booking_demo_data.sql legt zusätzlich bestätigte Demo-Teilnahmen an und hält Beispieltermine jeweils einen Monat in der Vergangenheit und Zukunft. Diese letzte Datei ist ausschließlich für die lokale Entwicklungs- und Testdatenbank bestimmt und darf nicht auf dem Produktivsystem ausgeführt werden. 004_booking_contact_phones.sql ergänzt die Telefonnummer der Ansprechperson und ersetzt die Kontakte der stabilen Demo-Termine durch Carina Hollederer und Sarah van den Heuvel. 005_booking_demo_july_august.sql ergänzt ausschließlich lokal weitere bestätigte Demo-Termine und -Teilnahmen für Juli und August. 006_remove_booking_outbox.sql entfernt den nicht mehr verwendeten Test-Mailausgang; Buchungsnachrichten werden direkt an das Server-Sendmail übergeben.