Mehrere WordPress-Sites lokal mit DevKinsta erstellen

Dieser Artikel wurde freundlicherweise von unseren lieben Freunden bei DevKinsta unterstützt, die so vielen Entwicklern, Webdesignern und Freiberuflern helfen, ihre WordPress-Websites aus der ganzen Welt zu entwerfen, zu entwickeln und bereitzustellen. Danke!

Beim Erstellen von Themen und Plugins für WordPress müssen wir sicherstellen, dass sie in all den verschiedenen Umgebungen, in denen sie installiert werden, gut funktionieren. Manchmal können wir diese Umgebung kontrollieren, wenn wir ein Design für unsere eigenen Websites erstellen, aber manchmal nicht, z. B. wenn wir unsere Plugins über das öffentliche WordPress-Repository verteilen, damit jeder sie herunterladen und installieren kann.

In Bezug auf WordPress umfassen die möglichen Kombinationen von Umgebungen , um die wir uns Sorgen machen müssen, Folgendes:

• Verschiedene Versionen von PHP,
• Verschiedene Versionen von WordPress,
• Verschiedene Versionen des WordPress-Editors (auch bekannt als Block-Editor),
• HTTPS aktiviert/deaktiviert,
• Multisite aktiviert/deaktiviert.

Mal sehen, wie das der Fall ist. PHP 8.0, die neueste Version von PHP, hat bahnbrechende Änderungen gegenüber den vorherigen Versionen eingeführt. Da WordPress noch offiziell PHP 5.6 unterstützt, muss unser Plugin möglicherweise 7 Versionen von PHP unterstützen: PHP 5.6 plus PHP 7.0 bis 7.4 plus PHP 8.0. Wenn das Plugin eine bestimmte Funktion von PHP benötigt, wie z. B. typisierte Eigenschaften (eingeführt in PHP 7.4), muss es diese Version von PHP und höher unterstützen (in diesem Fall PHP 7.4 und PHP 8.0).

In Bezug auf die Versionierung in WordPress kann diese Software selbst gelegentlich bahnbrechende Änderungen einführen, wie z. B. das Update auf eine neuere Version von jQuery in WordPress 5.6. Darüber hinaus führt jede Hauptversion von WordPress neue Funktionen ein (z. B. den neuen Gutenberg-Editor, der in Version 5.0 eingeführt wurde), die für unsere Produkte erforderlich sein könnten.

Der Blockeditor ist da keine Ausnahme. Wenn unsere Themes und Plugins benutzerdefinierte Blöcke enthalten, ist es unerlässlich, sie für alle verschiedenen Versionen zu testen. Zumindest müssen wir uns um zwei Versionen von Gutenberg kümmern: die im WordPress-Kern ausgelieferte und die als eigenständiges Plugin verfügbare.

In Bezug auf HTTPS und Multisite könnten sich unsere Themes und Plugins unterschiedlich verhalten, je nachdem, ob diese aktiviert sind oder nicht. Beispielsweise möchten wir möglicherweise den Zugriff auf einen REST-Endpunkt deaktivieren, wenn HTTPS nicht verwendet wird, oder dem Superadministrator erweiterte Funktionen von der Multisite bereitstellen.

Das bedeutet, dass es viele mögliche Umgebungen gibt, um die wir uns kümmern müssen. Wie gehen wir damit um?

Die Umgebungen herausfinden

Alles, was automatisiert werden kann, muss automatisiert werden. Um beispielsweise die Logik unserer Themen und Plugins zu testen, können wir einen kontinuierlichen Integrationsprozess erstellen, der eine Reihe von Tests in mehreren Umgebungen durchführt. Die Automatisierung nimmt einen großen Teil des Schmerzes weg.

Wir können uns jedoch nicht darauf verlassen, dass Maschinen die ganze Arbeit für uns erledigen. Wir müssen auch auf eine WordPress-Testseite zugreifen, um zu sehen, ob unsere Themen nach einem Software-Upgrade immer noch wie beabsichtigt aussehen. Wenn Gutenberg beispielsweise sein globales Stilsystem aktualisiert oder wie sich ein Kernblock verhält, möchten wir überprüfen, ob unsere Produkte von der Änderung nicht betroffen sind.

