In diesem Beitrag zeige ich eine einfache Lösung, wie Du mit Docker, Gitlab und PhpStorm eine schnelle, lokale Entwicklungsumgebung einrichtest. Dies ist vor allem dann ganz gut, wenn Du ein WordPress-Template oder -Plugin entwickeln möchtest.
Kurz gesagt: Im Anschluss wirst Du Deine Projekt-Daten für Dein Template oder Plugin auf Gitlab.com ablegen und entwickelst dabei dein Projekt lokal auf Deinem Rechner. Der komplette WordPress-Code wird dabei natürlich nicht via git getrackt. PhpStorm eignet sich für die WordPress-Entwicklung sehr gut – Du kannst allerdings auch jeden anderen Editor verwenden. Dabei musst du eben die Docker-Befehle von Hand eingeben. Es ist allerdings so oder so eine gute Idee, die einzelnen Docker-Befehle manuell zumindest kennenzulernen.
Step 1: Anlegen des Gitlab-Projekts & Anlegen der Docker-Compose-Datei
Entweder nutzt Du ein neues Projekt auf https://gitlab.com oder Du legst ein neues Projekt auf Deiner selbstgehosteten Gitlab-Installation an. Im neu angelegten Gitlab-Projekt kannst Du jetzt eine neue Datei anlegen. Diese nennst Du docker-compose.yml.
Inhalt der Datei:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
services:
db:
image: mysql:5.7
volumes:
- db_data:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: somewordpress
MYSQL_DATABASE: wordpress
MYSQL_USER: wordpress
MYSQL_PASSWORD: wordpress
wordpress:
depends_on:
- db
image: wordpress
ports:
- "666:80"
restart: always
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_USER: wordpress
WORDPRESS_DB_PASSWORD: wordpress
working_dir: /var/www/html
volumes:
- ./:/var/www/html
- ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
volumes:
db_data:
Erklärung:
image: Es werden hier zwei Docker-Container definiert und verbunden. Für diesen Test habe ich das Standard-Wordpress-Image genutzt. Das bedeutet, dass jeweils die aktuellste WordPress-Version gezogen wird. In den allermeisten Fällen ist dies auch am sinnvollsten – es sei denn, man möchte ein Plugin oder Theme für eine ältere WP-Version testen oder entwickeln.
volumes: Mit Volumes können Verzeichnisse aus den Docker-Containern in das lokale Verzeichnis gemountet werden. Ich lade i.d.R. das komplette WordPress-Verzeichnis in die Projekt-Root, so dass ich auch später die WordPress-Erweiterungen von PHP-Storm nutzen kann (und bei Bedarf Zugriff auf WP-Core-Dateien habe).
Es ist allerdings auch denkbar, dass Du Dir hier _nur_ Dein Plugin oder Theme in die Projekt-Root lädst, oder gar die WordPress-Installation in ein anderes Verzeichnis in der Projekt-Root lädst. Folgende Alternativen wären hier denkbar:
– ./wordpress:/var/www/html – Die WordPress-Installation ins lokale Verzeichnis wordpress laden.
– ./:/var/www/html/wp-content/plugins/myplugin – nur „myplugin“ wird in die lokale Projekt-Root geladen
Step 2: PhpStorm-Projekt anlegen, Code aus Git holen
Beim Start von PhpStorm legst Du jetzt ein neues Projekt über den Listen-Eintrag „Get from Version Control“ an. Hierbei benötigst Du die Clone-URL aus gitlab.com. Außerdem sollte dein lokaler SSH-Schlüssel in deinem Repository eingetragen sein. Alternativ fragt PhpStorm beim clonen aber auch nach Benutzernamen und Passwort – die SSH-Verbindung ist allerdings m.E. die einfachere Methode.
Im Anschluss wird das Projektverzeichnis automatisch erstellt und die Projektdatei (docker-compose.yml) in dieses Verzeichnis geladen. Nach dem Clone-Vorgang kannst Du auf „yes“ klicken – das Projekt wird jetzt via PhpStorm geöffnet („Would you like to open the directory…?“).
Als nächstes definieren wir Docker für das Projekt (Docker für Windows, Linux oder Mac solltest Du natürlich bereits installiert und gestartet haben – Standard-Einstellungen).
Über das Plus-Zeichen (siehe Screenshot oben) kannst du eine neue Docker-Konfiguration hinzufügen. Die obigen Einstellungen werden schon so automatisch ausgefüllt (funktioniert entsprechend auch unter Linux und Mac OS). Nachdem die Einstellungen wie oben passen, kannst Du den Settings-Dialog auch schon wieder per Klick auf „OK“ schließen.
Step 3: Docker-Setup starten
In den Projekt-Dateien kannst Du jetzt automatisch via Rechtsklick auf die docker-compose.yml das Docker-Setup starten. Wenn Du dies machst, passiert folgendes: Die beiden definierten Docker-Container werden gestartet und eine WordPress-Installation wird durchgeführt. Je nach Einstellung in der docker-compose.yml-Datei werden hierbei auch automatisch die notwendigen Ports gemappt. Sprich: WordPress läuft über den Webserver-Container innerhalb des Docker-Netzes. Da wir nur jeweils einen Port 80 zur Verfügung haben, aber ggf. mehrere Webservices via Docker laufen lassen, mappen wir den Port 80 einfach auf einen alternativen Port. Im Beispielsfall von oben ist dies Port 666. Die vorläufige WordPress-Grundinstallation erreichst du ab jetzt also über die URL http://localhost:666 in deinem Browser.
Wenn das Setup geklappt hat, siehst du im unteren Bereich von PhpStorm die Erfolgsmeldung „Compose: docker-compose.yml has been deployed successfully“ im Abschnitt Deploy Log. Natürlich bemerkst Du es auch dann, wenn du im Browser die WordPress-Einrichtungs-Seite unter http://localhost:666 erreichst.
Was ist noch passiert? Je nachdem, wie die Volumes-Config (siehe Step 1) aussehen, werden nun auch sämtliche WordPress-Dateien in der Projekt-Root angezeigt. Im Settings-Dialog von PhpStorm kann man jetzt also auch den WordPress-Support aktivieren.
Step 4: Was wird getrackt, was wird ignoriert?
Bereits weiter oben hatte ich schon erwähnt, dass es nicht sehr sinnvoll ist, irgendwelchen WordPress-Core-Code via git zu tracken, da dieser natürlich kontinuierlich weiterentwickelt wird und sich ggf. auch hier und da verändert.
Wichtig ist an dieser Stelle auch, dass Du am Besten gar keine WordPress-Core-Updates über das Web-Interface installierst, sondern stattdessen immer gleich ein neues Docker-Image ziehst (einfach das Setup erneut ausführen – die bestehenden Docker-Container entfernen).
An dieser Stelle kommt jetzt die Datei „.gitignore“ ins Spiel. Mit dieser Datei kannst Du Dateien aus dem Git-Tracking ausschließen. Im Grunde wollen wir alles ignorieren, außer die Verzeichnisse für unser Plugin und/oder Theme. Hinweis: Die .gitignore sollte natürlich mit ins GIT-Repository aufgenommen werden (git add .gitignore).
2
3
4
5
6
7
8
9
10
11
12
13
14
# IntelliJ project files
.idea
*.iml
out
gen
# Alles ignorieren
/*
.*
# Ausnahmen definieren
!.gitignore
!README.md
/wp-content/*
!/wp-content/themes/powermetal/
Zusatz
Für die lokale Docker-Entwicklung wird früher oder später das Problem auftauchen, dass du entweder die lokal gemounteten Dateien nicht bearbeiten kannst, oder dass du Plugins in WordPress (Docker) nicht ohne FTP-Zugang hinzufügen kannst, weil die Dateirechte nicht passen. Im Docker-Container werden die Dateirechte vom Image aus dem Benutzer und der Gruppe www-data zugewiesen. Dies kann, muss aber nicht dieselbe Benutzer-ID wie auf deinem lokalen System sein. Die Berechtigungen kannst du Anpassen, in dem du direkt auf eine Shell in den Docker-Container verbindest. Dies passiert mit dem folgenden Kommando:
1 | docker exec -u root -it [DOCKER-ID] /bin/bash |
Die [DOCKER-ID] erhältst du über das folgende Kommando:
2
3
4
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4867c885db42 wordpress "docker-entrypoint.s…" 32 hours ago Up Less than a second 0.0.0.0:666->80/tcp pmwp_wordpress_1
bd78c4dbe73d mysql:5.7 "docker-entrypoint.s…" 32 hours ago Up Less than a second 3306/tcp, 33060/tcp pmwp_db_1
Die Docker-ID ist die Zeichenfolge in der ersten Tabellen-Spalte. In meinem Fall würde das Kommando für die Shell zum Docker-Container (wordpress) also wie folgt lauten:
In der Shell können dann die Dateirechte beispielsweise via chmod und chown angepasst werden. WordPress befindet sich im Standard-Image im Verzeichnis /var/www/html.
