# Bedrock et Trellis pour déployer WordPress avec une arborescence modernisée

> Composer, variables d'environnement séparées, structure de dossiers repensée : ce que change concrètement l'adoption de Bedrock et Trellis sur un projet WordPress.

- Auteur : WordPress Développement
- Publié le : 2021-05-06
- Mis à jour le : 2021-05-06
- Catégorie : Hébergement & serveurs
- URL : https://www.wpmoderne.fr/hebergement/bedrock-trellis-deployer-wordpress-arborescence-modernisee/

## L’essentiel

- Bedrock sépare le cœur WordPress des fichiers propres au projet
- Les extensions et le thème deviennent des dépendances Composer versionnées
- Trellis automatise le provisioning serveur via Ansible

`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/
└── .env
```

Le 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 :

> L'essentiel à retenir : Bedrock sépare le cœur WordPress des fichiers propres au projet ; Les extensions et le thème deviennent des dépendances Composer versionnées ; Trellis automatise le provisioning serveur via Ansible

```
{
    "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.