WP-CLI installieren: die wichtigsten WordPress-Befehle für Admins
So installieren Sie WP-CLI auf dem Server, prüfen die Datei und nutzen die Befehle, die Admins brauchen: Updates prüfen, Plugins verwalten, Datenbank sichern, Dateien kontrollieren.
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Mehr dazu
Im Backend von WordPress klicken Sie sich für jede Aufgabe einzeln durch Menüs. Auf der Kommandozeile erledigen Sie dieselbe Arbeit mit einem Befehl, der sich wiederholen, protokollieren und in Skripte packen lässt. Das Werkzeug dafür heißt WP-CLI, die offizielle Kommandozeile für WordPress. Diese Anleitung zeigt, wie Sie WP-CLI auf einem Linux-Server installieren, die Datei auf Echtheit prüfen und die Befehle nutzen, die Admins kleiner Websites im Alltag wirklich brauchen: Versionen und Updates prüfen, Plugins verwalten, die Datenbank sichern, Dateien auf Veränderungen kontrollieren und Benutzer pflegen.
Voraussetzungen
- WordPress ab einer aktuellen Version, getestet mit WordPress 7.1.2.
- PHP auf der Kommandozeile: WP-CLI verlangt laut Handbuch PHP 7.2.24 oder neuer. Die Version zeigt
php --version. - SSH-Zugang zum Server oder Webhosting mit Shell. Reines FTP genügt nicht, weil WP-CLI auf dem Server selbst läuft.
- Rechte, um eine Datei nach
/usr/local/binzu legen (sudo). Ohne sudo geht auch ein Ordner im eigenen Home-Verzeichnis, siehe Häufige Fragen. - Den MariaDB- oder MySQL-Client auf dem Server (Pakete wie
mariadb-client), falls Sie Datenbankbefehle nutzen wollen. - Ein Benutzerkonto mit der Rolle Administrator in WordPress und ein aktuelles Backup von Dateien und Datenbank, bevor Sie verändernde Befehle ausführen.
Schritt 1: WP-CLI herunterladen und Prüfsumme kontrollieren
Das WP-CLI-Handbuch empfiehlt die Phar-Datei. Das ist ein einzelnes PHP-Archiv, das alle Befehle enthält und ohne weitere Installation läuft. Laden Sie es in ein temporäres Verzeichnis:
cd /tmp
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar.sha512
echo "$(cat wp-cli.phar.sha512) wp-cli.phar" | sha512sum -cDie Prüfsumme stellt sicher, dass die Datei beim Download nicht beschädigt wurde. Das Handbuch beschreibt zusätzlich eine Prüfung per GPG-Signatur (wp-cli.phar.asc), die auch eine manipulierte Quelle erkennen würde. Auf Servern mit installiertem gpg lohnt sich dieser zusätzliche Schritt. Anschließend testen Sie die Datei, noch ohne sie zu installieren:
php wp-cli.phar --infoVerifizieren: sha512sum -c meldet wp-cli.phar: OK, und --info gibt unter anderem die PHP-Version und die Zeile WP-CLI version: 2.12.0 (oder neuer) aus.
Schritt 2: WP-CLI als Befehl wp installieren
Damit Sie künftig nur wp tippen, machen Sie die Datei ausführbar und verschieben sie in ein Verzeichnis im Suchpfad:
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --infoDie Datei gehört danach root. Das ist gewollt: So kann kein Plugin oder kompromittierter Webbenutzer das Werkzeug selbst verändern. Die Kehrseite zeigt sich beim Aktualisieren, dazu mehr in Schritt 8.
Verifizieren: which wp liefert /usr/local/bin/wp, und wp --info zeigt dieselbe Version wie in Schritt 1.
Schritt 3: Als richtiger Benutzer im richtigen Verzeichnis arbeiten
WP-CLI lädt WordPress mit allen aktiven Plugins. Jeder Code auf der Website läuft damit mit den Rechten des Benutzers, der den Befehl startet. Als root verweigert WP-CLI deshalb den Dienst, im Test kam wörtlich diese Meldung:
Error: YIKES! It looks like you're running this as root. You probably meant to run this as the user that your WordPress installation exists under.Arbeiten Sie deshalb als Eigentümer der WordPress-Dateien. Auf Debian und Ubuntu mit Apache ist das oft www-data, bei Webhostern meist Ihr SSH-Benutzer. Wem die Dateien gehören, zeigt ls -l:
ls -l /var/www/html/wp-config.php
sudo -u www-data -- wp --path=/var/www/html core versionOhne --path sucht WP-CLI WordPress im aktuellen Verzeichnis und darüber. Damit Sie den Pfad nicht jedes Mal angeben, wechseln Sie vorher mit cd in den WordPress-Ordner. Die Option --allow-root gibt es zwar, sie hebt den Schutz aber auf. Nutzen Sie sie nur, wenn Sie genau wissen, warum.
Verifizieren: wp core version gibt die installierte Version aus, im Test 7.1.2, ohne Fehlermeldung.
Schritt 4: Bestand und Updates prüfen
Die folgenden Befehle verändern nichts. Sie eignen sich als erster Blick auf eine fremde oder lange nicht gepflegte Website:
wp core version
wp core check-update
wp option get siteurl
wp plugin list
wp theme list --status=active
wp plugin list --update=available --format=countwp plugin list zeigt eine Tabelle mit Name, Status (aktiv oder inaktiv), vorhandenen Updates, Version und automatischen Updates. Die letzte Zeile zählt nur Plugins mit ausstehendem Update, das passt gut in ein Überwachungsskript. Ist WordPress aktuell, meldet wp core check-update im Test Success: WordPress is at the latest version.
Verifizieren: Die Liste der Plugins stimmt mit Plugins > Installierte Plugins im Backend überein.
Schritt 5: Datenbank sichern, bevor Sie etwas ändern
Ein Export dauert bei kleinen Websites Sekunden und ist die wichtigste Gewohnheit bei der Arbeit mit WP-CLI. Speichern Sie die Datei außerhalb des öffentlich erreichbaren Webordners, sonst könnte sie jemand über den Browser herunterladen:
mkdir -p ~/backups
wp db export ~/backups/vor-aenderung-$(date +%F-%H%M).sql
wp db size --human-readableWP-CLI ruft dafür das Programm mariadb-dump oder mysqldump auf. Fehlt der Datenbank-Client auf dem Server, scheitert der Export (siehe Typische Fehler). Die Wiederherstellung erfolgt mit wp db import DATEI.sql. Ausführlicher, inklusive Aufbewahrung und Rücksicherung, beschreibt das die Anleitung WordPress-Datenbank mit WP-CLI sichern und wiederherstellen.
Verifizieren: Die Ausgabe lautet Success: Exported to '…'., und die Datei in ~/backups ist größer als null Byte.
Schritt 6: Plugins und Updates verwalten
Mit WP-CLI installieren, aktivieren und entfernen Sie Plugins aus dem offiziellen Verzeichnis auf wordpress.org. Maßgeblich ist der Slug aus der Adresse der Plugin-Seite, etwa classic-editor:
wp plugin install classic-editor --activate
wp plugin deactivate classic-editor
wp plugin delete classic-editor
wp plugin update --all --dry-run
wp plugin update --allDie Option --dry-run listet auf, was aktualisiert würde, ohne etwas zu verändern. Das eigentliche Update erledigen Sie besser Plugin für Plugin, wenn die Website geschäftskritisch ist: Tritt ein Fehler auf, wissen Sie sofort, welches Update ihn ausgelöst hat. Premium-Plugins mit eigenem Update-Server lassen sich je nach Hersteller nur aktualisieren, wenn eine Lizenz hinterlegt ist. Einen Ablauf mit Sicherung, Reihenfolge und Kontrolle finden Sie in der Anleitung WordPress-Updates per WP-CLI einspielen.
Updates, Sicherungen und Kontrollen sind keine einmalige Aufgabe, sondern kommen jede Woche wieder. Wer diese Arbeit nicht selbst im Kalender halten möchte, kann sie abgeben: Die WordPress-Wartung von wordpressupdate.de spielt Updates von WordPress, Plugins und Themes mit Kompatibilitätsprüfung ein und legt wöchentlich ein Backup auf externem Speicher ab.
Verifizieren: Nach der Installation erscheint Success: Installed 1 of 1 plugins., und wp plugin list --status=active --field=name enthält das Plugin.
Schritt 7: Dateien prüfen, Benutzer und Wartungsmodus
Drei Befehlsgruppen helfen besonders bei der Fehlersuche und nach einem Verdacht auf Manipulation. Zuerst der Abgleich der Kerndateien und Plugins mit den Originalen auf wordpress.org:
wp core verify-checksums
wp plugin verify-checksums --allSind die Dateien unverändert, meldet der erste Befehl Success: WordPress installation verifies against checksums. Zusätzliche Dateien im Kern führt WP-CLI als Warnung auf. Im Docker-Image von WordPress erschien zum Beispiel Warning: File should not exist: wp-config-docker.php, das ist dort eine Vorlage des Images und unbedenklich. Unbekannte PHP-Dateien auf einem normalen Server sollten Sie dagegen genauer ansehen. Plugins aus fremden Quellen lassen sich so nicht prüfen, weil wordpress.org keine Prüfsummen für sie kennt.
Für Benutzer genügen meist diese Befehle:
wp user list --fields=ID,user_login,roles
wp user create redaktion redaktion@example.com --role=editor
wp user update 1 --user_pass='NEUES-STARKES-PASSWORT'Beachten Sie, dass ein Passwort in der Befehlszeile in der Shell-History landet. Löschen Sie die Zeile danach aus der History oder setzen Sie das Passwort lieber über das Backend. Als Letztes der Wartungsmodus, der Besuchern während größerer Arbeiten eine kurze Hinweisseite zeigt:
wp maintenance-mode activate
wp maintenance-mode status
wp maintenance-mode deactivateVerifizieren: wp maintenance-mode status meldet nach dem Deaktivieren nicht mehr Maintenance mode is active., und die Website lädt im Browser normal.
Schritt 8: WP-CLI aktuell halten und bequemer machen
Die Phar-Datei aktualisiert sich selbst mit wp cli update. Weil sie root gehört, klappt das nur mit sudo. Als Webbenutzer erscheint sonst ein Fehler:
sudo wp cli update --allow-root
wp --versionHier ist --allow-root vertretbar, weil wp cli update WordPress selbst nicht lädt. Im Test scheiterte die Versionsabfrage einmal mit Error: Failed to get latest version (HTTP code 403). In diesem Fall laden Sie die Phar-Datei wie in Schritt 1 neu herunter, prüfen die Prüfsumme und ersetzen /usr/local/bin/wp. Damit Sie nicht in jedem Befehl den Pfad angeben, legen Sie eine Datei wp-cli.yml an. WP-CLI sucht sie laut Handbuch im aktuellen Verzeichnis und darüber, die globale Variante liegt unter ~/.wp-cli/config.yml:
path: /var/www/htmlMit dem globalen Parameter --ssh=benutzer@server/pfad steuert WP-CLI eine entfernte Installation vom eigenen Rechner aus. Dafür muss WP-CLI auch auf dem Zielserver installiert sein.
Verifizieren: wp --version zeigt die aktuelle Version, und wp option get home funktioniert aus dem Verzeichnis mit der wp-cli.yml heraus ohne --path.
Typische Fehler
| Meldung | Ursache | Lösung |
|---|---|---|
Error: YIKES! It looks like you're running this as root. | Befehl als root gestartet | Als Dateieigentümer ausführen: sudo -u www-data -- wp … |
Error: This does not seem to be a WordPress installation. | Aktuelles Verzeichnis enthält kein WordPress | In den WordPress-Ordner wechseln oder --path= angeben |
env: 'mysqldump': No such file or directory | Datenbank-Client fehlt, betrifft wp db export und wp db check | Paket mariadb-client oder default-mysql-client installieren |
Error: /usr/local/bin/wp is not writable by current user. | wp cli update ohne Schreibrechte | sudo wp cli update --allow-root |
Warning: Failed to create directory '/var/www/.wp-cli/cache/' | Webbenutzer darf sein Home-Verzeichnis nicht beschreiben | Harmlos, Downloads funktionieren trotzdem. Optional WP_CLI_CACHE_DIR auf einen beschreibbaren Ordner setzen |
Error: 'foo' is not a registered wp command. | Tippfehler oder Befehl aus einem nicht installierten Paket | wp help zeigt alle verfügbaren Befehle |
Eine weitere Falle betrifft E-Mails: Legt WP-CLI einen Benutzer an, versucht WordPress eine Benachrichtigung zu verschicken. Auf Servern ohne Mailprogramm erscheint dann sh: 1: /usr/sbin/sendmail: not found, der Benutzer wird trotzdem angelegt. Für zuverlässigen Versand hilft die Anleitung zum E-Mail-Versand über SMTP.
Häufige Fragen
Geht WP-CLI auch ohne sudo, etwa beim Webhoster?
Ja. Legen Sie die Phar-Datei in einen eigenen Ordner, zum Beispiel ~/bin/wp, und ergänzen Sie diesen Ordner in Ihrer ~/.bashrc um export PATH="$HOME/bin:$PATH". Viele Hoster haben WP-CLI bereits vorinstalliert, prüfen Sie das zuerst mit which wp.
Ersetzt WP-CLI das Backend?
Nein. Inhalte schreiben, Menüs gestalten und Einstellungen mit visueller Vorschau bleiben im Backend einfacher. WP-CLI spielt seine Stärken bei wiederkehrenden Aufgaben aus, bei Massenänderungen und wenn das Backend wegen eines Fehlers nicht mehr lädt.
Was tun, wenn ein Plugin WP-CLI selbst abstürzen lässt?
Starten Sie den Befehl mit --skip-plugins und bei Bedarf --skip-themes. Dann lädt WordPress ohne Plugins, und Sie können das fehlerhafte Plugin mit wp --skip-plugins plugin deactivate NAME abschalten.
Wie ändere ich die Domain mit WP-CLI?
Mit wp search-replace alt neu --dry-run sehen Sie zunächst, wie viele Ersetzungen anfallen, im Test waren es acht. Der Befehl behandelt serialisierte Daten korrekt, anders als ein direktes SQL-Replace. Den vollständigen Ablauf beschreibt die Anleitung WordPress-Domain ändern.
Lässt sich WP-CLI in Cronjobs nutzen?
Ja, dafür ist es gut geeignet, etwa für nächtliche Exporte. Geben Sie in der Crontab den vollen Pfad /usr/local/bin/wp und --path= an und legen Sie den Job beim Dateieigentümer an, nicht bei root.
Testumfang
Wir haben WP-CLI auf einer Testinstallation mit WordPress 7.1.2 eingerichtet und alle gezeigten Befehle als Webbenutzer durchgespielt. Der Datenbankexport lief allerdings erst, nachdem wir den MariaDB-Client nachinstalliert hatten.
Nicht geprüft haben wir die Arbeit bei Webhostern mit eigener Shell-Umgebung. Wenn Sie bei einem solchen Hoster arbeiten, testen Sie die Befehle am besten zuerst auf einer Kopie Ihrer Website.
Fazit
WP-CLI ist schnell installiert und verändert den Alltag mit WordPress spürbar: Bestandsaufnahme, Sicherung, Updates und Prüfungen laufen in Sekunden und lassen sich wiederholen. Entscheidend sind drei Gewohnheiten: als Dateieigentümer arbeiten, vor jeder Änderung die Datenbank exportieren und bei Massenänderungen zuerst --dry-run nutzen. Wenn Sie die regelmäßigen Updates und Backups lieber abgeben, übernimmt das die WordPress-Wartung von Marcel Schönfelder.
