--- title: "WordPress-Updates per WP-CLI: Core, Plugins und Themes auf der Kommandozeile aktualisieren" date: 2026-09-30T20:59:36+02:00 modified: 2026-11-10T17:18:47+01:00 category: wordpress type: how_to author: Marcel Schönfelder canonical: https://s-edv.com/anleitungen/wordpress-updates-wp-cli-core-plugins-themes keywords: - WordPress - WP-CLI - Updates - Plugins - Wartung reading_time: 10 --- # WordPress-Updates per WP-CLI: Core, Plugins und Themes auf der Kommandozeile aktualisieren Wer mehrere WordPress-Websites betreut oder per SSH auf den Server kommt, spielt Updates mit **WP-CLI** schneller und nachvollziehbarer ein als über das Backend. Jeder Befehl liefert eine klare Ausgabe mit alter und neuer Version, Probeläufe zeigen vorab, was passieren würde, und einzelne Plugins lassen sich gezielt ausnehmen. Diese Anleitung führt Sie in einer sicheren Reihenfolge durch Core, Datenbank, Plugins, Themes und Übersetzungen und zeigt, wie Sie bei Problemen auf eine ältere Version zurückgehen. **Kurzfassung:** Sichern Sie zuerst Datenbank und Dateien, prüfen Sie dann mit `wp core check-update` und `wp plugin update --all --dry-run`, was ansteht. Aktualisieren Sie anschließend Core, Datenbankschema, Plugins, Themes und Sprachdateien in dieser Reihenfolge. Führen Sie WP-CLI immer als Benutzer des Webservers aus, damit die Dateirechte stimmen. Bei Problemen können Sie die vorherigen Dateien mit `--version` und `--force` erneut installieren. Datenbankänderungen erfordern die Wiederherstellung des Backups. ## Voraussetzungen - [ ] **WordPress:** eine laufende Installation. Die Beispielausgaben stammen von WordPress 7.1.2, die Befehle funktionieren seit vielen Versionen gleich. - [ ] **WP-CLI:** auf dem Server installiert, die Beispielausgaben stammen von Version 2.12.0. Die Version zeigt `wp cli version`. - [ ] **PHP:** WP-CLI nutzt das PHP der Kommandozeile. WordPress empfiehlt laut Update-API mindestens PHP 7.4. - [ ] **Zugriff:** SSH-Zugang zum Server oder Webhosting mit Shell-Zugriff. Reine FTP-Zugänge reichen nicht. - [ ] **Rechte:** Schreibrechte im WordPress-Verzeichnis als Benutzer des Webservers (unter Debian und Ubuntu meist `www-data`) sowie ein Administratorkonto im Backend für die Kontrolle danach. - [ ] **Backup:** eine aktuelle Sicherung von Datenbank und `wp-content`, die Sie zurückspielen können. Schritt 1 zeigt eine schnelle Sicherung per WP-CLI. Falls Sie noch keinen SSH-Schlüssel nutzen, richten Sie ihn vorher ein: [SSH-Key-Authentifizierung einrichten](https://s-edv.com/anleitungen/ssh-key-authentifizierung-einrichten-linux-windows). ## Schritt 1: Richtig anmelden und eine Sicherung ziehen Wechseln Sie in das WordPress-Verzeichnis, also den Ordner mit der `wp-config.php`. WP-CLI sucht die Installation im aktuellen Verzeichnis, alternativ geben Sie den Pfad mit `--path` an. Führen Sie die Befehle als Benutzer des Webservers aus. Arbeiten Sie als root, gehören neu entpackte Dateien root, und spätere Updates aus dem Backend scheitern an fehlenden Schreibrechten. WP-CLI verweigert den Betrieb als root deshalb standardmäßig, der Schalter `--allow-root` umgeht das nur, löst das Rechteproblem aber nicht. ```bash $ cd /var/www/html $ sudo -u www-data wp core version --extra ``` Die Ausgabe sieht so aus: ```plaintext WordPress version: 7.1.2 Database revision: 61833 TinyMCE version: 4.9110 (49110-20250317) Package language: en_US ``` Sichern Sie danach die Datenbank. `wp db export` liest die Zugangsdaten aus der `wp-config.php`, Sie müssen kein Passwort eintippen. Legen Sie die Datei außerhalb des Webroots ab, damit sie nicht über den Browser abrufbar ist, und packen Sie `wp-content` zusätzlich ein, denn dort liegen Plugins, Themes und Uploads. ```bash $ sudo install -d -o www-data -m 700 /var/backups/wordpress $ sudo -u www-data wp db export /var/backups/wordpress/vor-update-$(date +%F).sql $ sudo tar -czf /var/backups/wordpress/wp-content-$(date +%F).tar.gz wp-content ``` > **Prüfen:** `wp db export` meldet `Success: Exported to '...sql'.`, und `ls -lh /var/backups/wordpress` zeigt SQL-Datei und Archiv mit plausibler Größe. ## Schritt 2: Anstehende Updates prüfen, ohne etwas zu ändern Prüfen Sie vor Änderungen die installierten und verfügbaren Versionen, um große Versionssprünge zu erkennen. ```bash $ sudo -u www-data wp core check-update $ sudo -u www-data wp plugin list --update=available --fields=name,status,version,update_version $ sudo -u www-data wp theme list --update=available --fields=name,version,update_version ``` Sind ältere Versionen installiert, sieht die Ausgabe so aus: ```plaintext version update_type package_url 7.1.2 minor https://downloads.wordpress.org/release/de_DE/wordpress-7.1.2.zip name status version update_version akismet inactive 5.3 5.7.2 classic-editor active 1.6.3 1.7.0 name version update_version twentytwentythree 1.0 1.7 ``` Ist nichts zu tun, meldet `wp core check-update` `Success: WordPress is at the latest version.` Für Plugins gibt es zusätzlich einen echten Probelauf, der dieselbe Auswahl trifft wie der spätere Befehl: ```bash $ sudo -u www-data wp plugin update --all --dry-run ``` Bei einem Sprung in der ersten oder zweiten Versionsstelle lohnt vorher ein Blick in das Änderungsprotokoll auf der Plugin-Seite bei wordpress.org. > **Prüfen:** Sie haben eine Liste aller anstehenden Updates mit alter und neuer Version, und der Probelauf hat nichts verändert (`wp plugin list` zeigt weiterhin die alten Versionen). ## Schritt 3: WordPress-Core und Datenbank aktualisieren Aktualisieren Sie den Core zuerst, weil neue Plugin-Versionen oft eine aktuelle WordPress-Version voraussetzen. Für den laufenden Betrieb reicht meist die vorsichtige Variante: `--minor` spielt nur Wartungs- und Sicherheitsversionen innerhalb derselben Hauptversion ein, also etwa von 7.1.1 auf 7.1.2, nicht aber auf 7.2. ```bash $ sudo -u www-data wp core update --minor $ sudo -u www-data wp core update-db ``` Die Ausgabe beim Sprung von 7.1.1 auf 7.1.2: ```plaintext Updating to version 7.1.2 (de_DE)... Herunterladen der Aktualisierung von https://downloads.wordpress.org/release/de_DE/wordpress-7.1.2.zip ... Entpacken der aktualisierten Version ... Success: WordPress updated successfully. Success: WordPress database already at latest db version 61833. ``` WP-CLI lädt dabei automatisch das Paket in der Sprache der Installation. Ein Hauptversions-Update starten Sie ohne `--minor` mit `wp core update`. Planen Sie es bewusst ein, am besten nach einem Test auf einer Kopie der Website. `wp core update-db` bringt das Datenbankschema auf den Stand des neuen Codes. Mit `--dry-run` sehen Sie vorher, ob eine Änderung ansteht. > **Prüfen:** `wp core version` zeigt die neue Version, `wp core check-update` meldet `WordPress is at the latest version.`, und `wp core verify-checksums` endet mit `Success: WordPress installation verifies against checksums.` ## Schritt 4: Plugins gezielt aktualisieren Wählen Sie die Update-Stufe passend zum Risiko Ihrer Plugins. | Befehl | Wirkung | Beispiel | | --- | --- | --- | | `wp plugin update --all` | alle Plugins auf die neueste Version | akismet 5.3 auf 5.7.2 | | `wp plugin update --all --minor` | nur innerhalb der ersten Versionsstelle | akismet 5.3 auf 5.7.2 | | `wp plugin update --all --patch` | nur innerhalb der zweiten Versionsstelle | akismet 5.3 auf 5.3.7 | | `wp plugin update --all --exclude=NAME` | alle außer den genannten Plugins | „Skipped updates for: classic-editor“ | | `wp plugin update NAME` | nur das genannte Plugin | akismet 5.3 auf 5.7.2 | Die Option `--patch` ist die vorsichtigste Stufe und eignet sich für geschäftskritische Plugins wie Shop oder Formulare, bei denen Sie größere Sprünge erst prüfen möchten. Mit `--exclude` nehmen Sie Plugins aus, deren Update Sie separat begleiten wollen. Für eine Website mit wenigen, gut gepflegten Plugins reicht in der Regel: ```bash $ sudo -u www-data wp plugin update --all ``` Die Ausgabe sieht so aus: ```plaintext Wartungsmodus wird aktiviert … Herunterladen der Aktualisierung von https://downloads.wordpress.org/plugin/akismet.5.7.2.zip ... Das Plugin wurde erfolgreich aktualisiert. Herunterladen der Aktualisierung von https://downloads.wordpress.org/plugin/classic-editor.1.7.0.zip ... Das Plugin wurde erfolgreich aktualisiert. Wartungsmodus wird deaktiviert … name old_version new_version status akismet 5.3 5.7.2 Updated classic-editor 1.6.3 1.7.0 Updated Success: Updated 2 of 2 plugins. ``` WordPress schaltet während der Plugin-Updates selbst den Wartungsmodus ein und danach wieder aus. Besucher sehen in diesen Sekunden eine kurze Wartungsseite. > **Prüfen:** Die Tabelle zeigt bei jedem Plugin `Updated`, `wp plugin list --update=available` liefert keine Zeilen mehr, und `wp plugin verify-checksums --all` meldet `Success: Verified 3 of 3 plugins.` (Anzahl je nach Installation). Plugins, die nicht aus dem Verzeichnis auf wordpress.org stammen, kann dieser Abgleich nicht prüfen. ## Schritt 5: Themes und Übersetzungen nachziehen Themes aktualisieren Sie mit denselben Optionen wie Plugins. Achten Sie besonders auf das aktive Theme: Haben Sie Dateien darin direkt geändert, überschreibt das Update diese Änderungen. Eigene Anpassungen gehören deshalb in ein Child-Theme. ```bash $ sudo -u www-data wp theme update --all $ sudo -u www-data wp language core update $ sudo -u www-data wp language plugin update --all $ sudo -u www-data wp language theme update --all ``` `wp theme update --all` aktualisiert alle Themes, zum Beispiel Twenty Twenty-Three von 1.0 auf 1.7. Die Sprachbefehle sind wichtig, weil Übersetzungen eigene Pakete sind: Nach einem Plugin-Update lädt `wp language plugin update --all` zum Beispiel die deutsche Übersetzung für Classic Editor 1.7.0 nach. > **Prüfen:** `wp theme list --update=available` ist leer, und `wp language core update` meldet `Success: Translations are up to date.` ## Schritt 6: Website kontrollieren und bei Bedarf zurückgehen Ein erfolgreicher Befehl bedeutet nicht, dass die Website funktioniert. Rufen Sie die Startseite, eine Unterseite, das Kontaktformular und, falls vorhanden, den Shop auf. Melden Sie sich im Backend an und öffnen Sie **Werkzeuge > Website-Zustand**. Auf der Kommandozeile hilft ein schneller Blick auf den HTTP-Status: ```bash $ curl -s -o /dev/null -w "%{http_code}\n" https://www.example.de/ ``` Erwartet wird `200`. Macht ein Plugin nach dem Update Probleme, installieren Sie die vorherige Version erneut. Die Versionsnummer kennen Sie aus Schritt 2: ```bash $ sudo -u www-data wp plugin install akismet --version=5.3 --force ``` Der Befehl ersetzt die installierte Version, im Beispiel 5.7.2 durch 5.3 („Die alte Version des Plugins wird entfernt“), das Plugin bleibt dabei aktiv beziehungsweise inaktiv wie vorher. Für den Core funktioniert der Weg zurück entsprechend mit `wp core update --version=7.1.1 --force`, damit lässt sich zum Beispiel von 7.1.2 auf 7.1.1 zurückgehen. Das ist ein Notbehelf: Datenbankänderungen einer neueren Hauptversion macht er nicht rückgängig. Nach einem Hauptversions-Update ist deshalb das Backup aus Schritt 1 der sichere Weg zurück. Schreibt das Update PHP-Fehler, finden Sie die Ursache schneller mit aktiviertem Fehlerprotokoll, wie in [WordPress Debug-Modus aktivieren](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) beschrieben. > **Prüfen:** Die wichtigsten Seiten liefern Status `200`, der Website-Zustand zeigt keine neuen kritischen Probleme, und nach einem Rückschritt zeigt `wp plugin list` die gewünschte Version. ## Updates als Routine Die Befehle lassen sich in ein kleines Shell-Skript schreiben, das Sie regelmäßig ausführen. Automatisch per Cron sollten Sie höchstens Wartungsversionen einspielen, und nur mit vorheriger Datenbanksicherung und Kontrolle der Ausgabe. Hauptversionen und große Plugin-Sprünge brauchen einen Menschen, der danach die Website prüft. Wie Sie WP-CLI grundsätzlich über den System-Cron laufen lassen, zeigt [WordPress Cron Job einrichten](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten). Sicherheitsversionen erscheinen unregelmäßig. Die laufende Kontrolle können Sie abgeben: Die [WordPress-Wartung von wordpressupdate.de](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=artikel&utm_campaign=4) spielt Updates von WordPress, Plugins und Themes innerhalb von 48 Stunden mit Kompatibilitätsprüfung ein und sichert die Website wöchentlich auf externen Speicher. ## Typische Fehler **`Error: Momentan wird eine andere Aktualisierung durchgeführt.`** (englisch „Another update is currently in progress.“): Ein früheres Update wurde abgebrochen und hat die Sperre `core_updater.lock` hinterlassen. Prüfen Sie, dass wirklich kein Update läuft, dann: `wp option delete core_updater.lock`. Danach läuft das Update durch. **Website zeigt „Wartungsmodus“ und HTTP-Status 503** Eine übrig gebliebene Datei `.maintenance` im WordPress-Verzeichnis. `wp maintenance-mode status` zeigt den Zustand, `wp maintenance-mode deactivate` beendet ihn. Ist die Datei beschädigt, meldet WP-CLI „Unable to read the maintenance file timestamp“, dann löschen Sie `.maintenance` von Hand. **`Warning: The 'NAME' plugin could not be found.`** gefolgt von `Error: No plugins updated (1 failed).`: Sie haben den Anzeigenamen statt des Ordnernamens verwendet. Den richtigen Namen zeigt die Spalte `name` in `wp plugin list`. **`Error: YIKES! It looks like you're running this as root.`** Sie haben WP-CLI als root aufgerufen. Starten Sie den Befehl mit `sudo -u www-data` statt mit `--allow-root`, sonst gehören neue Dateien root. **Backend meldet danach „Aktualisierung fehlgeschlagen“ oder fragt nach FTP-Daten** WP-CLI lief als root, und die neuen Dateien gehören root. Korrigieren Sie die Rechte mit `chown -R www-data:www-data wp-content` und nutzen Sie künftig `sudo -u www-data`. **`Warning: File should not exist: ...`** bei `wp core verify-checksums`: Im Core-Verzeichnis liegt eine Datei, die nicht zu WordPress gehört. Das kann etwa eine Konfigurationsdatei des Docker-Images sein. Unbekannte PHP-Dateien sollten Sie prüfen, sie können auf eine Kompromittierung hinweisen. ## Häufige Fragen ### Ist WP-CLI sicherer als Updates über das Backend? Die heruntergeladenen Pakete und der Update-Mechanismus sind dieselben. Der Gewinn liegt in der Kontrolle: Probelauf, gezieltes Ausnehmen einzelner Plugins, klare Ausgaben für ein Protokoll und keine Abbrüche durch Zeitlimits des Browsers. ### Werden Premium-Plugins mit aktualisiert? Nur wenn das Plugin seine Updates in den normalen WordPress-Update-Mechanismus einspeist und die Lizenz auf der Website aktiv ist. Prüfen Sie in Schritt 2, ob das Plugin in der Liste auftaucht. Fehlt es, obwohl der Hersteller eine neue Version anbietet, müssen Sie das Update über dessen Weg einspielen. ### Wie aktualisiere ich mehrere Websites auf einem Server? Mit dem globalen Parameter `--path` sprechen Sie jede Installation direkt an, zum Beispiel `wp --path=/var/www/kunde1 plugin update --all`. Führen Sie die Websites nacheinander aus und kontrollieren Sie jede einzeln. ## Fazit Mit WP-CLI werden Updates planbar: Sicherung, Überblick, Core, Datenbank, Plugins, Themes und Übersetzungen in fester Reihenfolge, dazu ein erprobter Weg zurück. Entscheidend bleibt die Kontrolle danach, denn ein erfolgreicher Befehl ersetzt keinen Blick auf die Website. Wenn Sie diese Routine lieber abgeben möchten, übernimmt die [WordPress-Wartung von Marcel Schönfelder](https://wordpressupdate.de/?utm_source=s-edv.com&utm_medium=fazit&utm_campaign=4) Updates und externe Backups für Sie. ## Weiterführende Anleitungen und Quellen - [WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen](https://s-edv.com/anleitungen/wordpress-wp-cron-echte-cronjobs-einrichten) - [WordPress Debug-Modus aktivieren und Error-Logs analysieren](https://s-edv.com/anleitungen/wordpress-debug-modus-error-logs-fehler-beheben) - [WordPress nativ auf Ubuntu installieren](https://s-edv.com/anleitungen/wordpress-nativ-ubuntu-lamp-apache-mariadb-php-fpm) - [WP-CLI-Handbuch: wp core update](https://developer.wordpress.org/cli/commands/core/update/) - [WP-CLI-Handbuch: wp plugin update](https://developer.wordpress.org/cli/commands/plugin/update/) - [WP-CLI-Handbuch: wp language](https://developer.wordpress.org/cli/commands/language/) - [WP-CLI-Handbuch: wp maintenance-mode](https://developer.wordpress.org/cli/commands/maintenance-mode/)