Du möchtest WordPress ausprobieren, ein neues Plugin testen oder Änderungen an deiner Website vornehmen, ohne dabei deine echte Website zu gefährden?

Dann ist eine lokale WordPress-Installation ideal.

Mit Docker können wir WordPress und die benötigte Datenbank auf dem eigenen Rechner starten, ohne PHP, MariaDB und einen Webserver einzeln installieren und konfigurieren zu müssen.

In dieser Anleitung beginnen wir wirklich bei null.

Wir installieren Docker unter Windows, Ubuntu oder macOS und starten anschließend eine komplette lokale WordPress-Installation.

Was wir am Ende haben

#

Unsere Testumgebung besteht aus zwei Containern:

Browser
   │
   │ localhost:8080
   ▼
WordPress
   │
   ▼
MariaDB

WordPress läuft anschließend unter:

http://localhost:8080

Die Installation befindet sich nur auf unserem Rechner und eignet sich hervorragend zum Experimentieren.

Was ist Docker?

#

Normalerweise benötigt WordPress mehrere Komponenten:

Webserver
PHP
WordPress
Datenbank

Man könnte diese Programme einzeln auf dem eigenen Rechner installieren.

Für eine Testumgebung ist das häufig unnötig aufwendig.

Docker verpackt die benötigten Komponenten in sogenannte Container.

Für unsere Installation verwenden wir einen WordPress-Container und einen MariaDB-Container.

Der große Vorteil:

Die eigentliche WordPress-Konfiguration ist anschließend unter Windows, Linux und macOS praktisch identisch.

Nur die Installation von Docker unterscheidet sich.

Docker unter Windows installieren

#

Unter Windows ist Docker Desktop der einfachste Einstieg.

Docker Desktop stellt Docker Engine, die Kommandozeilenwerkzeuge und Docker Compose bereit.

Für aktuelle Windows-Systeme verwendet Docker Desktop normalerweise WSL 2 als technische Grundlage.

WSL steht für Windows Subsystem for Linux.

Damit kann Windows eine Linux-Umgebung bereitstellen, in der die Linux-Container von Docker laufen.

WSL prüfen

#

Öffne PowerShell oder Windows Terminal.

Prüfe zunächst:

wsl --status

Falls WSL noch nicht eingerichtet ist, kann es auf unterstützten Windows-Versionen beispielsweise mit folgendem Befehl installiert werden:

wsl --install

Anschließend kann ein Neustart erforderlich sein.

Docker Desktop installieren

#

Lade Docker Desktop von der offiziellen Docker-Website herunter und führe die Installation aus.

Während der Einrichtung verwenden wir die WSL-2-basierte Konfiguration.

Nach der Installation starten wir Docker Desktop.

Im Terminal können wir anschließend prüfen:

docker --version

und:

docker compose version

Wenn beide Befehle eine Versionsnummer ausgeben, können wir weitermachen.

Docker unter Ubuntu installieren

#

Unter Ubuntu benötigen wir für unsere WordPress-Testumgebung keine grafische Docker-Desktop-Anwendung.

Docker Engine und das Compose-Plugin reichen aus.

Docker stellt für Ubuntu ein eigenes Paket-Repository bereit. Für eine dauerhaft genutzte Installation würde ich dieses gegenüber irgendwelchen zufälligen Installationsskripten bevorzugen.

Die jeweils aktuellen Installationsschritte sollten direkt in der offiziellen Docker-Dokumentation geprüft werden, da sich Paketnamen und unterstützte Ubuntu-Versionen ändern können.

Nach der Installation prüfen wir:

docker --version

und:

docker compose version

Docker ohne sudo verwenden

#

Je nach Installation benötigt Docker unter Linux zunächst sudo.

Docker kann so konfiguriert werden, dass der eigene Benutzer Docker-Befehle ohne sudo ausführen kann.

Dabei sollte man wissen, dass die Mitgliedschaft in der Docker-Gruppe weitreichende Rechte auf dem Rechner ermöglicht.

Für einen privaten Entwicklungsrechner ist diese Konfiguration verbreitet, sie sollte aber nicht als bedeutungslose Komfortoption betrachtet werden.

Docker unter macOS installieren

#

Unter macOS ist Docker Desktop ebenfalls der unkomplizierte Weg.

Dabei muss die passende Version für die verwendete Mac-Hardware gewählt werden.

Aktuelle Macs verwenden in der Regel Apple-Silicon-Prozessoren, ältere Geräte können Intel-Prozessoren besitzen.

Nach Installation und Start von Docker Desktop öffnen wir das Terminal und prüfen wieder:

docker --version

und:

docker compose version

Damit sind die Unterschiede zwischen unseren drei Betriebssystemen für diese Anleitung im Wesentlichen erledigt.

Ab jetzt verwenden wir überall Docker Compose.

Unser WordPress-Projekt anlegen

#

Wir erstellen ein neues Verzeichnis.

