WordPress mit Docker und Composer installieren: modernes Entwicklungssetup für 2026

Die WordPress-Entwicklung ist über FTP-Uploads und Shared-Hosting-Panels hinausgewachsen. Im Jahr 2026 behandeln professionelle Teams WordPress wie jedes andere Softwareprojekt, mit versionierten Abhaengigkeiten, containerisierten Umgebungen und automatisierten Deployment-Pipelines. Wenn Sie immer noch Dateien direkt auf einem Live-Server bearbeiten, wird diese Anleitung Ihre Arbeitsweise verändern.

Dieses Tutorial behandelt zwei komplementaere Ansaetze für die moderne WordPress-Entwicklung: Docker Compose für reproduzierbare Serverumgebungen und Composer mit Bedrock für die Abhaengigkeitsverwaltung. Sie erhalten vollstaendige, kopierfertige Konfigurationsdateien, Xdebug-Setup für professionelles PHP-Debugging und einen Deployment-Workflow, der Ihren Code sicher von der lokalen Maschine in die Produktion bringt.

#Warum das traditionelle WordPress-Setup Sie zurückhaelt

Der klassische Ansatz, eine ZIP-Datei von wordpress.org herunterzuladen und per FTP hochzuladen, schafft mehrere Probleme, die sich mit der Zeit verstärken:

• Umgebungsabweichung - Ihr lokales MAMP- oder XAMPP-Setup stimmt nie genau mit dem Produktionsserver überein, was zu “funktioniert auf meinem Rechner”-Fehlern führt.
• Kein Abhaengigkeits-Tracking - Plugins und Themes werden manuell heruntergeladen und aktualisiert, was es unmöglich macht, genau dieselbe Site auf einer anderen Maschine zu reproduzieren.
• Keine Versionskontrolle für den Core - WordPress-Core-Dateien liegen in Ihrem Repository (oder schlimmer, werden gar nicht getrackt) und vermischen Anwendungscode mit Framework-Code.
• Manuelle Deployments - Das Kopieren von Dateien per FTP ist fehleranfaellig und bietet keinen Rollback-Mechanismus.

Docker und Composer loesen jedes dieser Probleme systematisch.

#WordPress mit Docker Compose einrichten

Docker Compose laesst Sie Ihren gesamten Server-Stack in einer einzigen YAML-Datei definieren. Jeder Entwickler im Team erhaelt genau dieselbe PHP-Version, MySQL-Version und Serverkonfiguration, indem er einen einzigen Befehl ausführt.

#Voraussetzungen

Installieren Sie Docker Desktop für Ihr Betriebssystem. Docker Desktop enthaelt sowohl die Docker-Engine als auch das docker compose CLI-Plugin. Überprüfen Sie die Installation:

docker --version
docker compose version

#Projektstruktur

Erstellen Sie ein sauberes Projektverzeichnis:

mkdir wordpress-docker && cd wordpress-docker
mkdir -p wp-content/themes wp-content/plugins wp-content/uploads

#Die vollstaendige docker-compose.yml

Erstellen Sie eine docker-compose.yml-Datei in Ihrem Projektstammverzeichnis:

version: "3.9"

