Tester WordPress en local avec Docker : zéro installation, zéro galère

Mettre en place WordPress en local avec Docker Compose : MySQL, PhpMyAdmin et WP-CLI prêts en 5 minutes. Un environnement de test reproductible, sans installer PHP ni Apache sur ta machine.

6 min de lectureDéveloppement Web
Tester WordPress en local avec Docker : zéro installation, zéro galère

Tu veux tester un thème, valider la compatibilité d’un plugin ou reproduire un bug signalé par un client sans toucher au site de production ? Avec Docker, tu as un WordPress fonctionnel en 5 minutes, sans installer PHP ni Apache sur ta machine.

Ce guide suppose que Docker Desktop est déjà installé et que tu connais les concepts de base (image, conteneur, volume). Si ce n’est pas le cas, commence par l’article sur l’environnement LAMP avec Docker, qui couvre tout ça depuis le début.

Ce qu’on construit

Trois conteneurs qui communiquent entre eux :

  • WordPress : le CMS, accessible sur http://localhost:8080
  • MySQL 8.4 : la base de données
  • PhpMyAdmin : l’interface de gestion MySQL sur http://localhost:8081

Plus un service optionnel WP-CLI pour gérer WordPress en ligne de commande (installer des plugins, créer des utilisateurs, vider les caches).

Pas de Dockerfile ici : les images officielles suffisent, aucune personnalisation nécessaire.

Information
On utilise le port 8080 plutôt que 80 pour éviter un conflit si l’environnement LAMP tourne en parallèle sur ta machine.

Structure du projet

C:\Dev\WordPress\
  |-- .env                    # Mots de passe et version WordPress
  |-- .gitignore              # Pour ne jamais versionner .env
  |-- docker-compose.yml      # Les 3 services

Trois fichiers, c’est tout.

Le fichier .env

# MySQL
MYSQL_ROOT_PASSWORD=root
MYSQL_DATABASE=wordpress
MYSQL_USER=wp_user
MYSQL_PASSWORD=wp_password

# WordPress
WP_VERSION=latest

# PhpMyAdmin
PMA_VERSION=5.2.2
Information
WP_VERSION=latest pointe sur la dernière version stable. Pour tester la compatibilité avec une version précise, utilise WP_VERSION=6.4 ou n’importe quelle version listée sur hub.docker.com/_/wordpress.

Le docker-compose.yml

services:
  # Base de données MySQL
  mysql-server:
    image: mysql:8.4
    container_name: wp-mysql
    volumes:
      - mysql_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 3
    restart: "no"

  # WordPress
  wordpress:
    image: wordpress:${WP_VERSION}
    container_name: wp-site
    ports:
      - "8080:80"
    volumes:
      - wordpress_data:/var/www/html
    environment:
      WORDPRESS_DB_HOST: mysql-server
      WORDPRESS_DB_NAME: ${MYSQL_DATABASE}
      WORDPRESS_DB_USER: ${MYSQL_USER}
      WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}
    depends_on:
      mysql-server:
        condition: service_healthy
    restart: "no"

  # PhpMyAdmin
  phpmyadmin:
    image: phpmyadmin:${PMA_VERSION}
    container_name: wp-phpmyadmin
    ports:
      - "8081:80"
    environment:
      PMA_HOST: mysql-server
      PMA_USER: ${MYSQL_USER}
      PMA_PASSWORD: ${MYSQL_PASSWORD}
    depends_on:
      mysql-server:
        condition: service_healthy
    restart: "no"

  # WP-CLI (optionnel, lancé à la demande)
  wpcli:
    image: wordpress:cli
    volumes:
      - wordpress_data:/var/www/html
    environment:
      WORDPRESS_DB_HOST: mysql-server
      WORDPRESS_DB_NAME: ${MYSQL_DATABASE}
      WORDPRESS_DB_USER: ${MYSQL_USER}
      WORDPRESS_DB_PASSWORD: ${MYSQL_PASSWORD}
    depends_on:
      - wordpress
      - mysql-server
    profiles: ["tools"]

volumes:
  mysql_data:
  wordpress_data:

Quelques points à comprendre :

WORDPRESS_DB_HOST: mysql-server : WordPress doit connaître l’adresse de sa base de données. Dans Docker, les conteneurs communiquent par le nom du service défini dans docker-compose.yml, pas par localhost.

wordpress_data:/var/www/html : toute l’installation WordPress (core, thèmes, plugins, uploads) est stockée dans un volume. Elle survit aux arrêts et redémarrages des conteneurs.

profiles: ["tools"] : le service wpcli ne démarre pas avec docker compose up -d. Il ne se lance que quand on l’appelle explicitement avec docker compose run. Ça évite de démarrer un conteneur inutile en permanence.

Lancer l’environnement

Ouvre un terminal dans C:\Dev\WordPress et lance :

docker compose up -d