Wie viele verschiedene Umgebungen müssen wir unterstützen? Nehmen wir an, wir zielen auf 4 Versionen von PHP (7.2 bis 8.0), 5 Versionen von WordPress (5.3 bis 5.7), 2 Versionen von Gutenberg (Core/Plugin), HTTPS aktiviert/deaktiviert und Multisite ein/aus ab. Das alles ergibt insgesamt 160 mögliche Umgebungen. Das ist viel zu viel zu handhaben.

Anstatt für jede mögliche Kombination eine Site zu erstellen, können wir sie der Einfachheit halber auf eine Handvoll Umgebungen reduzieren, die insgesamt alle verschiedenen Eigenschaften umfassen.

Beispielsweise können wir diese fünf Umgebungen erstellen:

1. PHP 7.2 + WP 5.3 + Gutenberg-Kern + HTTPS + Multisite
2. PHP 7.3 + WP 5.4 + Gutenberg-Plugin + HTTPS + Multisite
3. PHP 7.4 + WP 5.5 + Gutenberg-Plugin + kein HTTPS + keine Multisite
4. PHP 8.0 + WP 5.6 + Gutenberg-Kern + HTTPS + keine Multisite
5. PHP 8.0 + WP 5.7 + Gutenberg-Kern + kein HTTPS + keine Multisite

Das Erstellen von 5 WordPress-Sites ist überschaubar, aber es ist nicht einfach, da es technische Herausforderungen mit sich bringt, insbesondere das Aktivieren verschiedener PHP-Versionen und das Bereitstellen von HTTPS-Zertifikaten.

Wir möchten WordPress-Sites einfach erstellen, auch wenn wir nur begrenzte Systemkenntnisse haben. Und wir wollen es schnell machen, denn wir haben unsere Entwicklungs- und Konstruktionsarbeit zu erledigen. Wie können wir das machen?

Lokale WordPress-Sites mit DevKinsta verwalten

Glücklicherweise ist das Hochfahren lokaler WordPress-Sites heutzutage nicht schwierig, da wir die manuelle Arbeit vermeiden und uns stattdessen auf ein Tool verlassen können, das den Prozess für uns automatisiert.

DevKinsta ist genau so ein Tool. Es ermöglicht, mit minimalem Aufwand eine lokale WordPress-Site für jede gewünschte Konfiguration zu starten. Die Website wird in kürzerer Zeit erstellt, als es dauert, eine Tasse Kaffee zu trinken. Und es kostet sicherlich weniger als eine Tasse Kaffee: DevKinsta ist 100 % kostenlos und für Benutzer von Windows, macOS und Ubuntu verfügbar .

Wie der Name schon sagt, wurde DevKinsta von Kinsta erstellt, einem der führenden Hosting-Anbieter im WordPress-Bereich. Ihr Ziel ist es, die Arbeit mit WordPress-Projekten zu vereinfachen, sei es für Designer oder Entwickler, Freiberufler oder Agenturen. Je einfacher wir unsere Umgebung einrichten können, je mehr wir uns auf unsere eigenen Themen und Plugins konzentrieren können, desto besser werden unsere Produkte.

Die Magie, die DevKinsta antreibt, ist Docker, die Software, die es ermöglicht, eine App über Container von ihrer Umgebung zu isolieren. Wir müssen jedoch nichts über Docker oder Container wissen: DevKinsta verbirgt die zugrunde liegende Komplexität, sodass wir die WordPress-Site einfach auf Knopfdruck starten können.

In diesem Artikel werden wir untersuchen, wie man DevKinsta verwendet, um die 5 verschiedenen lokalen WordPress-Instanzen zum Testen eines Plugins zu starten, und welche netten Funktionen wir zur Verfügung haben.

Starten einer WordPress-Site mit DevKinsta

Die Bilder von oben zeigen DevKinsta beim ersten Öffnen. Es bietet 3 Optionen zum Erstellen einer neuen lokalen WordPress-Site:

1. Neue WordPress-Seite
   Es verwendet die Standardkonfiguration, einschließlich der neuesten WordPress-Version und PHP 8.
2. Import von Kinsta
   Es klont die Konfiguration von einer bestehenden Website, die bei MyKinsta gehostet wird.
3. Benutzerdefinierte Website
   Es verwendet eine benutzerdefinierte Konfiguration, die von Ihnen bereitgestellt wird.