services:
  db:
    image: mysql:8.0
    container_name: wp_mysql
    restart: unless-stopped
    environment:
      MYSQL_DATABASE: ${DB_NAME:-wordpress}
      MYSQL_USER: ${DB_USER:-wpuser}
      MYSQL_PASSWORD: ${DB_PASSWORD:-wppassword}
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-rootpassword}
    volumes:
      - db_data:/var/lib/mysql
    ports:
      - "3306:3306"
    networks:
      - wp_network
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  wordpress:
    image: wordpress:6.7-php8.3-apache
    container_name: wp_app
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: ${DB_NAME:-wordpress}
      WORDPRESS_DB_USER: ${DB_USER:-wpuser}
      WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:-wppassword}
      WORDPRESS_DEBUG: ${WP_DEBUG:-1}
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_DEBUG_LOG', true);
        define('WP_DEBUG_DISPLAY', false);
        define('SCRIPT_DEBUG', true);
        define('DISALLOW_FILE_EDIT', true);
    volumes:
      - ./wp-content/themes:/var/www/html/wp-content/themes
      - ./wp-content/plugins:/var/www/html/wp-content/plugins
      - ./wp-content/uploads:/var/www/html/wp-content/uploads
      - ./php-custom.ini:/usr/local/etc/php/conf.d/custom.ini
    ports:
      - "8080:80"
    networks:
      - wp_network

  phpmyadmin:
    image: phpmyadmin:5
    container_name: wp_phpmyadmin
    restart: unless-stopped
    depends_on:
      - db
    environment:
      PMA_HOST: db
      PMA_PORT: 3306
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:-rootpassword}
    ports:
      - "8081:80"
    networks:
      - wp_network

  mailhog:
    image: mailhog/mailhog:latest
    container_name: wp_mailhog
    ports:
      - "1025:1025"
      - "8025:8025"
    networks:
      - wp_network

volumes:
  db_data:

networks:
  wp_network:
    driver: bridge

Diese Konfiguration bietet Ihnen vier Services:

• MySQL 8.0 mit Health-Check, damit WordPress auf die Bereitschaft der Datenbank wartet, bevor es startet.
• WordPress 6.7 auf PHP 8.3 mit Apache, wobei nur Ihre eigenen Themes, Plugins und Uploads gemountet werden.
• phpMyAdmin für die visuelle Datenbankverwaltung unter http://localhost:8081.
• MailHog zum Abfangen ausgehender E-Mails während der Entwicklung unter http://localhost:8025.

#Umgebungsvariablen mit .env

Erstellen Sie eine .env-Datei im Projektstammverzeichnis:

# Datenbank
DB_NAME=wordpress
DB_USER=wpuser
DB_PASSWORD=secure_local_password_2026
DB_ROOT_PASSWORD=secure_root_password_2026

# WordPress
WP_DEBUG=1

# Website
SITE_URL=http://localhost:8080

Docker Compose liest automatisch .env-Dateien aus dem Projektverzeichnis. Fuegen Sie .env sofort zu Ihrer .gitignore hinzu und committen Sie stattdessen eine .env.example-Vorlage.

#Benutzerdefinierte PHP-Konfiguration

Erstellen Sie php-custom.ini für entwicklungsfreundliche PHP-Einstellungen:

upload_max_filesize = 128M
post_max_size = 128M
memory_limit = 512M
max_execution_time = 300
max_input_vars = 3000
display_errors = On
error_reporting = E_ALL

#Umgebung starten

docker compose up -d

Öffnen Sie http://localhost:8080 und schließen Sie die WordPress-Installation ab. Ihre Themes- und Plugins-Verzeichnisse werden vom Host-System gemountet, sodass alle Änderungen in Ihrem Editor sofort in der laufenden WordPress-Instanz erscheinen.

#Nuetzliche Docker-Befehle für den Arbeitsalltag

# Logs aller Container anzeigen
docker compose logs -f

# Nur WordPress-Logs anzeigen
docker compose logs -f wordpress

# Shell im WordPress-Container öffnen
docker compose exec wordpress bash

# WP-CLI-Befehle im Container ausfuehren
docker compose exec wordpress wp plugin list --allow-root

# Alle Container stoppen (Daten bleiben erhalten)
docker compose stop

# Container stoppen und entfernen (Volume-Daten bleiben erhalten)
docker compose down

# Vollstaendiger Reset inklusive Datenbank
docker compose down -v

#Composer-basiertes WordPress mit Bedrock

Während Docker die Serverumgebung verwaltet, strukturiert Bedrock von Roots WordPress selbst in eine ordnungsgemaess Composer-verwaltete Anwendung um. Bedrock behandelt den WordPress-Core als Abhaengigkeit, nicht als Projektstammverzeichnis, was alles an der Verwaltung und dem Deployment von WordPress veraendert.

