Reproduire un environnement local similaire à la production pour un projet WordPress peut être une tâche pénible pour certains développeurs. D’autant que les configurations locales peuvent varier au sein de l’équipe projet : système d’exploitation et/ou matériel différents, version des dépendances non-alignées, commandes manuelles mal documentées...
Comme nous l’avions déjà abordé dans un précédent article (DDEV : moderniser sa stack locale avec Docker), DDEV résout ces problématiques en utilisant des containers Docker régis par un fichier de configuration commun. Désormais, seules quelques minutes sont nécessaires pour installer un nouveau projet WordPress.
Forts de ce constat, voyons ensemble comment mettre en place un projet WordPress avec DDEV.
La configuration d’un projet DDEV pour WordPress
Plusieurs fichiers spécifiques à DDEV sont nécessaires pour configurer un projet WordPress. Découvrons-les en détails ensemble afin de comprendre leurs configurations et leurs impacts.
Le fichier .ddev/config.yaml
Le cœur de la configuration DDEV réside dans le fichier .ddev/config.yaml, qui définit l’ensemble de l’environnement :
name: mon-projet-wordpress
type: wordpress
docroot: .
php_version: "8.4"
webserver_type: nginx-fpm
database:
type: mysql
version: "8.0"
Ce fichier déclare le type de projet (WordPress), la version PHP, le serveur Web (Nginx avec PHP-FPM), et la version de MySQL. Le paramètre “docroot” précise le répertoire racine du site (ici, il s’agit du répertoire courant “.”). Ce dernier paramètre est crucial pour Bedrock que nous aborderons plus loin, où la racine sera le répertoire “web”.
Le fichier wp-config-ddev.php
Lorsque le projet est démarré pour la première fois, DDEV génère automatiquement un fichier wp-config-ddev.php contenant les identifiants de connexion à la base de données via des variables d’environnement :
define('DB_NAME', 'db');
define('DB_USER', 'db');
define('DB_PASSWORD', 'db');
define('DB_HOST', 'ddev-mon-projet-wordpress-db'));
DDEV s’occupe aussi d’inclure automatiquement ce fichier dans votre fichier wp-config.php principal en allant rajouter les lignes de code adéquates.
WP CLI dans DDEV
Précision importante : les commandes WP-CLI doivent s’exécuter dans le container géré par DDEV.
La commande ddev wp plugin list exécute WP-CLI dans l’environnement conteneurisé, tandis que la commande wp plugin list tenterait de l’exécuter sur votre machine hôte (où WordPress n’est alors pas installé).
Configuration Nginx et le cas du multisite
DDEV configure également Nginx automatiquement pour WordPress avec les règles de réécriture appropriées. Pour un multisite en sous-domaines, il suffira d’ajouter les hosts additionnels dans le fichier .ddev/config.yaml :
additional_hostnames:
- site1.mon-projet
- site2.mon-projet
Après l’exécution de la commande ddev restart pour prendre en compte cette nouvelle configuration, ces domaines sont accessibles localement.
Important : lors de la migration d’un multisite existant, utilisez WP-CLI pour un search-replace optimisé des URLs dans la base de données (voir section dédiée ci-après).
Vous ne travaillez plus sur le projet ? Utilisez simplement ddev stop pour arrêter les containers de celui-ci et libérer des ressources sur votre machine. Et si vous n’avez plus besoin de DDEV pour la journée, ddev poweroff éteindra tous les services DDEV ainsi que Mutagen.
Rapide aparté : le boilerplate Bedrock pour WordPress
Nous l’avons mentionné précédemment, certaines configurations de DDEV, notamment le répertoire racine (webroot), peuvent changer si vous utilisez Bedrock. Mais qu’est-ce que Bedrock ?
Nous ne nous attarderons pas en détails sur cette approche aujourd’hui car elle sera le sujet d’un article dédié dans le futur, mais vous pouvez retenir ces quelques points : Bedrock implémente Composer pour la gestion des dépendances (core, plugins, thèmes...), sépare le core WordPress des plugins/thèmes/uploads, introduit une configuration par environnement basée sur le fichier .env... Bref, Bedrock aide à la bonne organisation et à la maintenance de son projet WordPress.
Si vous souhaitez en savoir plus sur Bedrock et sur les avantages pour un projet WordPress, vous pouvez consulter la documentation officielle par Roots.io à cette adresse : https://roots.io/bedrock/. Mais surtout n’hésitez pas à revenir sur le blog technique Adimeo où nous aborderons l’infrastructure Bedrock sous toutes ses coutures 😉.
La puissance des variables d’environnement
Utiliser des variables d’environnement empêche d’exposer des informations sensibles dans le code tout en s’assurant que chaque environnement dispose de sa propre configuration.
L’approche native PHP
PHP offre plusieurs fonctions pour lire les variables d’environnement. La fonction native getenv('VARIABLE_NAME') lit une variable définie au niveau du système ou du container. DDEV injecte automatiquement des variables comme DDEV_DBNAME, DDEV_HOSTNAME, DDEV_PRIMARY_URL dans tous les containers.
Exemple d’utilisation dans le fichier wp-config.php :
if (getenv('DDEV_HOSTNAME')) {
define('WP_HOME', getenv('DDEV_PRIMARY_URL'));
define('WP_SITEURL', getenv('DDEV_PRIMARY_URL'));
}
Cette approche permet d’adapter automatiquement la configuration WordPress selon l’environnement sans modifier le code existant.
Les librairies tierces : vlucas/phpdotenv
Pour des projets plus complexes (notamment avec Bedrock), la librairie vlucas/phpdotenv offre une gestion plus sophistiquée via un fichier .env déposé à la racine de votre projet et dans lequel vous pouvez définir vos variables d’environnement :
// Import de la fonction env()
use function Env\env;
// Chargement du fichier .env
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();
// Définition des constantes WordPress via le .env et env() : plus de valeurs en dur dans le code
define('DB_NAME', env('DB_NAME'));
define('DB_USER', env('DB_USER');
define('DB_PASSWORD', env('DB_PASSWORD');
define('DB_HOST', env('DB_HOST'));
Et votre fichier .env de contenir les lignes suivantes :
DB_NAME=”wordpress_database”
DB_USER=”database_user”
DB_PASSWORD=”passwordToMyDB”
DB_HOST=”localhost”
Bedrock utilise cette approche par défaut, permettant de définir toutes les constantes WordPress dans un fichier .env, qu’il faudra alors ignorer dans Git. Les valeurs sensibles (base de données, clés API, secrets) restent ainsi hors du dépôt et spécifiques à chaque environnement, tout en étant accessibles par le code.
Importer un projet WordPress existant (cadre TMA)
Voyons maintenant les avantages qu’offre DDEV lors de la reprise d’un projet existant pour l’installation de celui-ci sur votre environnement de développement.
Import de base de données via DDEV
DDEV simplifie drastiquement l’import d’une base de données existante, il suffit d’une seule commande :
ddev import-db --src=/path/to/database.sql.gz
Cette commande accepte les formats .sql, .sql.gz ou .sql.zip. DDEV importe automatiquement dans la base de données configurée, sans nécessiter de connexion manuelle à MySQL. Pour des projets en TMA, cette commande permet d’importer très facilement et rapidement une base de données pour remonter un environnement local iso-prod en un clin d’oeil.
Search-replace optimisé avec WP-CLI
Après l'import de la base de données, les URLs stockées dans celle-ci pointeront encore vers le domaine de production. WP-CLI offre une commande optimisée pour remplacer massivement ces URLs, que nous lancerons donc dans le container DDEV :
ddev wp search-replace 'https://www.example.com' 'https://mon-projet.ddev.site' --all-tables --precise
Le flag --precise évite les remplacements dans les données sérialisées PHP (corruptions courantes), --all-tables parcourt l’ensemble de la base y compris les tables non-core WordPress (introduites notamment par des plugins tiers). Cette commande gère correctement les contenus sérialisés, ce qui est crucial pour les métadonnées WordPress et les options de plugins.
Bonne pratique supplémentaire : pour vérifier ce qui sera remplacé par WP CLI en amont de la commande réelle, ajoutez le flag --dry-run :ddev wp search-replace 'https://www.example.com' 'https://mon-projet.ddev.site' --all-tables --precise --dry-run
Synchronisation des médias
Pour les médias (wp-content/uploads), une simple copie via rsync suffit généralement :
# ou /web/app/uploads dans une architecture Bedrock
rsync -av production:/var/www/html/wp-content/uploads/ ./wp-content/uploads/
Pour des volumes conséquents, privilégiez un rsync incrémental ou limitez la copie aux médias récents nécessaires au développement (dossiers uploads/2025 et uploads/2026 uniquement, par exemple).
Différences d’installation avec Bedrock
Bedrock modernise l’architecture WordPress, mais cela demande d’adapter certaines configurations.
Configuration de la webroot
Comme nous l’avons évoqué précédemment, Bedrock réorganise l’arborescence WordPress en plaçant le core WordPress dans un sous-dossier web/wp. Le fichier .ddev/config.yaml doit donc refléter cette structure via la ligne :
docroot: web
Cette modification indique à DDEV que le point d’entrée HTTP est le dossier “web” et non la racine du projet (comme c’est le cas pour un WordPress "vanilla"). Nginx servira les fichiers depuis ce répertoire, permettant de placer des scripts, documentation et configuration à la racine sans les exposer publiquement.
Hooks post-start pour Composer
Bedrock repose sur Composer pour gérer le core, plugins et thèmes de WordPress. DDEV peut automatiser l’installation des dépendances via un hook post-start dans .ddev/config.yaml :
hooks:
post-start:
- exec: composer install
À chaque exécution de ddev start, Composer s’exécute automatiquement dans le container web, pour installer ou mettre à jour les dépendances. Cela garantit que tous les développeurs travaillent avec les mêmes versions de plugins.
En 2026, il est grand temps de dire adieu aux installations LAMP hasardeuses pour WordPress. Que ce soit pour un site classique, un multisite en sous-domaines ou une architecture Bedrock, DDEV garantit que tous les développeurs travaillent dans des conditions identiques : même version de PHP, même configuration Nginx, mêmes versions de plugins via Composer.
Les valeurs sensibles (base de données, clés API, secrets WordPress) restent hors du dépôt Git et spécifiques à chaque environnement grâce aux variables d’environnement. La configuration sera automatiquement récupérée par tous les développeurs via Git, et l’écosystème d’addons permet d’élargir au besoin l’outillage du projet : PhpMyAdmin pour parcourir la base de données, ElasticSearch pour la recherche avancée, Redis pour le cache objet... Sans jamais toucher à l’installation WordPress elle-même.
DDEV modernise donc grandement la robustesse de vos projets WordPress, d’autant plus si vous décidez d’utiliser la puissance de Composer grâce à l’architecture Bedrock. En tout cas chez Adimeo, notre choix est fait !
Crédit photo : Antonio_Diaz
08 décembre 2025
10 minutes