Unter Linux oder macOS beispielsweise:

mkdir wp-test
cd wp-test

Unter PowerShell:

mkdir wp-test
cd wp-test

Darin legen wir zwei Dateien an:

wp-test/
├── compose.yaml
└── .env

Warum compose.yaml?

Ältere Tutorials verwenden häufig:

docker-compose.yml

Dieser Dateiname funktioniert in vielen Umgebungen weiterhin.

Bei aktuellen Docker-Compose-Versionen ist compose.yaml allerdings ein üblicher und von Docker unterstützter Standardname.

Außerdem verwenden wir heute:

docker compose

statt des älteren separaten:

docker-compose

Zugangsdaten in .env

#

Wir wollen Datenbankpasswörter nicht direkt in die Compose-Datei schreiben.

Deshalb erstellen wir:

.env

mit beispielsweise:

MYSQL_DATABASE=wordpress
MYSQL_USER=wordpress
MYSQL_PASSWORD=change-this-password
MYSQL_ROOT_PASSWORD=change-this-root-password

Für eine lokale Wegwerf-Testinstallation könnten diese Werte beliebig gewählt werden.

Trotzdem ist es eine gute Gewohnheit, Zugangsdaten von der eigentlichen Compose-Konfiguration zu trennen.

Wenn dieses Projekt in Git landet, sollte die echte .env nicht committed werden.

Die Compose-Datei

#

Jetzt erstellen wir compose.yaml.

services:
  db:
    image: mariadb:11.8
    restart: unless-stopped
    environment:
      MARIADB_DATABASE: ${MYSQL_DATABASE}
      MARIADB_USER: ${MYSQL_USER}
      MARIADB_PASSWORD: ${MYSQL_PASSWORD}
      MARIADB_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
    volumes:
      - db_data:/var/lib/mysql

  wordpress:
    image: wordpress:latest
    restart: unless-stopped
    depends_on:
      - db
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${MYSQL_DATABASE}
      WORDPRESS_DB_USER: ${MYSQL_USER}
      WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}
    volumes:
      - wordpress_data:/var/www/html

volumes:
  db_data:
  wordpress_data:

Damit beschreiben wir unsere komplette Testumgebung.

Was passiert hier?

#

Der Service:

db

startet MariaDB.

Der Service:

wordpress

startet WordPress mit Apache Webserver und PHP und verbindet sich mit der Datenbank.

Docker stellt für beide Services ein gemeinsames internes Netzwerk bereit.

Deshalb kann WordPress die Datenbank einfach über:

db:3306

erreichen.

Wir müssen dafür keine IP-Adresse der Datenbank herausfinden.

Was bedeutet 8080:80?

#

Diese Zeile:

ports:
  - "8080:80"

verbindet einen Port unseres Rechners mit dem Webserver im Container.

Vereinfacht:

Browser
   │
localhost:8080
   │
   ▼
Docker
   │
   ▼
WordPress Container
Port 80

Deshalb können wir WordPress anschließend über localhost:8080 öffnen.

WordPress starten

#

Jetzt kommt der angenehme Teil.

Im Projektverzeichnis führen wir aus:

docker compose up -d

Docker lädt beim ersten Start die benötigten Images herunter und erzeugt die Container.

-d bedeutet, dass die Container anschließend im Hintergrund laufen.

Danach prüfen wir:

docker ps

Wir sollten zwei laufende Container sehen.

WordPress im Browser öffnen

#

Jetzt öffnen wir:

http://localhost:8080

Beim ersten Aufruf erscheint die normale WordPress-Installation.

Wir wählen die Sprache und richten anschließend die Website ein.

WordPress fragt unter anderem nach:

Titel der Website
Benutzername
Passwort
E-Mail-Adresse

Diese Angaben betreffen den WordPress-Administrator.

Sie sind nicht identisch mit den MariaDB-Zugangsdaten aus unserer .env.

Danach können wir uns im Dashboard anmelden.

Container stoppen

#

Wenn wir die Testumgebung gerade nicht benötigen:

docker compose stop

Später starten wir sie wieder mit:

docker compose start

Unsere WordPress-Daten bleiben dabei erhalten.

Die Umgebung herunterfahren

#

Alternativ:

docker compose down

Dadurch werden die Container entfernt.

Unsere Daten bleiben trotzdem erhalten, weil wir Docker Volumes verwenden.

Beim nächsten:

docker compose up -d

werden die Container neu erzeugt und verwenden wieder die vorhandenen Daten.

Alles wirklich löschen

#

Hier muss man etwas aufpassen.

Wenn wir ausführen:

docker compose down -v

werden zusätzlich die von Compose verwalteten Volumes entfernt.

Damit verschwinden auch unsere WordPress- und Datenbankdaten.

Für eine reine Wegwerf-Testinstallation kann genau das gewünscht sein.

Für eine Installation mit wichtigen Testdaten möglicherweise nicht.

Deshalb:

docker compose down

bedeutet nicht dasselbe wie:

docker compose down -v

Das -v sollte man bewusst verwenden.

WordPress aktualisieren

#

Unsere Compose-Datei verwendet:

image: wordpress:latest

Ein erneutes Starten eines vorhandenen Containers lädt aber nicht automatisch bei jedem Aufruf ein neues Image herunter.

Wenn wir aktuelle Images beziehen möchten, können wir beispielsweise ausführen:

docker compose pull
docker compose up -d

Für eine langfristig reproduzierbare Entwicklungsumgebung würde ich allerdings überlegen, konkrete Image-Versionen festzulegen statt dauerhaft latest zu verwenden.

Für unsere einfache lokale Spielwiese ist latest zunächst bequem.

Wo sind meine WordPress-Dateien?

#

In unserer Konfiguration verwenden wir:

wordpress_data:/var/www/html

Das ist ein Docker Volume.

Die Dateien liegen deshalb nicht einfach als normales wordpress/-Verzeichnis neben unserer compose.yaml.

Das ist für eine Testinstallation bequem.

Wenn wir dagegen Themes oder Plugins selbst entwickeln möchten, würden wir bestimmte Verzeichnisse gezielt als Bind Mount vom Host in den Container einbinden.

Das wäre dann eher eine Entwicklerumgebung als die einfache Testinstallation aus diesem Artikel.

Warum nicht XAMPP?

#

Natürlich kann man WordPress auch mit XAMPP, MAMP oder einer anderen lokalen Serverumgebung betreiben.

Docker hat für mich bei Testumgebungen einen entscheidenden Vorteil:

Die benötigten Dienste werden als Teil des Projekts beschrieben.

Unsere Umgebung ist damit nicht:

Auf meinem Rechner ist irgendwo PHP installiert,
irgendwo läuft MariaDB
und irgendwann habe ich Apache konfiguriert.

sondern:

compose.yaml
     │
     ├── WordPress
     └── MariaDB

Wir können die Umgebung starten, stoppen und bei Bedarf komplett wegwerfen.

Gerade zum Testen von WordPress-Plugins ist das ausgesprochen angenehm.

Windows, Ubuntu oder Mac: Ab hier ist es fast egal

#

Das ist eine der angenehmen Eigenschaften dieses Setups.

Die Docker-Installation unterscheidet sich zwischen den Betriebssystemen.

Unser eigentliches WordPress-Projekt dagegen kaum:

Windows ─┐
Ubuntu  ─┼──► Docker Compose ──► WordPress + MariaDB
macOS   ─┘

Die gleiche compose.yaml kann damit von unterschiedlichen Entwicklern beziehungsweise auf unterschiedlichen Rechnern verwendet werden.

Wofür sich die Testinstallation eignet

#

Jetzt besitzen wir eine WordPress-Spielwiese.

Dort können wir beispielsweise:

• Themes ausprobieren,
• Plugins testen,
• WordPress-Einstellungen untersuchen,
• eigene CSS-Anpassungen testen,
• Gutenberg ausprobieren,
• Updates testen,
• Google Analytics einbauen,
• YouTube und Maps einbetten,
• Consent-Lösungen ausprobieren,
• oder eine Installation absichtlich kaputtmachen.

Gerade der letzte Punkt ist durchaus nützlich.

Wer WordPress lernen möchte, sollte Dinge ausprobieren können, ohne dabei ständig Angst um eine produktive Website zu haben.

Was diese Installation nicht ist

#

Unsere Konfiguration ist für eine lokale Testumgebung gedacht.

Sie ist keine Anleitung für einen öffentlich erreichbaren WordPress-Produktionsserver.

Für einen produktiven Betrieb müssten wir uns zusätzlich unter anderem mit HTTPS, Reverse Proxy, Backups, Updates, Secrets, Zugriffsschutz, Mailversand, Monitoring und der Absicherung der Serverumgebung beschäftigen.

Unsere lokale Umgebung soll dagegen vor allem eines sein:

einfach.

Fazit

#

Eine lokale WordPress-Testumgebung muss nicht aus einer manuellen Installation von Webserver, PHP und Datenbank bestehen.

Nachdem Docker installiert ist, beschreibt eine kleine compose.yaml praktisch unsere komplette Umgebung:

compose.yaml
     │
     ├── MariaDB
     │
     └── WordPress
            │
            ▼
    http://localhost:8080

Unter Windows und macOS ist Docker Desktop ein einfacher Einstieg. Unter Ubuntu können wir Docker Engine direkt verwenden.

Danach ist der eigentliche WordPress-Workflow auf allen drei Plattformen praktisch derselbe.

Mit:

docker compose up -d

starten wir unsere Testseite.

Und mit:

docker compose down

räumen wir die laufenden Container wieder weg.

Damit haben wir eine ideale Umgebung für die nächsten Experimente, ohne eine echte WordPress-Website dafür verwenden zu müssen.