Concept dev web

Nouvelle page
Notes techniques — Site Erasmus+ 
 Ce que nous avons mis en place, pourquoi, et comment ça fonctionne — expliqué simplement. 
 
 Migration vers Fat Free Framework (F3) 
 1. 🗺️ Le contexte — d’où on part, où on va 
 Le site Erasmus+ a démarré en PHP pur : chaque page était un fichier PHP séparé ( articles.php , contacts.php …). Simple à démarrer, mais difficile à faire évoluer sur le long terme. 
 On a décidé de migrer vers une architecture plus structurée, avec un framework léger . En bonus, on en a profité pour avoir de vraies URLs lisibles. 
 
 
 
 ❌ Avant (URLs “moches”) 
 ✅ Après (URLs propres) 
 
 
 
 
 erasmus.thymon.fr/article.php?id=corogna-2024 
 erasmus.thymon.fr/article/corogna-2024 
 
 
 
 Ce changement nécessitait un point d’entrée unique : toutes les requêtes passent désormais par index.php , qui distribue le travail selon l’URL demandée. C’est ce que fait F3. 
 
 2. 🏗️ Le patron MVC — Modèle · Vue · Contrôleur 
 MVC est une façon d’organiser son code en 3 rôles bien séparés , pour ne pas tout mélanger dans un seul fichier. 
 🍕 Analogie — Un restaurant 
 
 
 Modèle = la cuisine. Il sait où sont les données et comment les lire (les fichiers JSON des articles). 
 Vue = le menu et la salle. Elle s’occupe uniquement de l’apparence (les fichiers HTML). 
 Contrôleur = le serveur. Il prend la commande (l’URL), va chercher les données, et les envoie à la bonne vue. 
 
 
 Schéma simple du flux : 
 Visiteur → frappe erasmus.thymon.fr/articles
 ↓
index.php — F3 lit l'URL et dit : "ça c'est pour ArticleController → liste()"
 ↓
ArticleController.php — va chercher les articles dans les JSON
 ↓
articles.html (Vue) — affiche les articles dans le HTML
 ↓
Navigateur reçoit la page finale 
 Avantage concret : si demain tu veux changer la mise en page de la liste des articles, tu touches seulement articles.html . Si tu veux changer comment les données sont filtrées, tu touches seulement ArticleController.php . Les deux ne se mélangent pas. 
 
 3. ⚡ Fat Free Framework (F3) — le chef d’orchestre 
 F3 est un micro-framework PHP . “Framework” = boîte à outils qui donne une structure. “Micro” = il reste très léger, sans des dizaines de fichiers de configuration. 
 Son rôle principal dans notre projet : le routage . Il lit l’URL demandée et appelle le bon contrôleur. 
 // Dans index.php — on dit à F3 : "si quelqu'un va sur /articles,
// appelle la méthode liste() dans ArticleController"
$f3->route('GET /articles', 'ArticleController->liste');
$f3->route('GET /article/@slug', 'ArticleController->detail');
// @slug = la partie variable de l'URL (ex: "corogna-2024") 
 F3 s’occupe aussi du moteur de templates : il lit les fichiers .html des vues, remplace les {{ @variables }} par les vraies valeurs, et produit le HTML final envoyé au navigateur. 
 💡 Pourquoi F3 plutôt que Laravel/Symfony ? Les grands frameworks sont très puissants mais ont une courbe d’apprentissage importante et beaucoup de “magie” cachée. F3 fait exactement ce dont on a besoin, sans surplus. 
 
 4. 📦 Composer — le gestionnaire de librairies 
 Composer est le gestionnaire de paquets PHP . C’est l’équivalent d’un store : il télécharge et installe des librairies créées par d’autres développeurs. 
 🛒 Analogie — Liste de courses 
 Tu écris dans composer.json : “j’ai besoin de F3 et d’une librairie vidéo”. Composer télécharge tout et le place dans vendor/ . 
 On a installé deux librairies pour ce projet : 
 
 bcosca/fatfree — le framework F3 
 php-ffmpeg/php-ffmpeg — manipulation vidéo (miniatures, futures fonctionnalités) 
 
 Le dossier vendor/ est exclu de Git (dans .gitignore ) car il peut être recréé avec : 
 composer install 
 
 5. 🔗 Les URLs propres — comment ça fonctionne 
 Pour que toutes les URLs passent par index.php , on utilise un fichier .htaccess à la racine du site (Apache). 
 # .htaccess — la règle clé
