Verwalten von WordPress-Entwicklungsumgebungen mit WP-CLI und Robo

Veröffentlicht: 2022-09-13

Die Automatisierung sich wiederholender Aufgaben ist eine der besten Möglichkeiten, Zeit in Ihrem Entwicklungsworkflow zu sparen. In meiner täglichen Arbeit als Plugin-Entwickler muss ich oft die Datenbank zurücksetzen, eine bestimmte Version von WordPress neu installieren, ein oder mehrere Plugins installieren und die Einstellungen aktualisieren. Das wird schnell ermüdend und eignet sich daher ganz natürlich für die Automatisierung. In diesem Artikel zeige ich Ihnen, wie ich WP-CLI in Kombination mit Robo verwende, um die Aufgaben zu automatisieren, die zur Verwaltung meiner WordPress-Entwicklungsumgebung erforderlich sind.

Das WordPress-Befehlszeilentool WP-CLI ist ein großartiger Anfang, um Ihren Workflow zu beschleunigen. Wenn Sie damit nicht vertraut sind, empfehle ich dringend, einen unserer vielen Blog-Beiträge zu lesen. Unser Installationsleitfaden ist ein guter Ausgangspunkt, der erklärt, wie Sie es auf Ihrem Betriebssystem installieren, die Registerkartenvervollständigung einrichten und eine Konfigurationsdatei erstellen.

Inhaltsverzeichnis

  1. Was ist Robo?
    1. Robo vereinfacht die PHP-Befehlszeile
    2. Robo installieren
    3. Dein erstes Kommando
    4. Eingang und Ausgang
    5. Tolle Helfer
    6. Vorteile von Robo
  2. WordPress mit Robo pflegen
    1. Die wichtigen Dateien
    2. Meine Umgebung
    3. Datenbankbenutzer
    4. Webserver
    5. Pflege von Abhängigkeiten
  3. Nutzung von wp-cli.yml
    1. Was ist ein Alias ​​in WP-CLI?
    2. Befehlsvorgaben
  4. Erstellen benutzerdefinierter Robo-Befehle
    1. Befehlskonfiguration
    2. Der reset Befehl
    3. Schritte nach der Installation
    4. Der profile
  5. Einpacken

Was ist Robo?

Robo ist ein moderner Open-Source-Task-Runner, der von einer Reihe von Projekten verwendet wird, darunter Drush und Codeception.

Robo ähnelt Gulp und Grunt, verwendet aber PHP statt JavaScript.

Die Idee ist, dass Sie raffinierte kleine Befehle wie diese erstellen können:

# Setzen Sie meine WP-Entwicklungsumgebung zurück und machen Sie sie zu mehreren Standorten
Robo-Reset --multi

# Installiere und richte das Plugin WP Offload Media ein
Robo-Profil ome-dev

Der Robo Task Runner macht es einfach, die von Ihnen erstellten Befehle zu dokumentieren, indem Sie Ihren Befehlen DocBlock-Kommentare hinzufügen, damit Sie für zukünftige Versionen von sich selbst Hilfe leisten können:

# Robo ohne Argumente zeigt die verfügbaren Befehle an.
Roboter

Verfügbare Befehle:
  help Zeigt Hilfe zu einem Befehl an
  list Listet Befehle auf
  profile Führen Sie eine Reihe von wp-cli-Befehlen in einer vorhandenen WordPress-Umgebung aus
  reset Setzt die WordPress-Umgebung auf einen bekannten Zustand zurück

Weitere Informationen zu einem bestimmten Befehl anfordern:

Robo-Hilfe zurückgesetzt

Beschreibung:
  Setzen Sie die WordPress-Umgebung auf einen bekannten Zustand zurück. Liest Umgebungen und Konfiguration 
  von robo.yml

Verwendungszweck:
  Optionen zurücksetzen]

Optionen:
      --env[=ENV] Umgebung (dev, test usw.) [Standard: "dev"]
      --multi Erstellt eine Multi-Site-Installation
      --ver[=VER] WordPress-Version [Standard: „neueste“]

Ich habe mit Robo einige leistungsstarke Befehle erstellt, die ich jeden Tag verwende, um meine WordPress-Entwicklungsumgebung zu verwalten. In diesem Artikel werde ich diese Befehle mit Ihnen teilen und dabei eine Einführung in die Robo-Befehle geben.

Robo vereinfacht die PHP-Befehlszeile

Lassen Sie uns den Rückspiegel nur ein wenig überprüfen. Das Schreiben von PHP-Kommandozeilenbefehlen ist sicherlich nicht neu. Es war schon immer möglich, ein PHP-Skript einfach wie folgt über die Befehlszeile auszuführen:

php myscript.php

Und PHP war, solange ich mich erinnern kann, in den meisten *NIX-Umgebungen als Befehlszeilenumgebung verfügbar. Das Hinzufügen des PHP-Shebangs funktioniert in den meisten Umgebungen, in denen der PHP-Interpreter installiert ist.

 // file: myscript #!/usr/bin/env php <?php // do stuff here…

Dadurch ist es möglich, das Skript von der Befehlszeile aus auszuführen, ohne anzugeben, dass es von PHP geparst werden soll (oder die Dateierweiterung .php einzuschließen):

myscript

Der Nachteil der Ausführung roher PHP-Skripte über die Befehlszeile besteht darin, dass in jedem Skript ziemlich viel Overhead für Ein- und Ausgabe anfällt. Der Prozess, Argumente von der Befehlszeile zu akzeptieren und dann die Nachrichten an die Befehlszeile auszugeben, ist etwas umständlich und fühlt sich nicht sehr flexibel an.

Robo macht es sich zum Ziel, das Schreiben von Befehlszeilen-PHP zu vereinfachen, indem es sich um einen Großteil der standardmäßigen „Installation“ kümmert, die die meisten Skripte benötigen. Dadurch können Sie sich auf die Kernfunktionalität Ihrer Skripte konzentrieren.

Robo installieren

Sie müssen Robo installieren, bevor wir beginnen können. Ich lasse Robo global auf meinem Computer installiert, also habe ich es so installiert:

Composer Global erfordert Konsolidierung/Robo

Aber wie bei allem, was über Composer installiert wird, können Sie es als Projektabhängigkeit beibehalten, wenn Sie sich damit wohler fühlen. Alternativ finden Sie auf GitHub Anweisungen zur Installation durch Herunterladen von robo.phar .

Dein erstes Kommando

Zuerst müssen wir Robo im Projektordner initialisieren:

cd /pfad/zu/meinprojekt
Robo-Init

Dies erstellt wirklich nur eine neue RoboFile.php in Ihrem Ordner mit folgendem Inhalt:

 <?php class RoboFile extends \Robo\Tasks { }

Um unseren ersten Befehl hinzuzufügen, fügen wir einfach eine öffentliche Methode hinzu:

 <?php class RoboFile extends \Robo\Tasks { public function hello($world) { $this->say("Hello, $world"); } }

Wie Sie wahrscheinlich erraten können, erstellt die obige Methode den Befehl hello und gibt einfach eine Nachricht auf dem Bildschirm aus.

Analysieren von Argumenten

Das einfache Hinzufügen dieser Methode, wie wir es oben getan haben, ist eine großartige Möglichkeit, einen der wichtigeren Gründe zu zeigen, warum ich Robo mag, nämlich das Analysieren von Befehlszeilenargumenten.

Um Ihnen zu zeigen, was ich meine, versuchen wir, diesen Befehl auszuführen:

Robo hallo

Nicht genug Argumente (fehlt: "world").

