WordPress Bedrock : adopter une stack moderne pour vos projets

Publié le — WordPress

L'installation classique de WordPress mélange le core, les plugins, les thèmes, la configuration et les uploads dans un même répertoire. Tout est exposé publiquement, les mises à jour se font via le back-office et la configuration est hardcodée dans wp-config.php. Bedrock, développé par Roots, modernise cette approche : Composer pour les dépendances, variables d'environnement pour la configuration, structure sécurisée avec un dossier web isolé. C'est WordPress avec les pratiques d'un framework moderne comme Symfony ou Laravel.

WordPress classique vs Bedrock

Structure WordPress classique vs Bedrock À gauche la structure WordPress classique où tout est mélangé à la racine. À droite la structure Bedrock avec séparation : web/ pour le public, config/ pour la configuration, vendor/ pour Composer. WordPress classique Bedrock / (racine = public) ├── wp-config.php │ (credentials en clair) ├── wp-admin/ ├── wp-includes/ ├── wp-content/ │ ├── plugins/ │ │ (install via back-office) │ ├── themes/ │ └── uploads/ ├── index.php └── .htaccess Tout au même niveau, tout public / (racine ≠ public) ├── .env │ (credentials séparés) ├── composer.json │ (plugins = dépendances) ├── config/ │ └── application.php ├── vendor/ │ (Composer autoload) └── web/ (seul dossier public) ├── app/ (plugins, themes) ├── wp/ (core WordPress) └── index.php Séparation claire : public / config / vendor
WordPress classique : tout est mélangé et public. Bedrock : séparation entre le code public (web/), la configuration (config/, .env) et les dépendances (vendor/).

Gestion des dépendances avec Composer

Le changement le plus impactant de Bedrock : les plugins et le core WordPress sont des dépendances Composer. Plus de mise à jour manuelle via le back-office, plus de FTP — un composer update met tout à jour, de manière traçable et reproductible.

{
    "require": {
        "roots/bedrock-autoloader": "^1.0",
        "roots/wordpress": "^6.7",
        "wpackagist-plugin/advanced-custom-fields": "^6.3",
        "wpackagist-plugin/wordfence": "^7.11",
        "wpackagist-theme/flavor": "^1.0"
    }
}

Les plugins et thèmes proviennent de WordPress Packagist, un miroir Composer du répertoire officiel WordPress. Chaque plugin a sa version pinnée — toute l'équipe travaille avec les mêmes versions. Un composer.lock versionné garantit la reproductibilité.

Avantages concrets

  • Reproductibilité — composer install restaure l'exact même environnement sur n'importe quelle machine
  • Rollback — Un plugin cause un problème ? git revert + composer install et c'est résolu
  • Sécurité — composer audit détecte les vulnérabilités connues dans les dépendances
  • CI/CD — Les plugins se déploient avec le code, pas via le back-office en production

Pour développer vos propres plugins compatibles avec cette stack moderne, j'ai mis en libre accès un générateur de plugin WordPress qui produit un squelette PSR-4 prêt à composer install (types stricts, DDD léger, PHP 8.4).

Variables d'environnement : séparer config et code

Bedrock utilise Dotenv (le même principe que Symfony ou Laravel) pour gérer la configuration via un fichier .env :

# .env
DB_NAME=mon_site
DB_USER=root
DB_PASSWORD=secret
DB_HOST=localhost

WP_ENV=development
WP_HOME=https://mon-site.localhost
WP_SITEURL=${WP_HOME}/wp

AUTH_KEY='...'
SECURE_AUTH_KEY='...'

Le fichier .env est gitignored — les credentials ne sont jamais dans le dépôt. Chaque environnement (local, staging, production) a son propre .env avec ses propres valeurs. Le fichier config/application.php lit ces variables et configure WordPress automatiquement.

Sécurité renforcée

  • Racine web isolée — Seul le dossier web/ est exposé publiquement. Le composer.json, le .env, le vendor/ et la configuration sont inaccessibles depuis le navigateur.
  • Credentials hors du code — Les mots de passe de base de données, clés d'authentification et secrets sont dans le .env, pas dans wp-config.php versionné.
  • Pas de mise à jour depuis le back-office — Les plugins se mettent à jour via Composer et se déploient via CI/CD, pas par un admin qui clique "Mettre à jour" en production.

Bedrock + Docker : le setup de développement

Bedrock s'intègre naturellement avec Docker. La structure séparée (code / config / public) correspond aux bonnes pratiques de conteneurisation :

# docker-compose.yml
services:
  web:
    image: php:8.5-apache
    volumes:
      - .:/var/www/html
    environment:
      - APACHE_DOCUMENT_ROOT=/var/www/html/web
    ports:
      - "8080:80"

  db:
    image: mariadb:11
    environment:
      MYSQL_DATABASE: bedrock
      MYSQL_ROOT_PASSWORD: secret
    volumes:
      - db_data:/var/lib/mysql

