composer create-project roots/bedrock : cette seule commande installe une arborescence WordPress radicalement différente de l’installation classique téléchargée depuis wordpress.org. Pas de dossier wp-admin à la racine, pas de wp-config.php à la racine non plus, mais une structure pensée pour séparer strictement le cœur de WordPress du code propre au projet.
Bedrock, maintenu par l’équipe Roots, ainsi que Trellis, son complément pour le provisioning serveur, répondent à un besoin précis : gérer un projet WordPress avec les mêmes outils et la même rigueur qu’un projet PHP moderne géré par Composer, sans renoncer à l’écosystème d’extensions et de thèmes WordPress existant.
La structure Bedrock, dossier par dossier
Une fois l’installation terminée, l’arborescence se présente ainsi :
site/
├── composer.json
├── config/
│ ├── application.php
│ └── environments/
│ ├── development.php
│ ├── staging.php
│ └── production.php
├── web/
│ ├── app/
│ │ ├── mu-plugins/
│ │ ├── plugins/
│ │ └── themes/
│ └── wp/
└── .envLe dossier web/wp contient le cœur WordPress téléchargé par Composer, jamais modifié directement. Le dossier web/app remplace le traditionnel wp-content, et concentre tout ce qui est propre au projet : thème, extensions, plugins obligatoires. Les identifiants de connexion à la base de données, les clés de sécurité et les réglages propres à chaque environnement sont extraits du code et placés dans le fichier .env, jamais versionné.
Gérer les extensions comme des dépendances Composer
Plutôt que d’installer une extension via l’interface d’administration, Bedrock encourage à la déclarer dans composer.json, ce qui rend la liste des dépendances explicite et reproductible d’un environnement à l’autre :
{
"require": {
"php": ">=7.4",
"composer/installers": "^1.9",
"roots/wordpress": "5.7.1",
"roots/bedrock-autoloader": "^1.0",
"wpackagist-plugin/advanced-custom-fields": "^5.9"
}
}Une extension issue du dépôt WPackagist s’installe alors avec composer require wpackagist-plugin/nom-extension, exactement comme n’importe quelle bibliothèque PHP. Ce mode de gestion facilite grandement la reproduction d’un environnement identique entre un poste de développement, un serveur de recette et la production.
Trellis : le provisioning serveur automatisé
Trellis complète Bedrock côté infrastructure, en s’appuyant sur Ansible pour provisionner des serveurs Ubuntu configurés pour WordPress : Nginx, PHP-FPM, MariaDB, et une structure de déploiement cohérente entre développement, recette et production. Une même définition de rôles Ansible permet de provisionner trois environnements distincts avec des variables spécifiques à chacun.
- Un fichier d’inventaire par environnement, listant les serveurs concernés
- Des rôles Ansible réutilisables pour Nginx, PHP-FPM et MariaDB
- Un mécanisme de déploiement (
trellis deploy) qui exécute Composer côté serveur et bascule symboliquement vers la nouvelle version du code
Ce que cette approche demande en contrepartie
Cette architecture n’est pas gratuite en complexité. Elle suppose une équipe à l’aise avec Composer, Ansible, et la ligne de commande, et rend certaines opérations habituelles pour un utilisateur WordPress classique moins directes, comme l’installation rapide d’une extension via l’interface d’administration, volontairement restreinte sur ce type de configuration.
Bedrock et Trellis conviennent à une équipe qui gère plusieurs projets WordPress avec une discipline d’ingénierie logicielle établie. Ils n’apportent pas grand-chose à un site unique géré par une seule personne peu familière de Composer.
Pour quel type de projet cette adoption a du sens
Sur les projets suivis par cette équipe, l’adoption de Bedrock et Trellis s’est révélée pertinente principalement pour les sites gérés en continu par plusieurs développeurs, avec un besoin réel de reproductibilité entre environnements et un cycle de déploiement fréquent. Pour un site vitrine simple géré ponctuellement, la structure classique de WordPress reste largement suffisante et plus accessible.