hallo [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [ -n|--nein
-interaction] [--simulate] [--progress-delay PROGRESS-DELAY] [-D|--define DEFINE] [--]

Aha! Robo gibt mir eine Fehlermeldung, weil der hello -Befehl tatsächlich einen $world Parameter erwartet und dann damit fortfährt, die vollständige Verwendungssyntax für den Befehl zu schreiben.

Ändern wir die Methode ein wenig und machen den Parameter optional:

 public function hello($world = 'from Robo') { $this->say("Hello, $world"); }

…und jetzt lassen wir es noch einmal laufen:

# Ohne Argumente
Robo hallo
Hallo, von Robo

# Mit einem einfachen Argument
Robo hallo!
Hallo!

# Mit einem Argument, das Leerzeichen enthält
Robo Hallo „Ich lebe auf der Kommandozeile“
Hallo, ich lebe auf der Kommandozeile

Das ist besser! Indem Sie den Parameter optional machen, führt Robo unsere Methode jetzt problemlos aus, auch ohne ein Argument zu übergeben. Wir haben auch gesehen, dass wir ein einfaches Argument und ein Argument in Anführungszeichen übergeben können, und es funktioniert einfach.

Wenn Sie jemals Zeit damit verbracht haben, Argumentprüfungslogik für ein Befehlszeilenskript zu schreiben, wissen Sie wahrscheinlich, warum dies eine nette Funktion ist. Es nimmt einfach viel Schmerz weg.

Der Beispielbefehl hello verwendet ein einzelnes Positionsargument. Robo unterstützt auch die Verwendung von Flags und benannten Argumenten, indem ein Array-Argument mit einigen Standardwerten erstellt wird.

Ändern wir die Funktion weiter, um optional einige zusätzliche Zeichen auszugeben:

 public function hello( $world = 'from Robo', $flags = [ 'stars' => false, 'stripes' => false ] ) { if ( $flags['stars'] ) $this->say( '***************' ); if ( $flags['stripes'] ) $this->say( '===============' ); $this->say( "Hello, $world" ); if ( $flags['stripes'] ) $this->say( '==============='); if ( $flags['stars'] ) $this->say( '***************' ); }

Dadurch wird Robo mitgeteilt, dass wir optional benannte Argumente mit doppelten Bindestrichen übergeben können:

# Nur durch Einfügen eines benannten Arguments erhält es den Wert 'true'
robo hallo - Sterne
 **************
 Hallo, von Robo
 **************

Eingang und Ausgang

Wir haben auch schon ein Beispiel mit IO gesehen. Die Funktion say() des Robo-Task-Objekts gibt einfach einen String an den Benutzer zurück. Es gibt auch eine ask() Funktion, mit der Sie den Benutzer um eine Eingabe bitten können:

 public function hello() { $word = $this->ask("Tell me what to say:"); $this->say( $word ); }
Robo hallo
? Sag mir, was ich sagen soll: foobar
foobar

Robo verwendet Symfony Console zum Erstellen von Benutzerinteraktionen. Das bedeutet, dass wir neben den beiden einfachen Funktionen say() und ask() Zugriff auf jede Funktion von Symfony Console haben, wie z. B. table() :

 public function table() { $this->io()->table( ['Header 1', 'Header 2'], [ ['Cell 1-1', 'Cell 1-2'], ['Cell 2-1', 'Cell 2-2'], ['Cell 3-1', 'Cell 3-2'], ] ); }
Robo-Tisch
---------- ----------
 Kopfzeile 1 Kopfzeile 2
---------- ----------
 Zelle 1-1 Zelle 1-2
 Zelle 2-1 Zelle 2-2
 Zelle 3-1 Zelle 3-2
---------- ----------

Ziemlich cool, oder?

Tolle Helfer

Ein weiterer Grund, Robo zu mögen, ist die integrierte Unterstützung für viele gängige Aufgaben, die das Schreiben von verständlichem Code erleichtert, selbst wenn Sie 3 Monate später darauf zurückkommen. Schauen wir uns an, wie Robo beim Schreiben von sehr sauberem Code für einige ziemlich standardmäßige Aufgaben hilft:

 # Create a directory, and switch to it: $this->taskExecStack() ->stopOnFail() ->exec('mkdir site') ->exec('cd site') ->run(); # Search and replace inside a text file: $this->taskReplaceInFile('VERSION') ->from('0.2.0') ->to('0.3.0') ->run(); # Run composer update: $this->taskComposerUpdate()->run(); # SSH into a server, go to a specific directory, list the contents of the directory, and set permissions on the logs subdirectory $this->taskSshExec('remote.example.com', 'user') ->remoteDir('/var/www/html') ->exec('ls -la') ->exec('chmod g+x logs') ->run();

All dies ist mit normalem PHP und der Funktion exec() möglich, aber das wird oft zu einer hoffnungslosen Übung, wenn es darum geht, Befehlszeichenfolgen zusammenzufügen und Argumente korrekt zu maskieren, ohne die Dinge zu sehr durcheinander zu bringen.

Neben den obigen Beispielen gibt es auch eine ähnliche Unterstützung für Git, Subversion, Rsync, Bower, Gulp, Docker, NPM und andere Tools, die häufig in Entwicklungsumgebungen verwendet werden.

Vorteile von Robo

Zusammengenommen macht Robo das Erstellen von Befehlszeilenskripten viel einfacher und das Endergebnis ist in der Regel semantisch ansprechender als einfaches PHP.

Ich finde, dass Skripte für Robo im Vergleich zu reinen PHP-Skripten leichter zu lesen und zu verstehen sind, weil so viel von den Boilerplates der Befehlszeile in Robo selbst versteckt ist. Persönlich kann ich mir nach ein paar Monaten meinen eigenen Code ansehen und mich ehrlich fragen, wer ihn geschrieben hat, also ist alles, was mir hilft, klaren, lesbaren Code zu schreiben, eine willkommene Ergänzung in meinem Werkzeuggürtel.

WordPress mit Robo pflegen

Der Rest dieses Artikels geht davon aus, dass Sie mit WP-CLI, der Verwendung von Composer und der Arbeit mit der Befehlszeile einigermaßen vertraut sind.

Die wichtigen Dateien

Es gibt vier wichtige Dateien in diesem Setup. Ich werde jeden von ihnen in diesem Beitrag behandeln:

  1. wp-cli.yml – Die Standard-WP-CLI-Konfigurationsdatei. Ich verwende dies, um einige der großartigen integrierten Funktionen von WP-CLI zu nutzen, wenn es um die Verwaltung mehrerer Umgebungen geht.
  2. RoboFile.php – Dies ist die Basisdatei zum Implementieren von Robo-Befehlen.
  3. robo.yml – Eine benutzerdefinierte YAML-Datei für einige zusätzliche Konfigurationsparameter für unsere Robo-Befehle.
  4. composer.json – Die standardmäßige Composer-Konfigurationsdatei.

Meine Umgebung

Um den Rest dieses Artikels vorzubereiten, werde ich kurz beschreiben, wie meine lokale Entwicklungsumgebung eingerichtet ist. Dies ist eine vereinfachte Version dessen, wie ich Dinge auf der Festplatte organisiert habe:

~/Quelle
├── devenv/
│ ├── RoboFile.php
│ ├── komponist.json
│ ├── wp-cli.yml
│ ├── robo.yml
│ ├── wordpress-dev/
│ └── WordPress-Test/    
├── plugin1/
│ ├── Vermögen/
│ └── beinhalten/
└── Plugin2
    └── ...

Im src -Ordner wird alles gespeichert, was mit der Entwicklung zu tun hat, und der devenv Ordner enthält Dateien, die für die tatsächliche Laufzeitumgebung spezifisch sind. Da ich normalerweise mehr als eine WordPress-Umgebung gleichzeitig laufen habe, hat jede WordPress-Installation einen eigenen Unterordner, der in diesem Beispiel wordpress-dev und wordpress-test heißt.

Jedes der Plugins, an denen ich arbeite, befindet sich in einem separaten Ordner pro Plugin.

In der realen Welt habe ich mehrere devenv-Ordner, damit ich meine Arbeit für Delicious Brains von verschiedenen Nebenprojekten trennen kann, aber das ist für diesen Artikel nicht relevant.

Datenbankbenutzer

Damit alles funktioniert, habe ich auch lokale Datenbanken für jede der WordPress-Installationen in meiner lokalen MySQL-Installation erstellt, und es gibt einen Datenbankbenutzer mit dem treffenden Namen wordpress mit dem richtigen Zugriff auf diese Datenbanken. Die genauen Details der Datenbanken sowie die Anmeldeinformationen des Benutzers sind in der Datei wp-cli.yml gespeichert.

Webserver

Ich verwende nginx als meinen lokalen Webserver, aber Sie werden feststellen, dass Apache2 genauso gut funktioniert. Meine nginx-Konfiguration ist so eingerichtet, dass http://www.wordpress-dev.local und http://www.wordpress-test.local auf die beiden oben genannten WordPress-Ordner zeigen.

Pflege von Abhängigkeiten

Um meine Robo-Skripte flexibler zu gestalten, verwende ich einige zusätzliche Funktionen, die über Composer installiert werden, insbesondere den Symfony Yaml-Parser. Da RoboFile.php wirklich nur eine normale PHP-Datei ist, kann ich beliebige Bibliotheken einbinden, und ich benutze natürlich Composer, um das zu tun. Die composer.json -Datei für dieses Projekt sieht folgendermaßen aus:

 { "require": { "symfony/yaml": "^5.2" } }

Wenn Sie das kopieren, vergessen Sie nicht, die Bibliothek tatsächlich mit composer update zu installieren.

Nutzung von wp-cli.yml

Wenn Sie mit WP-CLI arbeiten, können Sie das Leben viel einfacher machen, indem Sie eine Konfigurationsdatei wie wp-cli.yml . Ich verwende die WP-CLI-Konfigurationsdatei aus zwei Hauptgründen: Aliase und Einrichten von Standardeinstellungen für verschiedene Unterbefehle.

Was ist ein Alias ​​in WP-CLI?

Im Kern ist ein WP-CLI-Alias ​​nur eine Bezeichnung in der Konfigurationsdatei, mit der Sie einige der Standardeinstellungen überschreiben können.

Die häufigste Verwendung von path besteht wahrscheinlich darin, den Standardpfad zu überschreiben, sodass jeder Alias ​​auf eine separate WordPress-Installation verweist. Da jede WordPress-Installation eine eigene Konfigurationsdatei mit Datenbank-Anmeldeinformationen führt, repräsentiert der so verwendete Alias ​​auch eine separate Datenbank. Ein Alias ​​in der WP-CLI-Konfigurationsdatei kann die Einstellungen url , path , user , ssh und http überschreiben, aber er kann keine Standardwerte für Unterbefehle überschreiben.

Durch das Erstellen einer zusätzlichen WordPress-Umgebung mit dem Namen @test kann ich WP-CLI-Befehle wie folgt ausführen:

# Listet alle Plugins in der dev-WordPress-Installation auf
wp-Plugin-Liste

# Alle Plugins in der Test-WordPress-Installation auflisten
wp @test Plugin-Liste

Befehlsvorgaben

Wenn Sie dies noch nie versucht haben, ist das Einrichten von Standardparametern für Unterbefehle sehr praktisch. Wenn Sie beispielsweise eine neue WordPress-Konfigurationsdatei mit dem Befehl config create , müssen Sie jedes Mal mindestens drei Parameter angeben:

$ wp config create --dbname=somedb --dbuser=myuser --dbpass=secret

Wenn Sie es jemals satt haben, dies einzugeben, können Sie die Parameter in eine wp-cli.yml Datei einfügen:

 config create: dbuser: myuser dbpass: secret dbname: somedb

Sobald Sie das getan haben, können Sie einfach wp config create verwenden und es wird die richtigen Parameter aus Ihrer wp-cli.yml Datei abrufen.

Leider ist es nicht möglich, unterschiedliche Befehlsvorgaben für unterschiedliche Aliase einzurichten. Das war tatsächlich einer der Gründe, warum ich anfing, Robo für mehr Automatisierung in Betracht zu ziehen.

Meine WP-CLI-Konfigurationsdatei sieht so aus:

 # Global parameter defaults path: wordpress-dev url: http://www.wordpress-dev.local user: admin @test: path: wordpress-test url: www.wordpress-test.local # Subcommand defaults config create: dbuser: wordpress dbpass: ***** dbname: wordpress extra-php: | define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true); define( 'SCRIPT_DEBUG', true ); core install: admin_user: admin admin_password: admin admin_email: [email protected] title: WordPress Dev core multisite-install: admin_user: admin admin_password: admin admin_email: [email protected]

Mit nur dieser Konfigurationsdatei kann ich allgemeine Befehle ausführen, ohne jedes Mal die einzelnen Parameter angeben zu müssen:

# Setzen Sie die Datenbank in der Testumgebung zurück
wp @test db reset - ja

# Laden Sie die neueste Version herunter und erstellen Sie die Datei wp-config.php
wp @test core herunterladen
wp @test config erstellen

#WordPress installieren
wp @test core install --title="WordPress-Test"

Da WP-CLI die meisten Parameter aus der Konfigurationsdatei übernimmt, muss ich nicht alle Befehlszeilenparameter wie --dbuser und --admin_email , die ich normalerweise müsste.

Beachten Sie, dass ich im letzten Beispiel oben den title Parameter separat angegeben habe. Dies liegt daran, dass ich möchte, dass der Seitentitel in der Testumgebung anders ist, es aber nicht möglich ist, diesen Parameter mit einem Alias ​​zu überschreiben.

Erstellen benutzerdefinierter Robo-Befehle

Das Einrichten einer frischen WordPress-Installation reicht fast nie aus. Normalerweise müssen ein oder mehrere Plugins installiert und aktiviert werden und nicht selten müssen hier und da ein paar Einstellungen korrigiert werden.

Selbst mit einer sorgfältig geschriebenen WP-CLI-Konfigurationsdatei würde ich am Ende immer noch eine lange Reihe von Befehlen haben, wenn ich meine WordPress-Umgebung zurücksetzen und alles bereit machen möchte. Ich habe oft solche Sequenzen immer und immer wieder gemacht:

# Setzen Sie meine Entwicklungsumgebung zurück
wp db reset - ja
rm -rf Pfad/nach/wordpress
Wp-Core herunterladen
wp config erstellen
wp-core installieren
ln -s Pfad/zu/mein/plugin1 Pfad/zu/wordpress/wp-content/plugins/
wp plugin aktiviert plugin1

Selbst wenn Sie die WP-CLI-Konfigurationsdatei voll ausnutzen, ist dies eine Menge Tipparbeit. Um zu vermeiden, dass ich dies immer wieder eintippe und auch ab und zu falsch mache, habe ich zwei spezielle Befehle mit Robo erstellt, um dies für mich zu tun:

  • reset – Setzt eine WordPress-Umgebung auf einen bekannten Zustand zurück.
  • profile – Führt eine Reihe von Befehlen in einer vorhandenen Umgebung aus.

Da sich die Standardparameter des WP-CLI-Unterbefehls nicht auf verschiedene Befehlszeilenumgebungen erstrecken, können wir Robo verwenden, um diesen Vogel mit demselben Stein zu töten. Mal sehen wie.

Befehlskonfiguration

Unsere erste Station ist, einen Blick auf die Robo-Konfigurationsdatei zu werfen, die ich dafür erstellt habe. Es ist in YAML geschrieben, was das Verstehen und Erweitern recht einfach machen sollte. Ich werde jeden Abschnitt durchgehen, wenn wir zu dem Befehl kommen, der ihn verwendet:

 wordpress-dev: cli-prefix: "" path: "wordpress" core-multisite-install: title: WordPress Multisite post-install: - ln -s $cwd/../plugins1 $path/wp-content/plugins/ - ln -s $cwd/../plugins2 $path/wp-content/plugins/ wordpress-test: cli-prefix: "@test" path: "wordpress-test" config-create: dbname: wordpress-test core-install: title: WordPress Test core-multisite-install: title: WordPress Test Multisite post-install: - ln -s $cwd/../plugins1 $path/wp-content/plugins/ profiles: woocommerce: - $wp plugin install --activate woocommerce - $wp wc payment_gateway update cheque --enabled=true --user=admin - $wp option update woocommerce_calc_taxes yes - $wp wc tax create --name=VAT --rate=10 --user=admin - $wp wc shipping_zone_method create 0 --method_id=flat_rate --user=admin - $wp option update --format=json woocommerce_flat_rate_1_settings '{"title":"Flat rate","tax_status":"taxable","cost":"15"}' imageimport: - $wp media import $cwd/../media/lots-of-images/* issue2530: - $wp plugin install --activate some_plugin - $wp config set FOOBAR true --raw

Jede WordPress-Umgebung wird mit einem wordpress-$env Schlüssel identifiziert. Jeder Schlüssel kann mehrere Konfigurationswerte enthalten.

Der reset Befehl

Der erste Befehl wird reset . Es wird von der Befehlszeile aus wie folgt verwendet:

# Setzen Sie die Entwicklungsumgebung (Standard) zurück
Robo-Reset

# Oder expliziter sein
Robo-Reset –env=dev

# Setzen Sie die Testumgebung zurück
Robo-Reset –env=test

# Setzen Sie die Entwicklungsumgebung zurück und installieren Sie eine WordPress-Multisite
Robo-Reset --multi

# Setzen Sie die Entwicklungsumgebung auf eine bestimmte WordPress-Version zurück
Robo-Reset --ver=5.6.1

Als Erstes löscht dieser Befehl alle vorhandenen Dateien und Ordner im Ziel-WordPress-Installationsverzeichnis und setzt die konfigurierte WordPress-Datenbank zurück.

Dann verwendet der reset -Befehl die WP-CLI-Befehle core download , config create und je nach Option --multi core install oder core multisite-install .

Dabei werden so weit wie möglich die in der Datei wp-cli.yml enthaltenen Befehlsparameter-Standardwerte verwendet. Der Grund dafür ist, dass diese Standardeinstellungen auch hilfreich sind, wenn WP-CLI direkt ohne den Robo-Wrapper ausgeführt wird. Aber wie oben besprochen, ist es in manchen Fällen einfach nicht möglich.

Daher bietet die Konfigurationsdatei robo.yml die Möglichkeit, Überschreibungen für die Standardeinstellungen in wp-cli.yml. Wenn wir beispielsweise die @test-Umgebung installieren, möchten wir die Parameter für den core install --title . Wir können das tun, indem wir Folgendes in robo.yml :

 wordpress-test: ... ... core-install: title: WordPress Test ... ...

Die Syntax hier ist recht einfach: der CLI-Befehlsname (Leerzeichen durch Bindestriche ersetzt) ​​als Schlüssel und ein Unterschlüssel für jeden benannten Parameter. Das obige Beispiel würde den folgenden zusätzlichen Parameter für den Befehl „ core install cli“ generieren:

wp @test core install --title="WordPress-Test"

Schritte nach der Installation

Jeder Umgebungsschlüssel in der Konfigurationsdatei kann optional ein Array mit Schritten nach der Installation angeben. Dies ist einfach eine Liste von Bash-Befehlen, die ausgeführt werden, wenn die WordPress-Installation abgeschlossen ist. Für zusätzliche Flexibilität werden vor der Ausführung des Befehls einige Zeichenkettenersetzungen vorgenommen:

Schnur Ersetzt mit
$cwd Das aktuelle Arbeitsverzeichnis
$Pfad Der Pfad der Ziel-WordPress-Installation
$wp Der Befehl wp-cli, einschließlich des Alias-Präfix, dh wp @test
~ (Tilde-Symbol) Das HOME-Verzeichnis des aktuellen Benutzers

Ein Schritt nach der Installation von ln -s $cwd/../plugin1 $path/wp-content/plugins/ würde also einen Symlink von einem meiner Plugins-Ordner zum Plugins-Unterordner in der Ziel-WordPress-Installation erstellen.

Der profile

Der profile ist den Post-Installationsschritten ziemlich ähnlich, aber seine beabsichtigte Verwendung besteht darin, eine Reihe von Befehlen auf einer vorhandenen WordPress-Installation auszuführen. Nehmen wir an, Sie haben eine sehr einfache Entwicklungsumgebung, in der Sie den größten Teil Ihrer Arbeit erledigen. Manchmal müssen Sie jedoch das WooCommerce-Plugin installieren und einige grundlegende Einstellungen dafür vornehmen. Dafür ist der profile da. Es kann wie folgt verwendet werden:

# Setzen Sie die Entwicklungsumgebung zurück
Robo-Reset

# Installieren Sie WooCommerce und nehmen Sie einige Setup-Änderungen vor
Robo-Profil woocommerce

Die obige Beispieldatei robo.yml hat ein WooCommerce-Profil. Die Anwendung dieses Profils wird:

  • Installieren und aktivieren Sie WooCommerce mit WP-CLI.
  • Verwenden Sie den Unterbefehl wc , um ein Zahlungsgateway, eine Steuerzone und Versandeinstellungen einzurichten.
  • Verwenden Sie den option -Unterbefehl, um einige Einstellungen direkt in der WordPress-Optionstabelle zu ändern.

Die Verwendung verschiedener Profile ist sehr nützlich. Ich verbringe die meiste Zeit meiner Tage damit, am Plugin WP Offload Media zu arbeiten, und ich muss oft viele Bilder in die WordPress-Medienbibliothek importieren. WP-CLI hat dafür einen wirklich praktischen Befehl:

wp import media /some/long/path/I/often/forget/*

Da ich oft viel Zeug im Allgemeinen und lange Pfadnamen im Besonderen vergesse, fällt es mir leichter, mir zu merken:

Robo-Profilbildimport

Hier ist ein weiteres Beispiel. Ich habe an einem bestimmten GitHub-Problem gearbeitet, bei dem wir versuchen, ein Kompatibilitätsproblem zwischen unserem Plugin und einem anderen beliebten WordPress-Plugin zu beheben. Wenn ich an diesem Problem arbeite, muss ich dieses Plugin installieren und einen Konfigurationswert in wp-config.php. Also habe ich ein Profil dafür erstellt:

 .... issue2530: - $wp plugin install --activate some_plugin - $wp config set FOOBAR value

Jetzt kann ich meine Umgebung in einem Schritt einsatzbereit machen, nur robo profile issue2530 .

Genau wie die Schritte nach der post-install im Reset-Befehl ist jede Zeile in der Profildefinition eigentlich nur ein separater Bash-Befehl. Sie können es verwenden, um separate Skripte zu starten, Dateien zu löschen oder was auch immer Sie möchten. Es ist auch durchaus möglich, sich selbst in den Fuß zu schießen, treten Sie also vorsichtig auf.

Die Quelle

Wenn eines der oben genannten Dinge interessant zum Ausprobieren klingt, hier ist das RoboFile, das ich für alle oben genannten Dinge verwende, Sie können es gerne verwenden, um mit der Verwaltung von WordPress mit Robo zu beginnen.

 <?php use Robo\Symfony\ConsoleIO; use Robo\Tasks; use Symfony\Component\Yaml\Yaml; require_once 'vendor/autoload.php'; /** * Class RoboFile */ class RoboFile extends Tasks { /** * Reset the WordPress environment to a known state. Reads environments * and configuration from robo.yml * * @option env Environment (dev, test etc) * @option multi Make a multi site install * @option ver WordPress version * * @return bool */ public function reset( $opts = [ 'env' => 'dev', 'multi' => false, 'ver' => 'latest' ] ) { $env = $opts['env']; $version = $opts['ver']; $multi = $opts['multi']; $all_config = $this->read_yaml(); $key = "wordpress-$env"; if ( ! $this->ensure_basic_config( $all_config, $env ) ) { return false; } if ( ! isset( $all_config[ $key ]['path'] ) ) { $this->say( "No path set for environment $env." ); } $config = $all_config[ $key ]; $prefix = $config['cli-prefix']; $wp = trim( "wp $prefix" ); $path = $config['path']; $path = substr( $path, 0, 1 ) !== '/' ? __DIR__ . '/' . $path : $path; $version = $version === 'latest' ? '' : "--version=$version"; $config_create = $this->additional_parameters( 'config create', $config ); $install_cmd = $multi ? 'core multisite-install' : 'core install'; $install_params = $this->additional_parameters( $install_cmd, $config ); echo "$wp $install_cmd $install_params\n"; $this->taskExec( "$wp db reset --yes" )->run(); $this->taskExecStack() ->exec( "rm -rf $path/*" ) ->exec( "$wp core download $version" ) ->exec( "$wp config create $config_create" ) ->exec( "$wp config delete WP_DEBUG" ) ->exec( "$wp $install_cmd $install_params" ) ->run(); foreach ( $config['post-install'] as $cmd ) { $cmd = str_replace( '$wp', $wp, $cmd ); $cmd = str_replace( '$path', $path, $cmd ); $cmd = str_replace( '$cwd', __DIR__, $cmd ); $cmd = str_replace( '~', getenv( "HOME" ), $cmd ); echo $cmd . "\n"; $this->taskExec( $cmd )->run(); } } /** * Run a set of wp-cli commands on an existing WordPress environment * * @param string $profileName Name of the profile in robo.yml * * @option env Environment (dev, test etc) */ public function profile( $profileName, $opts = ['env' => 'dev']) { $env = $opts['env']; $all_config = $this->read_yaml(); $key = "wordpress-$env"; if ( ! $this->ensure_basic_config( $all_config, $env ) ) { return false; } $config = $all_config[ $key ]; $prefix = $config['cli-prefix']; $wp = trim( "wp $prefix" ); $path = $config['path']; $path = substr( $path, 0, 1 ) !== '/' ? __DIR__ . '/' . $path : $path; if ( ! isset( $all_config['profiles'][ $profileName ] ) ) { $this->say( "Profile $profileName not found" ); return false; } $profile = $all_config['profiles'][ $profileName ]; foreach ( $profile as $cmd ) { $cmd = str_replace( '$wp', $wp, $cmd ); $cmd = str_replace( '$path', $path, $cmd ); $cmd = str_replace( '$cwd', __DIR__, $cmd ); $cmd = str_replace( '~', getenv( "HOME" ), $cmd ); // Quick and dirty. If the cmd exactly matches another profile, run it! if ( isset( $all_config['profiles'][ $cmd ] ) ) { $this->profile( $cmd, $env ); continue; } echo $cmd . "\n"; $this->taskExec( $cmd )->run(); } } /** * @return array */ private function read_yaml() { return Yaml::parseFile( __DIR__ . '/robo.yml' ); } /** * @param $config * @param $env * * @return bool */ private function ensure_basic_config( $config, $env ) { $key = "wordpress-$env"; if ( ! isset( $config[ $key ] ) ) { $this->say( "No path set for environment $env." ); return false; } if ( ! isset( $config[ $key ]['cli-prefix'] ) ) { $this->say( "No wp-cli prefix set for environment $env." ); return false; } return true; } /** * @param string $name * @param array<string, string> $config * * @return string */ private function additional_parameters( $name, $config ) { $name = str_replace( ' ', '-', $name ); if ( ! isset( $config[ $name ] ) ) { return ''; } return implode( ' ', array_map( function ( $v, $k ) { return sprintf( "--%s='%s'", $k, $v ); }, $config[ $name ], array_keys( $config[ $name ] ) ) ); } }

Einpacken

In der Entwicklung gehen sich wiederholende Aufgaben in der Regel mit dem Territorium einher. Ich sehe keine Möglichkeit, sie vollständig abzuschaffen, aber die Automatisierung so vieler wie möglich hilft Ihnen wirklich, so viel echte Arbeit wie möglich mit der verfügbaren Zeit zu erledigen.

Die Automatisierung einiger dieser Aufgaben mit der Kombination aus WP-CLI und Robo, die ich hier skizziert habe, hat mir als Plugin-Entwickler jeden Tag Zeit gespart. Ich könnte nie wieder zurückgehen, um diese Dinge manuell zu erledigen.

Welche Tools verwenden Sie, um die mühsamsten Teile Ihres Entwicklungsworkflows zu automatisieren? Lass es mich in den Kommentaren wissen.