#Warum Bedrock wichtig ist

Standard-WordPress vermischt Anwendungscode (Ihr Theme, Plugins) mit Framework-Code (wp-admin, wp-includes) im selben Verzeichnis. Bedrock trennt diese Belange:

project-root/
  config/              # Umgebungsspezifische Konfiguration
    application.php
    environments/
      development.php
      staging.php
      production.php
  web/                 # Document Root (öffentlich)
    app/               # wp-content-Aequivalent
      themes/
      plugins/
      uploads/
    wp/                # WordPress-Core (Composer-verwaltet)
    wp-config.php      # Minimaler Loader
  vendor/              # Composer-Abhaengigkeiten
  .env                 # Umgebungsvariablen
  composer.json        # Abhaengigkeitsmanifest

Der WordPress-Core befindet sich in web/wp/ und wird nie modifiziert. Ihr eigener Code befindet sich in web/app/. Das vendor/-Verzeichnis und web/wp/ werden beide gitignored, da Composer sie aus composer.json neu erstellt.

#Bedrock installieren

composer create-project roots/bedrock my-wordpress-project
cd my-wordpress-project

#Die composer.json-Struktur

Bedrock’s composer.json verwaltet WordPress-Core, Plugins und Themes als Pakete:

{
  "name": "your-agency/client-project",
  "type": "project",
  "license": "MIT",
  "description": "WordPress project managed with Bedrock and Composer",
  "require": {
    "php": ">=8.1",
    "composer/installers": "^2.3",
    "vlucas/phpdotenv": "^5.6",
    "oscarotero/env": "^2.1",
    "roots/bedrock-autoloader": "^1.0",
    "roots/bedrock-disallow-indexing": "^2.0",
    "roots/wordpress": "6.7.*",
    "roots/wp-config": "1.0.0",
    "roots/wp-password-bcrypt": "1.1.0",
    "wpackagist-plugin/wordpress-seo": "^23.0",
    "wpackagist-plugin/wp-super-cache": "^1.12",
    "wpackagist-plugin/wordfence": "^7.11"
  },
  "require-dev": {
    "squizlabs/php_codesniffer": "^3.10",
    "roave/security-advisories": "dev-latest"
  },
  "config": {
    "optimize-autoloader": true,
    "preferred-install": "dist",
    "allow-plugins": {
      "composer/installers": true,
      "roots/wordpress-core-installer": true
    }
  },
  "repositories": [
    {
      "type": "composer",
      "url": "https://wpackagist.org",
      "only": [
        "wpackagist-plugin/*",
        "wpackagist-theme/*"
      ]
    }
  ],
  "extra": {
    "installer-paths": {
      "web/app/mu-plugins/{$name}/": [
        "type:wordpress-muplugin"
      ],
      "web/app/plugins/{$name}/": [
        "type:wordpress-plugin"
      ],
      "web/app/themes/{$name}/": [
        "type:wordpress-theme"
      ]
    },
    "wordpress-install-dir": "web/wp"
  }
}

Die entscheidende Erkenntnis: WordPress Packagist spiegelt das gesamte WordPress.org-Plugin- und Theme-Repository als Composer-Pakete wider. Ein Plugin hinzuzufuegen ist so einfach wie:

composer require wpackagist-plugin/advanced-custom-fields

Das Entfernen ist genauso sauber:

composer remove wpackagist-plugin/advanced-custom-fields

#Bedrock-Umgebungskonfiguration

Bedrock verwendet .env-Dateien anstelle von hartkodierten Werten in wp-config.php:

# .env-Datei für Bedrock
DB_NAME=wordpress
DB_USER=wpuser
DB_PASSWORD=secure_local_password_2026
DB_HOST=db:3306
DB_PREFIX=wp_

WP_ENV=development
WP_HOME=http://localhost:8080
WP_SITEURL=${WP_HOME}/wp