Vérifie que les 3 conteneurs sont actifs :

docker compose ps
NAME              STATUS             PORTS
wp-mysql          Up (healthy)       3306/tcp
wp-site           Up                 0.0.0.0:8080->80/tcp
wp-phpmyadmin     Up                 0.0.0.0:8081->80/tcp

Accès :

  • http://localhost:8080 : WordPress
  • http://localhost:8081 : PhpMyAdmin (login: wp_user / wp_password)

L’installateur WordPress

La première fois que tu ouvres http://localhost:8080, WordPress lance son assistant d’installation : choix de la langue, nom du site, identifiants admin. Deux minutes, c’est plié.

Information
Si tu vois une page blanche ou une erreur de connexion à la base de données en arrivant sur localhost:8080, attends 15 secondes et rafraîchis. Le conteneur WordPress démarre dès que MySQL est healthy, mais l’initialisation interne de WordPress peut prendre quelques secondes de plus.

Une fois l’installation terminée :

  • http://localhost:8080/wp-admin : tableau de bord
  • Login : les identifiants que tu as définis à l’étape d’installation

Ce qui persiste entre les redémarrages

Le volume wordpress_data contient l’intégralité du dossier /var/www/html : core WordPress, thèmes, plugins, fichiers uploadés. Tout ce que tu installes ou modifies survit aux docker compose down et aux redémarrages.

ActionCe qui se passe
docker compose stopConteneurs stoppés, tout conservé
docker compose downConteneurs supprimés, données conservées
docker compose up -dWordPress repart avec tous tes plugins/thèmes
docker compose down --volumesTout supprimé, retour à zéro
Attention
docker compose down --volumes supprime la base de données et tous les fichiers WordPress. L’installateur se relancera au prochain démarrage.

Commandes du quotidien

Démarrer les conteneurs :

docker compose up -d

Arrêter sans supprimer (les données sont conservées, le prochain up repart instantanément) :

docker compose stop

Arrêter et supprimer les conteneurs (les volumes restent intacts) :

docker compose down

Suivre les logs WordPress en temps réel (utile pour déboguer un plugin ou un hook) :

docker compose logs -f wordpress

Suivre les logs MySQL en temps réel :

docker compose logs -f mysql-server

WP-CLI : gérer WordPress en ligne de commande

WP-CLI permet d’installer des plugins, de gérer les utilisateurs ou de vider les caches sans passer par l’interface graphique. C’est indispensable pour automatiser des tâches ou déboguer rapidement.

Le service wpcli partage le même volume que WordPress (wordpress_data), donc il agit directement sur l’installation existante.

Vérifier l’environnement WordPress et PHP :

docker compose run --rm wpcli wp --info

Lister les plugins installés :

docker compose run --rm wpcli wp plugin list

Installer et activer un plugin :

docker compose run --rm wpcli wp plugin install woocommerce --activate

Lister les thèmes disponibles :

docker compose run --rm wpcli wp theme list

Créer un utilisateur administrateur (pratique pour tester des rôles) :

docker compose run --rm wpcli wp user create dev dev@local.test --role=administrator --user_pass=devpass

Vider tous les caches WordPress :

docker compose run --rm wpcli wp cache flush
Information
--rm supprime automatiquement le conteneur WP-CLI après chaque commande. Ça évite l’accumulation de conteneurs stoppés dans Docker Desktop.

Tester plusieurs versions de WordPress

Tu veux vérifier qu’un plugin est compatible avec WordPress 6.3 ? L’image Docker WordPress ne met pas à jour les fichiers du core si le volume wordpress_data existe déjà : elle détecte que WordPress est installé et ne touche à rien. Il faut donc repartir d’un volume vide à chaque changement de version.

Supprime les volumes, change la version, relance :

docker compose down --volumes
WP_VERSION=6.3
docker compose up -d
Attention
down --volumes efface la base de données et tous les fichiers WordPress. C’est voulu ici : un test de compatibilité de version nécessite une installation fraîche pour être fiable.

Dépannage : problèmes courants

Page blanche au premier lancement : attends 20-30 secondes et rafraîchis. WordPress initialise ses fichiers de configuration au premier démarrage.

Erreur “Error establishing a database connection” : le conteneur MySQL n’est peut-être pas encore healthy. Vérifie avec docker compose ps et attends qu’il passe au statut Up (healthy).

Conflit sur le port 8080 : un autre service utilise ce port. Change le mapping dans docker-compose.yml : "8090:80", puis accède à http://localhost:8090.

WP-CLI : “Error: This does not seem to be a WordPress installation” : le volume wordpress_data est vide ou corrompu. Lance d’abord docker compose up -d pour laisser WordPress s’installer, puis relance ta commande WP-CLI.

Sources et références

Catégories

Commentaires

Connexion via GitHub, gratuite et sans collecte de données par ce site.

Partager cet article

Articles connexes