RewriteEngine On
# Si ce n'est pas un vrai fichier ET pas un vrai dossier...
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
# ...redirige vers index.php
RewriteRule .* index.php [L,QSA] 
 Quand quelqu’un va sur /article/corogna-2024 : 
 
 Apache cherche un fichier article/corogna-2024 → n’existe pas 
 La règle .htaccess envoie vers index.php 
 F3 lit l’URL, détecte la route /article/@slug 
 F3 appelle ArticleController->detail() avec slug = "corogna-2024" 
 
 ⚠️ Piège important — Chemins relatifs Avec les URLs propres, les chemins d’images relatifs cassent : sur /article/corogna-2024 , uploads/photo.jpg devient /article/uploads/photo.jpg → introuvable. Utiliser des chemins absolus : /uploads/photo.jpg . 
 
 6. 🎨 Les templates F3 — séparer le HTML du PHP 
 Dans l’ancien site, le PHP et le HTML étaient mélangés. Avec F3, le contrôleur prépare les données, puis les “envoie” à un fichier HTML (vue). 
 Syntaxe principale : 
 <!-- Afficher une variable (avec protection HTML automatique) -->
{{ @article.titre }}

<!-- Afficher du HTML pré-généré sans l'échapper -->
{{ @contenu_html | raw }}

<!-- Condition if/else -->
<check if="{{ @article.photo }}">
 <true><img src="{{ @article.photo }}" /></true>
 <false><div>Pas de photo</div></false>
</check>

<!-- Boucle foreach -->
<repeat group="{{ @articles }}" value="{{ @a }}">
 <h2>{{ @a.titre }}</h2>