# Generieren Sie diese unter https://roots.io/salts.html
AUTH_KEY='generate-unique-key-here'
SECURE_AUTH_KEY='generate-unique-key-here'
LOGGED_IN_KEY='generate-unique-key-here'
NONCE_KEY='generate-unique-key-here'
AUTH_SALT='generate-unique-salt-here'
SECURE_AUTH_SALT='generate-unique-salt-here'
LOGGED_IN_SALT='generate-unique-salt-here'
NONCE_SALT='generate-unique-salt-here'

Jede Umgebung (Entwicklung, Staging, Produktion) hat ihre eigene .env-Datei auf ihrem jeweiligen Server. Dieselbe Codebasis laeuft überall, wobei das Verhalten vollstaendig durch Umgebungsvariablen gesteuert wird.

#Docker und Bedrock kombinieren

Die wahre Staerke zeigt sich beim Betrieb von Bedrock innerhalb von Docker. Ändern Sie die docker-compose.yml, um Ihr Bedrock-Projekt anstelle des Standard-WordPress-Images zu mounten:

services:
  wordpress:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - .:/var/www/html
    environment:
      - WP_ENV=development

Mit einem benutzerdefinierten Dockerfile:

FROM php:8.3-apache

RUN apt-get update && apt-get install -y \
    libzip-dev \
    libpng-dev \
    libjpeg-dev \
    libfreetype6-dev \
    libicu-dev \
    && docker-php-ext-configure gd --with-freetype --with-jpeg \
    && docker-php-ext-install \
    mysqli \
    pdo_mysql \
    zip \
    gd \
    intl \
    opcache

RUN a2enmod rewrite

COPY --from=composer:latest /usr/bin/composer /usr/bin/composer

ENV APACHE_DOCUMENT_ROOT /var/www/html/web