Wenn Sie auf Option 1 drücken, wird buchstäblich eine lokale WordPress-Site erstellt, ohne darüber nachzudenken. Ich könnte es ein bisschen weiter erklären, wenn ich nur könnte; mehr ist da wirklich nicht drin.

Wenn Sie zufällig ein Kinsta-Benutzer sind, können Sie durch Drücken auf Option #2 eine Website direkt von MyKinsta importieren, einschließlich eines Dumps ihrer Datenbank. (Übrigens funktioniert es auch in die entgegengesetzte Richtung: Lokale Änderungen in DevKinsta können auf eine Staging-Site in MyKinsta gepusht werden.)

Wenn wir schließlich auf Option 3 klicken, können wir angeben, welche benutzerdefinierte Konfiguration für die lokale WordPress-Site verwendet werden soll.

Lassen Sie uns die Taste für Option #3 drücken. Der Konfigurationsbildschirm sieht folgendermaßen aus:

Einige Eingaben sind schreibgeschützt. Dies sind Optionen, die derzeit festgelegt sind, aber irgendwann in der Zukunft konfigurierbar gemacht werden. Beispielsweise ist der Webserver derzeit auf Nginx eingestellt, aber es wird daran gearbeitet, Apache hinzuzufügen.

Die Optionen, die wir derzeit konfigurieren können, sind die folgenden:

• Der Name der Site (aus dem die lokale URL berechnet wird),
• PHP-Version,
• Name der Datenbank,
• HTTPS aktiviert/deaktiviert,
• Der Titel der WordPress-Seite,
• WordPress-Version,
• E-Mail, Benutzername und Passwort des Administrators,
• Multisite aktiviert/deaktiviert.

Nachdem ich diese Informationen für meine erste lokale WordPress-Site namens „GraphQL API on PHP 80“ ausgefüllt und auf „Site erstellen“ geklickt hatte, dauerte es nur 2 Minuten, bis DevKinsta die Site erstellt hatte. Dann wird mir der Infobildschirm für die neu erstellte Site angezeigt:

Die neue WordPress-Site ist unter einer eigenen lokalen Domain graphql-api-on-php80.local . Durch Klicken auf die Schaltfläche „Website öffnen“ können wir unsere neue Website im Browser anzeigen:

Ich habe diesen Vorgang für alle verschiedenen erforderlichen Umgebungen wiederholt, und voila, meine 5 lokalen WordPress-Sites waren im Handumdrehen einsatzbereit. Nun listet der Startbildschirm von DevKinsta alle meine Seiten auf:

Verwenden von WP-CLI

Von der erforderlichen Konfiguration für meine Umgebungen habe ich bisher alle Punkte erfüllt, bis auf einen: die Installation von Gutenberg als Plugin.

Lassen Sie uns dies als nächstes tun. Wir können ein Plugin wie gewohnt über den WP-Admin installieren, auf den wir zugreifen können, indem wir auf dem Site-Info-Bildschirm auf die Schaltfläche „WP-Admin“ klicken, wie im obigen Bild zu sehen.

Noch besser, DevKinsta wird mit bereits installiertem WP-CLI ausgeliefert, sodass wir über die Befehlszeilenschnittstelle mit der WordPress-Site interagieren können.

In diesem Fall benötigen wir minimale Docker-Kenntnisse. Das Ausführen eines Befehls innerhalb eines Containers erfolgt folgendermaßen:

 docker exec {containerName} /bin/bash -c '{command}'

Die benötigten Parameter sind:

• Der Container von DevKinsta heißt devkinsta_fpm .
• Der WP-CLI-Befehl zum Installieren und Aktivieren eines Plugins lautet wp plugin install {pluginName} --activate --path={pathToSite} --allow-root
• Der Pfad zur WordPress-Site innerhalb des Containers lautet /www/kinsta/public/{siteName} .

Alles in allem lautet der Befehl zum Installieren und Aktivieren des Gutenberg-Plugins auf der lokalen WordPress-Site dieser:

 docker exec devkinsta_fpm /bin/bash -c 'wp plugin install gutenberg --activate --path=/www/kinsta/public/MyLocalSite --allow-root'

Erkunden von Merkmalen

Für unsere lokalen WordPress-Sites stehen einige praktische Funktionen zur Verfügung.