volumes:
  db_data:

Points importants :

  • DocumentRoot sur web/ — Apache sert uniquement le dossier public, pas la racine du projet
  • Base de données persistante — Un volume nommé conserve les données MySQL entre les redémarrages
  • Deux .env — Un pour Docker (ports, credentials MySQL) et un pour Bedrock (WP_HOME, DB_NAME)

Bedrock Multisite

Bedrock est compatible avec le multisite WordPress, que ce soit en mode sous-dossier (subdirectory) ou en mode sous-domaine (subdomain).

Configuration multisite

La configuration se fait dans config/application.php en ajoutant les constantes WordPress standard :

// config/application.php
Config::define('WP_ALLOW_MULTISITE', true);
Config::define('MULTISITE', true);
Config::define('SUBDOMAIN_INSTALL', false); // true pour sous-domaines
Config::define('DOMAIN_CURRENT_SITE', env('DOMAIN_CURRENT_SITE'));
Config::define('PATH_CURRENT_SITE', '/');
Config::define('SITE_ID_CURRENT_SITE', 1);
Config::define('BLOG_ID_CURRENT_SITE', 1);

Sous-domaines : corriger le routing admin

Bedrock installe WordPress dans un sous-dossier web/wp/, ce qui peut causer des problèmes de routing dans le back-office en mode sous-domaines. Le package historique roots/multisite-url-fixer n'est plus maintenu. La solution recommandée est de gérer la réécriture d'URL directement dans la configuration du serveur web (Nginx ou Apache) ou via un mu-plugin personnalisé qui corrige les URLs admin.

Sous-dossiers vs sous-domaines

  • Sous-dossiers (monsite.fr/blog1/, monsite.fr/blog2/) — Plus simple à configurer, pas de DNS wildcard nécessaire. Limitation : disponible uniquement si le WordPress a moins d'un mois d'ancienneté.
  • Sous-domaines (blog1.monsite.fr, blog2.monsite.fr) — Plus propre visuellement, nécessite un DNS wildcard (*.monsite.fr) et une configuration serveur adaptée pour le routing admin.

Déploiement et CI/CD

Bedrock s'intègre naturellement dans un pipeline CI/CD :

  1. Composer install — Installe le core WordPress, les plugins et les thèmes en mode production (--no-dev)
  2. Build des assets — Si le thème utilise Webpack ou Vite (npm run build)
  3. Déploiement — rsync vers le serveur (exclure .env, node_modules/, tests/)
  4. WP-CLI — Exécuter les migrations de base de données (wp db update) et vider le cache

Le workflow est identique à celui d'un projet Symfony : composer install → build → deploy → migrations. Les développeurs WordPress qui connaissent les frameworks modernes retrouvent leurs habitudes.

Migrer un site existant vers Bedrock

La migration d'un WordPress classique vers Bedrock est relativement simple car Bedrock ne change que la structure, pas le fonctionnement :

  1. Créer un nouveau projet Bedrock : composer create-project roots/bedrock mon-site
  2. Ajouter les plugins existants dans composer.json (depuis wpackagist.org)
  3. Copier le thème personnalisé dans web/app/themes/
  4. Importer la base de données (dump SQL classique)
  5. Configurer le .env (DB, WP_HOME, clés d'authentification)
  6. Lancer composer install et tester

Les contenus, les utilisateurs, les réglages et les médias sont conservés. Seule la structure de fichiers change.

Questions fréquentes

Bedrock est-il compatible avec tous les thèmes et plugins WordPress ?

Oui. Bedrock ne modifie pas le fonctionnement de WordPress, seulement sa structure de dossiers. Tout thème et tout plugin fonctionnent sans adaptation. La seule différence : les plugins et thèmes sont installés via Composer (depuis wpackagist.org) au lieu du back-office WordPress.

Peut-on migrer un site WordPress existant vers Bedrock ?

Oui, la migration est simple : créer un nouveau projet Bedrock, ajouter les plugins existants dans le composer.json, copier le thème dans web/app/themes/, importer la base de données et configurer le .env. Les contenus, utilisateurs et réglages sont conservés — seule la structure de fichiers change.

Bedrock fonctionne-t-il avec le multisite WordPress ?

Oui, Bedrock est compatible multisite en mode sous-dossier (subdirectory) et sous-domaine (subdomain). Pour les sous-domaines, une configuration serveur adaptée ou un mu-plugin personnalisé est nécessaire pour corriger le routing admin. La configuration se fait dans config/application.php avec les constantes MULTISITE standard.

Bedrock ralentit-il WordPress ?

Non. Bedrock est un boilerplate de structure, pas une surcouche d'exécution. Le WordPress qui tourne est strictement identique — même core, même moteur. La structure de dossiers n'a aucun impact sur les performances. Au contraire, la gestion via Composer facilite les mises à jour qui améliorent les performances.

Top