RUN sed -ri -e 's!/var/www/html!${APACHE_DOCUMENT_ROOT}!g' \
    /etc/apache2/sites-available/*.conf \
    /etc/apache2/apache2.conf

WORKDIR /var/www/html

Das ergibt eine vollstaendig containerisierte Bedrock-Umgebung, in der composer install innerhalb des Containers ausgeführt wird und das Document Root auf Bedrock’s web/-Verzeichnis zeigt.

#Xdebug-Setup für PHP-Debugging

Schrittweises Debugging ersetzt var_dump und error_log durch einen richtigen Debugger, der es Ihnen ermöglicht, die Ausfuehrung anzuhalten, Variablen zu inspizieren und Code Zeile für Zeile durchzugehen.

#Xdebug zum Docker-Container hinzufügen

Erstellen Sie eine xdebug.ini-Datei:

[xdebug]
zend_extension=xdebug
xdebug.mode=debug,develop
xdebug.start_with_request=yes
xdebug.client_host=host.docker.internal
xdebug.client_port=9003
xdebug.discover_client_host=0
xdebug.log=/tmp/xdebug.log
xdebug.idekey=VSCODE

Fuegen Sie die Xdebug-Installation zu Ihrem Dockerfile hinzu:

RUN pecl install xdebug-3.3.2 \
    && docker-php-ext-enable xdebug

COPY xdebug.ini /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini

#VS Code-Konfiguration

Erstellen Sie .vscode/launch.json in Ihrem Projektstammverzeichnis:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Listen for Xdebug (Docker)",
      "type": "php",
      "request": "launch",
      "port": 9003,
      "pathMappings": {
        "/var/www/html": "${workspaceFolder}"
      },
      "log": true
    }
  ]
}

Installieren Sie die PHP Debug-Erweiterung von Xdebug in VS Code, setzen Sie einen Breakpoint in einer beliebigen PHP-Datei, druecken Sie F5 zum Starten des Lauschens und laden Sie Ihre WordPress-Seite neu. Der Debugger haelt an Ihrem Breakpoint an.

#PhpStorm-Konfiguration

PhpStorm verarbeitet Docker-Xdebug-Verbindungen nativ:

1. Gehen Sie zu Settings > PHP > Debug und überprüfen Sie, dass Port 9003 eingestellt ist.
2. Gehen Sie zu Settings > PHP > Servers, fuegen Sie einen neuen Server mit localhost auf Port 8080 hinzu und konfigurieren Sie das Path-Mapping von /var/www/html zu Ihrem Projektstammverzeichnis.
3. Klicken Sie auf den Button Start Listening for PHP Debug Connections in der Symbolleiste.

#Deployment-Workflow: von lokal über Staging zur Produktion

Eine professionelle Deployment-Pipeline stellt sicher, dass Codeänderungen vorhersagbar von der Entwicklung zur Produktion fließen, ohne manuelles Kopieren von Dateien.

#Das Drei-Umgebungen-Modell

1. Lokal (Docker) - wo Sie Code schreiben und testen.
2. Staging - ein Server, der die Produktion für abschließende Tests spiegelt.
3. Produktion - die Live-Website.

#Git-basiertes Deployment mit GitHub Actions

Ihr Repository sollte Ihren Theme-, Plugin- und Bedrock-Konfigurationscode enthalten. Es sollte nicht den WordPress-Core, vendor/ oder uploads/ enthalten.

Beispiel .github/workflows/deploy.yml:

name: Deploy to staging

on:
  push:
    branches: [staging]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.3"

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Run code quality checks
        run: vendor/bin/phpcs --standard=WordPress web/app/themes/

      - name: Deploy via rsync
        uses: burnett01/rsync-deployments@7.0
        with:
          switches: -avz --delete --exclude='.env' --exclude='web/app/uploads/'
          path: ./
          remote_path: /var/www/staging.example.com/
          remote_host: ${{ secrets.STAGING_HOST }}
          remote_user: ${{ secrets.STAGING_USER }}
          remote_key: ${{ secrets.STAGING_SSH_KEY }}

#Datenbank- und Upload-Synchronisation

Code wird über Git deployt, aber Datenbanken und Medien-Uploads erfordern separate Behandlung:

# Produktionsdatenbank exportieren
wp db export production-backup.sql --ssh=user@production

# Auf Staging importieren
wp db import production-backup.sql --ssh=user@staging

# URLs ersetzen
wp search-replace 'https://example.com' 'https://staging.example.com' --ssh=user@staging

# Uploads von Produktion zu Staging synchronisieren
rsync -avz user@production:/var/www/html/web/app/uploads/ \
  user@staging:/var/www/html/web/app/uploads/

Für die lokale Entwicklung verwenden Sie die WP-CLI-Befehle wp db export und wp db import über Docker:

docker compose exec wordpress wp db export /tmp/backup.sql --allow-root
docker cp wp_app:/tmp/backup.sql ./backups/

#Vergleich: Docker vs Composer vs LocalWP vs MAMP

Die wichtigste Erkenntnis: Docker und Composer sind komplementaer, nicht konkurrierend. Docker ersetzt MAMP/XAMPP als Serverumgebung, während Composer die manuelle Plugin-/Theme-Verwaltung ersetzt. LocalWP bleibt eine gueltige Wahl für schnelles Prototyping, aber es fehlt ihm die Reproduzierbarkeit und CI/CD-Integration, die professionelle Teams benötigen.

#Performance-Tipps für Docker auf macOS

Docker auf macOS litt historisch unter langsamer Dateisystem-Performance aufgrund der Virtualisierungsschicht. Im Jahr 2026 verwendet Docker Desktop standardmaessig VirtioFS, was die I/O-Geschwindigkeit dramatisch verbessert. Wenn Sie immer noch Langsamkeit erleben:

• Überprüfen Sie, ob VirtioFS in Docker Desktop > Settings > General aktiviert ist.
• Beschraenken Sie gemountete Volumes auf das Noetigste (Themes, Plugins, Uploads), nicht die gesamte WordPress-Installation.
• Verwenden Sie bei Bedarf Docker’s eingebaute Caching-Direktiven: volumes: - ./wp-content:/var/www/html/wp-content:cached.
• Weisen Sie ausreichend Ressourcen in Docker Desktop > Settings > Resources zu (mindestens 4 GB RAM und 2 CPUs).

#Sicherheitsüberlegungen für die lokale Entwicklung

Selbst in lokalen Umgebungen sind Sicherheitsgewohnheiten wichtig, da Konfigurationen oft in die Produktion gelangen:

• Committen Sie niemals .env-Dateien in Git. Verwenden Sie .env.example als Vorlage.
• Verwenden Sie starke, einzigartige Passwoerter in Ihrer .env auch lokal, damit Sie nie versehentlich schwache Zugangsdaten deployen.
• Halten Sie DISALLOW_FILE_EDIT in allen Umgebungen auf true gesetzt.
• Fuehren Sie regelmäßig composer audit aus, um bekannte Schwachstellen in Ihren Abhaengigkeiten zu pruefen.
• Pinnen Sie spezifische Versionen in composer.json für Produktions-Deployments, anstatt lose Versionseinschraenkungen zu verwenden.

#Fehlerbehebung häufiger Probleme

MySQL-Container beendet sich sofort Überprüfen Sie die Logs mit docker compose logs db. Die häufigste Ursache ist ein vorhandenes Volume mit inkompatiblen Daten. Fuehren Sie docker compose down -v aus, um Volumes zu entfernen und neu zu beginnen.

WordPress kann keine Verbindung zur Datenbank herstellen Überprüfen Sie, ob der WORDPRESS_DB_HOST-Wert mit dem Servicenamen in docker-compose.yml übereinstimmt (typischerweise db:3306). Stellen Sie sicher, dass der Datenbank-Container gesund ist, bevor WordPress startet, indem Sie die oben gezeigte depends_on-Bedingung verwenden.

Xdebug verbindet sich nicht Bestaetigen Sie, dass host.docker.internal innerhalb des Containers korrekt aufgeloest wird. Unter Linux müssen Sie möglicherweise extra_hosts: - "host.docker.internal:host-gateway" zu Ihrer WordPress-Service-Definition hinzufügen.

Dateiberechtigungsfehler Wenn WordPress nicht in wp-content/uploads schreiben kann, passen Sie die Berechtigungen innerhalb des Containers an:

docker compose exec wordpress chown -R www-data:www-data /var/www/html/wp-content/uploads

#Nächste Schritte für Ihren Workflow

Sobald Docker und Composer laufen, sollten Sie diese Ergaenzungen in Betracht ziehen, um Ihr Setup weiter zu professionalisieren:

• WP-CLI als Composer-Abhaengigkeit für skriptgesteuerte WordPress-Verwaltung.
• PHPStan oder Psalm für statische Analyse Ihres Theme- und Plugin-PHP-Codes.
• GitHub Actions oder GitLab CI für automatisiertes Testen bei jedem Pull Request.
• Redis oder Memcached als zusätzlicher Docker-Service für Object Caching während der Entwicklung.
• Traefik oder Nginx Proxy für die Verwaltung mehrerer lokaler WordPress-Projekte mit benutzerdefinierten Domains anstelle von Portnummern.

Moderne WordPress-Engineering bedeutet, Ihre Website wie ein Softwareprodukt zu behandeln, mit reproduzierbaren Builds, automatisiertem Testen und sicheren Deployments. Die in dieser Anleitung behandelten Tools, Docker Compose für Umgebungen und Composer mit Bedrock für die Abhaengigkeitsverwaltung, bilden das Fundament, das jedes serioeoe WordPress-Team im Jahr 2026 braucht.

Bei wppoland.com bauen und pflegen wir WordPress-Projekte mit genau diesen Workflows. Wenn Ihr Team Hilfe bei der Modernisierung seines WordPress-Entwicklungsprozesses, der Einrichtung von CI/CD-Pipelines oder der Migration von Legacy-Setups zu containerisierten Umgebungen benötigt, steht unser Engineering-Team für Beratung und Implementierung zur Verfuegung. Die Preisgestaltung ist immer individuell und hängt vom Umfang Ihres Projekts ab.