Update-Manager

Der Update-Manager ist die zentrale Anlaufstelle fuer drei Aufgaben: Datenbank-Migrationen ausfuehren, System-Updates einspielen und Daten von einer Staging-Instanz auf ein Live-Deployment-Ziel schieben. Alle drei sind destruktiv — lies den passenden Abschnitt, bevor du auf Installieren oder Bereitstellen klickst.

Oeffne Einstellungen → Update. Der Screen hat drei Sektionen untereinander.

Systemstatus

Die obere Sektion zeigt auf einen Blick:

Karte	Bedeutung
Installierte Version	Die Systemversion aus config.php.
Ausstehende Migrationen	Anzahl noch nicht eingespielter SQL-Migrationen.
PHP-Version	PHP-Version des Webservers.
Letzte Migration	Dateiname + Zeitstempel der letzten Migration.

Ist Ausstehende Migrationen groesser null, erscheint Migrationen ausführen im Updates-Header.

1. Migrationen ausfuehren

Migrationen sind nummerierte SQL-Skripte (001_*.sql, 002_*.sql, ...), die das Schema ueber die Zeit entwickeln. Quellen:

• _migrations/core/ — Kernsystem.
• _migrations/plugins/{name}/ — Plugin-zentrale Migrationen.
• _public/extensions/core/backend/*/migrations/ — Plugin-eigene Migrationen.

Der Update-Manager scannt alle drei, gleicht gegen die Tabelle _migrations ab und fuehrt nur die fehlenden aus.

Klick Migrationen ausführen. Der Button zeigt einen Spinner. Bei Erfolg faellt Ausstehende Migrationen auf null, Letzte Migration aktualisiert sich.

Vorher Datenbank-Backup

Migrationen sind grundsaetzlich idempotent (CREATE TABLE IF NOT EXISTS, ALTER TABLE ... ADD COLUMN IF NOT EXISTS), aber eine fehlerhafte Migration kann Daten trotzdem zerstoeren. Mach einen SQL-Dump vor Migrationen auf Produktion.

2. System-Update einspielen

Klick Auf Updates prüfen. Der Update-Manager verbindet sich mit dem Update-Server und vergleicht die installierte Version mit der neuesten.

Liegt ein Update vor, erscheint ein Banner mit:

• Der neuen Versionsnummer.
• Einem zusammenklappbaren Changelog mit Release Notes jeder Version zwischen deiner aktuellen und der neuesten.
• Einem Update installieren-Button.

Klick Update installieren. Ein Bestaetigungs-Dialog fasst zusammen:

• Aktuelle Version → neue Version.
• Was der Installer tut: ZIP laden, Backup, Dateien ueberschreiben, Migrationen ausfuehren.

Klick Bestätigen. Der Installer braucht Sekunden bis Minuten. Schliess den Tab nicht, solange er laeuft.

Bei Erfolg laedt die Seite mit der neuen Version neu.

Anmeldedaten in config.local.php

Der Update-Server braucht update_user, update_password und update_base_url in config.local.php. Fehlen sie, schlaegt die Pruefung mit 401 Unauthorized fehl. Bitte deinen Entwickler, sie einzurichten.

3. Deployments

Deployments schieben dein Staging-CMS auf ein Live-Ziel — Datenbank plus Dateien. Typisch: Neue Site auf staging.example.com gebaut, muss fuer Start auf example.com.

Klick Neue Verbindung, um ein Ziel anzulegen.

Feld	Zweck
Name	Sprechendes Label, z.B. Production Server.
DB-Host / DB-Name / DB-Benutzer / DB-Passwort	Zugangsdaten der Ziel-Datenbank. Verschluesselt gespeichert (AES-256-CBC).
Zielverzeichnis	Absoluter Pfad auf dem Zielsystem, wohin die Dateien kommen.
Such-URL	URL der Staging-Instanz, z.B. https://staging.example.com.
Ersetzen-URL	URL der Ziel-Instanz, z.B. https://example.com.

Klick Speichern. Das Ziel erscheint als Karte.

Verbindung testen

Klick auf der Karte auf Verbindung testen. Das System:

1. Verbindet sich mit der Ziel-DB und fuehrt SELECT VERSION() aus.
2. Prueft, ob das Zielverzeichnis beschreibbar ist.

Gruenes Ergebnis = bereit zum Deployen. Rotes Ergebnis = Zugangsdaten oder Rechte falsch; vor dem Deploy fixen.

Deployment starten

Klick auf das Rakete-Icon Bereitstellen. Bestaetigungs-Dialog listet die Schritte. Klick Bestätigen.

Die 7-Schritt-Pipeline laeuft:

1. ZIP erstellen — aktuelles Dateisystem buendeln.
2. DB-Dump — aktuelle Datenbank mit mysqldump exportieren.
3. Dateien kopieren — ZIP im Zielverzeichnis entpacken.
4. Ziel-DB bereinigen — alle Tabellen der Ziel-DB loeschen ausser denen in updatemanager/config/deploy_exclude_tables.json.
5. Dump importieren — Dump in die Ziel-DB einspielen.
6. URL ersetzen — Jede Tabelle durchgehen und Such-URL durch Ersetzen-URL ersetzen, mit Respekt vor PHP-serialisierten und JSON-escapten Werten.
7. Webhook — deployment.completed feuern.

Die Pipeline braucht eine bis mehrere Minuten, abhaengig von DB-Groesse. Fortschritt erscheint im Log-Panel.

Die Ziel-DB wird GELEERT

Schritt 4 loescht Tabellen. Benutzer, Bestellungen und alle Daten auf dem Live-Ziel werden durch den Staging-Dump ersetzt — per Design. Willst du Live-Benutzer und -Bestellungen behalten, setz sie vor dem Deploy in deploy_exclude_tables.json. Falsch konfigurierte Ausschluesse sind die haeufigste Ursache fuer Datenverlust.

Ziel bearbeiten / loeschen

• Bearbeiten — Stift-Icon. Aenderungen greifen beim naechsten Deploy. Passwort leer lassen heisst gespeichertes beibehalten.
• Löschen — Muell-Icon. Nur der Eintrag wird entfernt; Ziel-DB und Dateisystem bleiben unberuehrt.

Haeufige Fehler

"Connection failed" beim Test. DB-Zugangsdaten falsch oder der MySQL-Benutzer hat keine CREATE, DROP, INSERT-Rechte. Der Benutzer braucht volle Schema-Rechte auf der Ziel-DB.

Deploy klappt, aber die Site zeigt die alte URL. URL-Ersetzen hat einen serialisierten String nicht erwischt. Pruef Widget-Konfigs mit PHP serialize(); fuer seltene Formate ergaenze eine Migration, die den Wert normalisiert.

Update-Pruefung liefert 401. Die Update-Server-Zugangsdaten in config.local.php sind falsch oder fehlen.

Migrationen bleiben ausstehend nach der Ausfuehrung. Der DB-Benutzer hat keine CREATE-Rechte, eine Migration scheitert still. Pruef das PHP-Fehler-Log.

Siehe auch

• Task-Manager — der Cron-Worker, der die Warteschlange abarbeitet.
• Log — Deploys landen als deploy-Events.
• Webhooks — abonnier deployment.completed.