WordPress-Updates und Staging per API steuern

WordPress-Updates und Staging per API steuern

Mit der Hosting-API prüfst du offene Plugin- und Theme-Updates und führst sie aus, auch aus einer Pipeline. Außerdem kannst du eine Staging-Website wieder löschen. Alles läuft über eigene Rechte, damit ein Token nur das kann, was du ihm gibst.

Offene Updates anzeigen

Mit dem Recht updates:read liest du die offenen Updates einer WordPress-Site:

turbopress updates list --site SITE_ID --json

Die Antwort nennt die Core-Version und alle Plugins und Themes mit einem offenen Update, jeweils mit der installierten und der verfügbaren Version. Die Prüfung liest den Stand direkt von der Website und kann bei großen Installationen bis zu einer Minute dauern. Rufe sie nicht in kurzen Abständen ab.

Plugins mit ungewöhnlichen Kennungen (etwa js_composer) erscheinen nicht in der Liste und lassen sich nicht über die API aktualisieren. Aktualisiere sie im WordPress Toolkit von Plesk.

Updates ausführen

Mit dem Recht updates:run aktualisierst du bis zu fünf Plugins oder Themes in einem Auftrag:

turbopress updates run --site SITE_ID --plugin classic-editor --theme twentytwentyfive --wait

Was dabei passiert:

• Vor dem ersten Update legt die API immer ein Sicherheitsbackup an. Schlägt das fehl oder dauert es zu lange, wird nichts aktualisiert, und der Auftrag meldet das ehrlich.
• Erreicht die Installation ihr Backup-Limit, lehnt die API den Auftrag ab (backup_limit_reached). Entferne zuerst ein altes Backup, siehe Backups anzeigen und löschen.
• Das Ergebnis nennt je Plugin oder Theme die alte und die neue Version (updated, unchanged oder failed) und den Namen des Sicherheitsbackups.
• Ein Auftrag hat ein Zeitbudget von sechs Minuten. Schafft er nicht alle Einträge, stehen die übrigen als skipped im Ergebnis. Starte sie dann in einem zweiten Auftrag.
• WordPress selbst (Core) aktualisierst du nicht hier, sondern mit dem eigenen Recht updates:core, siehe unten. In einem updates run-Auftrag wird ein Core-Eintrag mit core_update_not_supported abgelehnt.

Bei einem Teilerfolg endet der Auftrag mit failed und zeigt trotzdem, welche Einträge aktualisiert wurden. Ein Update läuft nie ohne vorheriges Sicherheitsbackup.

WordPress-Core aktualisieren

Mit dem Recht updates:core aktualisierst du WordPress selbst:

turbopress core update --site SITE_ID --expected-version 6.9 --wait

--expected-version ist optional. Mit der Angabe lehnt die API ab (version_changed), wenn eine andere Version angeboten wird. Ohne sie wird die angebotene Version installiert. Ist WordPress schon aktuell, passiert nichts (no_core_update).

Der Auftrag läuft im Hintergrund und kann einige Minuten dauern:

• Vor dem Update legt die API immer ein Sicherheitsbackup an. Ohne dieses wird nichts aktualisiert. Bei erreichtem Backup-Limit lehnt sie ab (backup_limit_reached).
• Die Versionen vor und nach dem Update liest die API direkt von der Website. succeeded gilt nur, wenn die Version danach höher ist als davor. Das Ergebnis nennt from, to und das Sicherheitsbackup.
• Bleibt die Version gleich, endet der Auftrag als failed (core_not_updated oder core_update_failed). Lässt sich die neue Version nicht lesen oder ist das Update nur teilweise gelaufen, ist der Ausgang unknown (Exitcode 4). Prüfe dann die Website. Das Sicherheitsbackup ist der Weg zurück, siehe Backup zurückspielen.
• Es gibt keine automatische Funktionsprüfung und kein automatisches Rollback.
• Pro Tag sind zehn Core-Updates möglich.

Plugin ein- oder ausschalten

Mit dem Recht plugins:manage schaltest du ein installiertes Plugin ein oder aus:

turbopress plugins disable --site SITE_ID --plugin akismet --wait

--plugin ist der Verzeichnisname des Plugins. Der Auftrag ist kurz, legt kein Sicherheitsbackup an und liest den Zustand nach dem Schalten zurück. Steht das Plugin schon so, endet er als succeeded mit changed: false. Must-Use-Plugins werden als plugin_not_installed abgelehnt, netzwerkweit aktive Plugins mit network_activated. Pro Tag sind 20 Schaltungen möglich. Die API hindert dich nicht daran, Sicherheits- oder Cache-Plugins oder WooCommerce abzuschalten.

Staging löschen

Mit dem Recht staging:delete entfernst du die Staging-Website einer Live-Site. Das Recht gibt es nur an der Live-Site, nicht an der Staging-Site selbst. Du gibst die Live-Site an und bestätigst den Host des Stagings:

turbopress staging delete --site LIVE_SITE_ID --confirm staging.beispiel.de --wait

Das Löschen ist dauerhaft. Zur Sicherheit gilt:

• Die Bestätigung muss exakt dem Host der Staging-Website entsprechen, sonst passiert nichts (confirmation_mismatch).
• Gelöscht wird nur die Staging-Kopie der angegebenen Live-Site, nie die Live-Site selbst. Die Staging-Site muss staging. plus deine Hauptdomain heißen.
• Läuft gerade ein Backup oder ein Update für die Site, lehnt die API ab (staging_in_use).
• Pro Tag sind fünf Löschungen möglich.

Gib dem Token, das diese Aufträge ausführt, nur das Recht, das es braucht. staging:delete, updates:run, updates:core und plugins:manage stehen nicht in der Schnellauswahl des Formulars und sind nie vorausgewählt.

Wenn die Website gerade beschäftigt ist

Schreibende Aufträge einer Website laufen nie gleichzeitig. Dafür gibt es eine gemeinsame Sperre je Hosting-Paket (Subscription): Live-Site und Staging-Site im selben Paket teilen sie sich. Läuft gerade etwas (zum Beispiel ein Backup, ein Update oder eine Übernahme von Staging nach Live im Panel oder per KI-Zugriff), endet ein neuer Schreibaufruf ohne Wirkung als failed mit site_busy. Warte einige Minuten und starte ihn mit einem neuen Idempotency-Key erneut. Lesende Aufrufe wie die Siteliste, die Backupliste oder operations list gehen währenddessen weiter, und die Websites anderer Kunden sind nie betroffen.

Welche Site ist Live, welche Staging?

In der Siteliste zeigt jedes Element role (live oder staging). Bei einer Staging-Site nennt staging_of die Live-Site, sofern dein Token auch sie sehen darf.

Weitere Anleitungen

Staging anlegen und übernehmen · Backup zurückspielen · API-Token erstellen · Backups anzeigen und löschen · Fehlersuche · turbopress CLI installieren · OpenAPI-Referenz