</repeat> 
 F3 compile ces templates en PHP dans tmp/ . Il ne recompile que si le fichier source a changé. Si une vue ne se met pas à jour, vider le cache en supprimant tmp/*.php . 
 📝 Analogie — Un formulaire à remplir 
 Le template HTML est comme un formulaire avec des cases vides. Le contrôleur PHP remplit les cases avec les vraies données. F3 fait la liaison entre les deux. 
 
 7. 🗂️ Structure du projet — qui fait quoi 
 html/
├── index.php ← Point d'entrée UNIQUE (toutes les URLs arrivent ici)
│ └─ F3 lit l'URL et distribue au bon contrôleur
│
├── app/controllers/ ← CONTRÔLEURS (logique PHP)
│ ├── BaseController.php ← Base commune (variables layout, render...)
│ ├── HomeController.php ← Page d'accueil (/)
│ ├── ArticleController.php ← /articles et /article/@slug
│ ├── ContactController.php ← /contacts
│ └── StandardsController.php ← /standards-qualite
│
├── app/views/ ← VUES (HTML + syntaxe F3)
│ ├── layouts/
│ │ ├── main.html ← Accueil (navbar complète + footer)
│ │ └── simple.html ← Pages secondaires (nav simplifiée + retour)
│ ├── home.html
│ ├── articles.html
│ ├── article.html
│ ├── contacts.html
│ └── standards.html
│
├── includes/ ← Helpers PHP partagés
│ ├── config.php ← Constantes + chargement config.json
│ ├── functions.php ← Fonctions utilitaires
│ └── db.php ← Connexion DB (futures fonctionnalités)
│
├── data/ ← DONNÉES (JSON, protégées par .htaccess)
│ ├── articles/ ← 12 fichiers JSON (un par mobilité)
│ ├── menu.json ← Structure du menu
│ └── config.json ← Config (email, mdp admin hashé)
│
├── vendor/ ← Librairies Composer (ne pas modifier)
└── admin/ ← Pages d'administration (migration F3 à venir) 
 
 8. 🖼️ Les layouts — le “moule” des pages 
 Un layout est le cadre commun à plusieurs pages. Au lieu de recopier la navbar et le footer partout, on les met une seule fois dans le layout. 
 ┌────────────── simple.html (layout) ──────────────┐
│ <head> Tailwind, polices, meta tags... │
│--------------------------------------------------│
│ NAVBAR sticky (logo + lien retour) │
│--------------------------------------------------│
│ │
│ {{ @content | raw }} ← la vue s'insère ici │
│ │
│--------------------------------------------------│
│ FOOTER │
│--------------------------------------------------│
│ {{ @extra_scripts | raw }} ← JS optionnel │
└──────────────────────────────────────────────────┘ 
 On a deux layouts : 
 
 main.html — pour la page d’accueil (navbar complète + menu déroulant) 
 simple.html — pour les pages secondaires (navbar allégée + lien “retour”) 
 
 
 9. 🛡️ PHP 8.4 — pièges rencontrés et leçons apprises 
 On tourne sur PHP 8.4 : version plus stricte, certaines choses qui “passaient” avant provoquent maintenant des erreurs. 
 Piège n°1 — Variable non définie = erreur 
 Si un template F3 affiche {{ @ma_variable }} et que cette variable n’a pas été définie, PHP 8.4 peut déclencher une erreur (en DEBUG=3 : page blanche / HTTP 500). 
 Solution : initialiser les variables optionnelles dans BaseController.php : 
 // Dans BaseController::render()
$f3->set('page_description', '');
$f3->set('extra_head', '');
$f3->set('extra_scripts', ''); 
 Piège n°2 — Clé de tableau manquante 
 Accéder à $tableau['ma_cle'] quand la clé n’existe pas → “Undefined array key”. 
 Solution : garantir que toutes les clés existent, même vides : 
 // Bien : la clé 'conditions' existe toujours (tableau vide si pas de conditions)
'groupe' => [
 'intro' => "...",
 'items' => [...],
 'conditions' => [], // vide mais présent
] 
 Comment diagnostiquer les erreurs : 
 
 
 Dans index.php , mettre $f3->set('DEBUG', 3) 
 Ajouter ini_set('error_log', __DIR__ . '/php_errors.log') 
 Lire php_errors.log pour voir l’erreur exacte et la ligne 
 Une fois corrigé, remettre DEBUG=0 et retirer les logs 
 
 
 
 10. 📖 Lexique — les termes à retenir 
 
 
 
 Terme 
 Définition 
 
 
 
 
 Framework 
 Boîte à outils qui impose une structure au projet. 
 
 
 MVC 
 Organisation du code en 3 rôles séparés (Modèle · Vue · Contrôleur). 
 
 
 Route 
 Association entre une URL (ex: /articles ) et le code à exécuter. 
 
 
 Template 
 Fichier HTML avec des “trous” ( {{ @variable }} ) remplis par F3. 
 
 
 Layout 
 Cadre commun (navbar + footer) partagé par plusieurs pages. 
 
 
 Composer 
 Gestionnaire de paquets PHP qui installe les librairies dans vendor/ . 
 
 
 .htaccess 
 Configuration Apache qui redirige vers index.php (URLs propres). 
 
 
 Cache de templates 
 F3 compile les templates dans tmp/ . Si une vue ne bouge pas : supprimer tmp/*.php . 
 
 
 Chemin absolu vs relatif 
 Absolu = commence par / . Relatif = dépend de l’URL, peut casser avec les routes. 
 
 
 DEBUG=3 
 Mode debug F3 : affiche les erreurs. En prod : DEBUG=0 . 
 
 
 
 
 Site Erasmus+ — Consortium École de Provence · Projet personnel de Thymon · Mars 2026