Die erste ist die Integration mit Adminer, einem Tool ähnlich phpMyAdmin, um die Datenbank zu verwalten. Mit diesem Tool können wir die Daten direkt über eine benutzerdefinierte SQL-Abfrage abrufen und bearbeiten. Durch Klicken auf die Schaltfläche „Datenbankmanager“ auf dem Site-Info-Bildschirm wird Adminer in einem neuen Browser-Tab geöffnet:

Die zweite bemerkenswerte Funktion ist die Integration mit Mailhog, dem beliebten E-Mail-Testtool. Dank dieses Tools wird jede E-Mail, die von der lokalen WordPress-Site gesendet wird, nicht wirklich versendet, sondern erfasst und im E-Mail-Posteingang angezeigt:

Wenn wir auf eine E-Mail klicken, können wir ihren Inhalt sehen:

Zugriff auf die lokalen Installationsdateien

Nach der Installation der lokalen WordPress-Site ist ihr Ordner mit all ihren Dateien (einschließlich WordPress-Kern, installierten Designs und Plugins und hochgeladenen Medienelementen) öffentlich verfügbar:

• Mac und Linux: unter /Users/{username}/DevKinsta/public/{siteName} .
• Windows: unter C:\Users\{username}\DevKinsta\public\{siteName} .

(Mit anderen Worten: Auf die Dateien der lokalen WordPress-Site kann nicht nur über den Docker-Container zugegriffen werden, sondern auch über das Dateisystem in unserem Betriebssystem, z. B. über My PC unter Windows, Finder unter Mac oder ein beliebiges Terminal.)

Dies ist sehr praktisch, da es eine Verknüpfung zum Installieren der von uns entwickelten Themen und Plugins bietet und unsere Arbeit beschleunigt.

Um beispielsweise eine Änderung an einem Plugin auf allen 5 lokalen Sites zu testen, müssten wir normalerweise zum WP-Admin auf jeder Site gehen und die neue Version des Plugins hochladen (oder alternativ WP-CLI verwenden).

Durch den Zugriff auf den Ordner der Website können wir das Plugin jedoch einfach aus seinem Repo klonen, direkt unter wp-content/plugins :

 $ cd ~/DevKinsta/public/MyLocalSite/wp-content/plugins $ git clone [email protected]:leoloso/MyAwesomePlugin.git

Auf diese Weise können wir unser Plugin einfach git pull auf die neueste Version aktualisieren und es sofort auf der lokalen WordPress-Site verfügbar machen:

 $ cd MyAwesomePlugin $ git pull

Wenn wir das in Entwicklung befindliche Plugin auf einem anderen Zweig testen möchten, können wir auf ähnliche Weise einen git checkout durchführen:

 git checkout some-branch-with-new-feature

Da wir möglicherweise mehrere Sites mit unterschiedlichen Umgebungen haben, können wir diesen Vorgang automatisieren, indem wir ein Bash-Skript ausführen, das die lokalen WordPress-Sites iteriert und für jede einen git pull für das darin installierte Plugin ausführt:

 #!/bin/bash iterateSitesAndGitPullPlugin(){ cd ~/DevKinsta/public/ for file in * do if [ -d "$file" ]; then cd ~/DevKinsta/public/$file/wp-content/plugins/MyAwesomePlugin git pull fi done } iterateSitesAndGitPullPlugin

Fazit

Bei der Gestaltung und Entwicklung unserer WordPress-Themes und Plugins möchten wir uns so weit wie möglich auf unsere eigentliche Arbeit konzentrieren können. Wenn wir die Einrichtung der Arbeitsumgebung automatisieren können, können wir die zusätzliche Zeit und Energie in unser Produkt investieren.

Das macht DevKinsta möglich. Wir können eine lokale WordPress-Site durch einfaches Drücken einer Schaltfläche erstellen und in nur wenigen Minuten viele Sites mit unterschiedlichen Umgebungen erstellen.

DevKinsta wird aktiv weiterentwickelt und unterstützt. Wenn Sie auf ein Problem stoßen oder eine Frage haben, können Sie die Dokumentation durchsuchen oder zum Community-Forum gehen, wo die Entwickler von DevKinsta Ihnen helfen werden.

All dies kostenlos. Klingt gut? Wenn ja, laden Sie DevKinsta herunter und starten Sie Ihre lokalen WordPress-Sites.