Jour 1 - Poser le socle d’un blog Symfony + Twig propre

Avant de parler entity, routing ou CRUD, on pose une base solide. C’est ce qui évite de courir après des bugs de structure plus tard.

Dans ce premier article, on installe le socle, on active Twig et on prépare un environnement local propre pour travailler chaque jour sans friction.

Objectif d’apprentissage

Installer un projet Symfony stable, brancher Twig proprement, et comprendre la structure minimale avant d’ajouter la moindre fonctionnalité métier.

Ce que tu vas pratiquer aujourd’hui

• Installer Symfony avec composer et vérifier les prérequis locaux.
• Activer Twig pour le rendu serveur avec des templates lisibles.
• Poser les premières conventions: dossier, nommage, variables d’environnement.
• Valider que le projet démarre bien avant d’aller plus loin.

1. Créer le projet et installer les packages de base

On démarre avec symfony/skeleton pour garder un projet léger et lisible. Ensuite on ajoute uniquement les briques utiles pour un blog.

L’idée est simple: installer peu, mais installer juste.

composer create-project symfony/skeleton blog-symfony-twig
cd blog-symfony-twig
composer require webapp
composer require symfony/asset symfony/validator symfony/string

2. Configurer l’environnement local

Le fichier .env centralise la config par défaut. On garde les secrets sensibles dans .env.local pour ne pas les versionner.

Prends l’habitude de vérifier la connexion base de données dès maintenant.

APP_ENV=dev
APP_SECRET=change-me-please
DATABASE_URL="mysql://blog:blog@127.0.0.1:3306/blog?serverVersion=8.0"

3. Lancer le serveur et valider le socle

Avant toute logique métier, valide que le serveur répond, que le cache est sain et que la configuration Symfony est cohérente.

Ce réflexe te fait gagner beaucoup de temps sur la suite de la série.

symfony serve -d
php bin/console about
php bin/console debug:container twig

Checklist de fin de session

• Le projet démarre en local sans erreur.
• Twig est disponible dans le container Symfony.
• La base de données est déclarée correctement.
• Tu connais le rôle de .env, .env.local et config/.

Erreurs fréquentes à éviter

• Sauter la vérification finale parce que “ça marche chez moi”.
• Mélanger trop de logique dans le controller au lieu de garder un flux clair.
• Oublier la cohérence entre la donnée, le template Twig et le comportement en production.

Pourquoi cette étape compte en conditions réelles

Dans un vrai projet client, chaque étape technique doit rester compréhensible par l’équipe, duplicable sur un autre environnement et fiable dans le temps. Ici, l’objectif est de transformer la théorie en un flux de travail concret, avec des décisions simples que tu peux défendre en revue de code.

Si tu appliques sérieusement les points du jour (installer symfony avec composer et vérifier les prérequis locaux.), tu réduis la dette technique dès le départ et tu facilites la suite: SEO, publication, maintenance et déploiement. C’est exactement la différence entre un blog “démo” et un blog exploitable en production.

Mini plan de révision

• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Installer Symfony avec composer et vérifier les prérequis locaux.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Activer Twig pour le rendu serveur avec des templates lisibles.
• Reprends ce point et explique-le à voix haute comme si tu faisais un code review : Poser les premières conventions: dossier, nommage, variables d’environnement.

Exercice rapide

Crée une page /healthz minimale qui retourne "OK", puis vérifie-la dans ton navigateur. Ce sera utile pour la prod à la fin.

Et demain ?

Demain, on crée la structure de données du blog avec une vraie entity et une migration propre.