Staging per API anlegen und nach Live übernehmen

Staging per API anlegen und nach Live übernehmen

Mit der Hosting-API legst du die Staging-Kopie einer WordPress-Website an und übernimmst sie später auf die Live-Website. Beides sind lange Aufträge mit eigenen Rechten. Die Übernahme überschreibt die Live-Website und ist die riskanteste Operation der API. Deshalb hat dort nichts einen Standardwert.

Staging anlegen

Das Recht staging:create legt die eine Staging-Kopie staging.<deine Hauptdomain> der Live-Website an. Du gibst die Live-Website an. Der Name der Kopie ist fest.

turbopress staging create --site LIVE_SITE_ID --wait

Was dabei passiert und wie du es liest:

• Pro Live-Website gibt es höchstens eine Kopie. Existiert sie schon, lehnt die API ab (staging_exists). Das gilt auch, wenn nur die Subdomain staging.<Hauptdomain> ohne Kopie übrig ist, etwa nach einem abgelehnten Klon. Entferne sie dann im Panel oder bitte den Support darum. Diese Ablehnung verbraucht kein Tageslimit.
• Hat der Webspace zu wenig Platz für Dateien und Datenbank plus Puffer, lehnt die API vorab ab (storage_insufficient).
• Ein Sicherheitsbackup gibt es hier nicht, weil an der Live-Website nichts geändert wird.
• Das Ergebnis nennt staging_host, den SSL-Stand (issued, failed oder unconfirmed) und die staging_site_id. Ein SSL-Problem lässt die Kopie trotzdem succeeded.
• Bestehende Tokens kennen die neue Website nicht. Stelle für staging_site_id ein neues Token aus, siehe API-Token für dein Hosting erstellen und widerrufen.
• Pro Tag sind drei Anlagen möglich. Anlagen über Chat, KI-Zugriff und Cockpit zählen mit.

Vorher prüfen: Trockenlauf

Bevor du die Live-Website überschreibst, prüfe die Übernahme mit --dry-run:

turbopress staging push --site LIVE_SITE_ID --scope all --dry-run

Der Trockenlauf antwortet sofort und ändert nichts. Er legt keinen Auftrag an, braucht keinen Idempotency-Key und zählt nicht gegen das Tageslimit. Du siehst das Paar aus Staging- und Live-Host, ob WooCommerce aktiv ist, die Tabellen der Staging-Datenbank, den Stand deines Backup-Limits, ob der Platz reicht und ob die Website gerade beschäftigt ist. Mängel werden gemeldet statt abgelehnt. Die echte Anfrage lehnt sie ab. Ein null heißt, dass der Wert nicht lesbar war. Die CLI gibt das Ergebnis als lesbaren Text aus, mit --json bekommst du die Rohdaten.

Nach Live übernehmen

Das Recht staging:push überschreibt die Live-Website mit ihrer Staging-Kopie:

turbopress staging push --site LIVE_SITE_ID --scope all --no-delete-missing-files --confirm-host beispiel.de --wait

Diese Angaben sind Pflicht:

Die Richtung ist immer Staging nach Live. Die Staging-Kopie nennst du nie, die API bestimmt sie nach der Namensregel.

Was dabei passiert:

1. Die API prüft alles noch einmal im Auftrag, unter der Sperre der Website.
2. Sie legt ein eigenes Sicherheitsbackup der Live-Website an. Ohne dessen genauen Dateinamen wird nichts kopiert. Ist dein Backup-Limit erreicht, lehnt sie vorab ab (backup_limit_reached).
3. Sie kopiert, leert den Cache und prüft die Live-Website vor und nach dem Kopieren.

Das Ergebnis nennt das Sicherheitsbackup (safety_backup) und die Funktionsprüfung (health_check). Es gibt kein automatisches Rollback. Steht health_check auf issue_found, ist die Kopie passiert und die Prüfung hat danach ein Problem gefunden. Den Weg zurück bietet das Sicherheitsbackup, siehe Backup per API zurückspielen.

Wird die Staging-Kopie zwischen deiner Anfrage und dem Lauf gelöscht und neu angelegt, kopiert der Auftrag die neue Kopie. Führe deshalb unmittelbar vor der Anfrage einen Trockenlauf aus und arbeite nicht parallel am Paket.

Grenzen

• Pro Tag sind fünf Übernahmen möglich, gemeinsam mit dem Panel und dem Cockpit.
• Live- und Staging-Website teilen sich eine Sperre. Läuft gerade etwas auf dem Paket, endet der Aufruf mit site_busy. Warte einige Minuten und starte ihn mit einem neuen Idempotency-Key erneut.
• Bei unklarem Ausgang (unknown, Exitcode 4, etwa copy_outcome_unknown) bleibt die Live-Website gesperrt, bis der Support den Ausgang geklärt hat. Siehe Hosting-API: 401, 403, 429, Timeout und unbekannter Jobstatus beheben.
• Staging löschen steht in WordPress-Updates und Staging per API steuern.

Weitere Anleitungen

API-Token für dein Hosting erstellen und widerrufen · Backup per API zurückspielen · WordPress-Updates und Staging per API steuern · Hosting-API: 401, 403, 429, Timeout und unbekannter Jobstatus beheben · turbopress CLI installieren und einrichten