Die WP-CLI kann uns das Leben bei der Administration von WordPress-Installationen deutlich leichter machen. So zum Beispiel das Aufspielen von Updates auf mehreren Servern innerhalb weniger Sekunden. Dafür ist es nach einmaliger Konfiguration lediglich das Ausführen sechs kurzer WP-CLI-Befehle notwendig.
Ich gehe hier davon aus, dass wir WP-CLI bereits lokal installiert haben. Außerdem muss WP-CLI auch auf allen Servern installiert sein, auf denen WordPress-Updates gemacht werden sollen. Außerdem muss die Verbindung per SSH möglich sein – idealerweise mit einem hinterlegten SSH-Key.
Die Kernkomponente, neben WP-CLI selbst, um sich schnell auf mehrere Server zu verbinden, ist die WP-CLI-Config. Alle Funktionen der WP-CLI lassen sich zwar per Parameter innerhalb des jeweiligen CLI-Befehls nutzen, allerdings kann man dort immer nur einen Host, nur ein Ziel-System, angeben. Mit der WP-CLI-Config ist es dagegen möglich, mehrere Hosts anzugeben und diese über Aliase schnell zugänglich machen.
Es gibt mehrere Speicherorte, an denen wir die WP-CLI-Config ablegen können. Einmal die wp-cli.local.yml
im aktuellen oder einem übergeordneten Verzeichnis. Zum Zweiten die wp-cli.yml
im aktuellen oder einem übergeordneten Verzeichnis. Und zum Dritten die ~/.wp-cli/config.yml
im Unterordner des eigenen Home-Verzeichnisses (unter Windows typischerweise C:\Users:\<Benutzername>\
).
In diesem Fall wähle ich die dritte Variante, da diese immer an derselben Stelle zu finden ist und es mir somit egal sein kann, in welchem Verzeichnis ich mich aktuell in meiner Konsole befinde.
Unter Windows-Systemen muss die Datei demnach hier erstellt werden:C:\Users\<Benutzername>\.wp-cli\config.yml
Unter UNIX-Systemen oder macOS hier:~/.wp-cli/config.yml
Der Aufbau ist in beiden Systemen identisch.
Nachfolgend müssen wir einen Alias vergeben und die Verbindungsdaten per SSH zur jeweiligen WordPress-Instanz angegeben. Der Alias wird dabei immer mit einem vorangestellten @
geschrieben. Einen solchen Verbindungsblock kann dann zum Beispiel so aussehen:
@production:
ssh: username@krautpress.de/var/www/wordpress
Code-Sprache: YAML (yaml)
Wer sich bereits per SSH bzw. SCP auf einen Server verbunden hat, wird hier direkt Ähnlichkeiten zu diesem Befehl feststellen. Ungewöhnlich ist nur, dass nach der Angabe der Domain direkt der Pfad folgt, ohne eine weitere Unterteilung.
In diesem Beispiel verbindet wir uns bei der Nutzung des Alias @production
als username
auf den Server unter der Domain krautpress.de
und führt den Befehl der WP-CLI in der WordPress-Instanz unter /var/www/wordpress
aus (sofern dort eine vorhanden ist).
Um ein Core-Update auszuführen, sähe der Befehl folgendermaßen aus:wp @production core update
Zu Beginn habe ich aber von sechs Befehlen gesprochen. Das kommt daher, dass Plugins separat aktualisiert werden müssen und die Aktualisierung von Übersetzungen zwischen Core, Plugins und Themes unterteilt ist. Die restlichen fünf Befehle lauten demnach:
wp @production plugin update --all
wp @production theme update --all
wp @production language core update
wp @production language plugin update --all
wp @production language theme update --all
Code-Sprache: Bash (bash)
Dann haben wir aber immer noch das Problem, dass diese Befehle für alle Aliase, also für alle WordPress-Instanzen, die man wie oben als Alias definiert hat, erneut ausgeführt werden muss.
Wie wäre es also mit einem Alias für alle Aliase? Der ist bereits standardmäßig vorhanden und lässt sich mit @all
ansprechen.
Dafür müssen aber auch mehrere Aliases definiert sein. Die ganze config.yml
kann demnach folgendermaßen aussehen:
@production:
ssh: username@krautpress.de/var/www/wordpress
@dev:
ssh: devuser@dev.krautpress.de/var/www/worddev
@international:
ssh: username@krautpress.com/var/www/glotpress
@etc:
ssh: foo@bar.krautpress.de/var/www/foo
Code-Sprache: YAML (yaml)
Und schon können wir bei den sechs Befehlen oben statt @production
einfach @all
benutzen und führen dann den Befehl automatisch nacheinander auf allen WordPress-Instanzen aus.
Die Ausgabe in der Konsole kann dann folgendermaßen aussehen (am Beispiel von Übersetzungsaktualisierungen im Core):
$ wp @all language core update
@production
Success: Translations are up to date.
@dev
Updating 'German' translation for WordPress 5.0.2...
Downloading translation from https://downloads.wordpress.org/translation/core/5.0.2/de_DE.zip...
Unpacking the update...
Installing the latest version...
Translation updated successfully.
Success: Updated 1/1 translation.
@international
Success: Translations are up to date.
@etc
Success: Translations are up to date.
Code-Sprache: Bash (bash)
Es lassen sich auch noch andere Gruppen, ähnlich zu @all
, manuell selbst anlegen. Das sieht dann beispielsweise so aus:
@random_group:
- @dev
- @etc
Code-Sprache: YAML (yaml)
Damit werden dann bei Aufruf von wp @random_group
lediglich die WordPress-Instanzen angesprochen, die davor mit @dev
und @etc
definiert wurden.
Die WP-CLI ist ein sehr mächtiges Werkzeug und kann uns eine Menge Arbeit ersparen. Und das ist nur eine der vielen Funktionen, die sie bietet …
Hallo Matthias,
Super Beitrag, das hilft bestimmt vielen Leuten noch etwas mehr aus WP-CLI rauszuholen!
Hier noch eine kleine Anmerkung:
Die `@all`-Gruppe brauchst du nicht separat anzulegen, die besteht automatisch und beinhaltet alle bereits definierten Aliase. Du kannst natürlich andere Gruppen anlegen, die eine Teilmenge aus allen Aliasen beinhalten. So könnste du z.B. eine Gruppe pro Hosting-Anbieter haben, oder eine Gruppe pro Kunde. Wenn du Server-Cluster verwalten musst, sind Gruppen natürlich auch super hilfreich.
Um eine Übersicht zu sehen, welche Aliase schon definiert sind kannst du folgendes Kommando nutzen: `wp cli alias`.
Liebe Grüsse,
Alain
Vielen Dank für deine Anmerkung, aber besonders auch für dein Lob! Das freut mich sehr.
Ich habe den Beitrag entsprechend deiner Anmerkung angepasst und alternativ erklärt, wie man eigene Gruppen erstellen kann, welche mehrere Aliases umfassen.