AccroCBio/README.md

# AccroCBio — site pédagogique sur le template commun

Site AccroCBio conservé visuellement, restructuré autour du même socle que `Template` : **Django 5 / DRF**, **React + Vite / shadcn/ui**, **MySQL 8**, **Oxlint**, services d'API distincts des composants React, authentification Django **par session avec CSRF**, administration React à `/admin/` (aucun `django-admin`).

Les pages pédagogiques d'origine restent présentes : accueil, présentation, services à la personne, crédit d'impôt, ressources et leurs sous-rubriques, avis, offre de rentrée, contact, mentions légales et confidentialité. Les ressources, témoignages, offres et messages reçus restent dans leurs modèles Django existants.

## Installer / migrer depuis l'ancien AccroCBio

**Avant de remplacer les fichiers : sauvegardez impérativement la base MySQL et `backend/media/`.** Ce projet réutilise la base et les migrations existantes : il ne faut pas réinitialiser le volume MySQL. Le déploiement Compose reste volontairement sur **MySQL 8.0**, comme AccroCBio d'origine.

1. Appliquer les fichiers de l'archive de modifications à la racine de l'ancien AccroCBio, en conservant l'arborescence et les autres fichiers existants.
2. **Garder le `.env` réel** et les valeurs des paramètres `MYSQL_*`, `SECRET_KEY`, ports et domaines. Ne pas remplacer les mots de passe par les valeurs de `.env.example`.
3. Vérifier `ALLOWED_HOSTS`, `CORS_ALLOWED_ORIGINS`, `CSRF_TRUSTED_ORIGINS` pour le domaine public ; en HTTPS, mettre `SESSION_COOKIE_SECURE=True`, `CSRF_COOKIE_SECURE=True` et `DEBUG=False`.
4. Ajouter `FRONTEND_PORT` et `BACKEND_PORT` dans le `.env` existant si absents (exemple : `FRONTEND_PORT=1036` et `BACKEND_PORT=1037`). Lancer `docker compose up -d --build`. Le backend exécute `migrate`, `ensure_admin`, `collectstatic` et démarre Django directement sur `BACKEND_PORT` ; Vite Preview écoute sur `FRONTEND_PORT`.
5. Se connecter à `/admin/` avec un compte **staff** déjà existant (`is_staff=True`) ou le compte admin initial configuré dans `.env` lors du tout premier démarrage. Les anciens jetons JWT de l'éditeur ne servent plus : une nouvelle connexion est requise.
6. Vérifier en priorité le formulaire de contact, les ressources, les médias et la page d'édition.

**Conservation des données** : la migration `common.0002_import_legacy_content` copie les personnalisations de l'ancienne table `education.SiteContent` dans la nouvelle table CMS `common.SiteContent`, sans supprimer l'ancienne. Le modèle utilisateur personnalisé `users.User` et ses migrations sont conservés. Le dossier `./backend/media:/app/media` continue de stocker les anciennes images ; les nouveaux uploads utilisent `/api/cms/media/…`.

**Ne pas** utiliser `docker compose down -v` lors de la mise à jour : cela effacerait les volumes de base de données.

## Administration « je peux tout modifier »

À `/admin/`, deux mécanismes se complètent :

- **Modifier directement les pages** : mode « Modifier » activé sur le site, pour les textes, liens de boutons et images marqués par des contrôles d'édition.
- **Éditeur avancé → Pages** : ajouter, publier/masquer, nommer et organiser de nouvelles pages.
- **Éditeur avancé → Navigation** : libellés, visibilité et ordre des liens internes.
- **Éditeur avancé → Blocs** : ajouter, modifier, masquer, déplacer et supprimer des titres, paragraphes, boutons ou images, y compris sur les pages historiques.
- **Éditeur avancé → Apparence** : changer les couleurs principales du thème clair/sombre sans reconstruire l'application.
- **Éditeur avancé → Textes / liens** : modifier et réinitialiser les contenus enregistrés.
- **Ressources, Avis, Offres, Messages** : garder la gestion des données métier de l'ancien AccroCBio.
- **Utilisateurs** : voir les comptes, créer des comptes (superutilisateur) et désactiver/réactiver ceux qui ne sont pas protégés.

La gestion couvre les contenus éditables et les sections ajoutées via le CMS. La création de nouveaux types de composants, la logique des formulaires et certaines zones techniques codées en dur nécessitent encore une intervention dans le code.

## Architecture

```text
backend/
  common/            # Authentification par session, utilisateurs, CMS et migrations
  core/              # Django, URLs, origines, réglages
  education/         # API et modèles existants (cours, contact, ressources, avis, offres)
  users/             # Modèle utilisateur et migrations existantes
  media/             # Images et fichiers persistants sur l'hôte
frontend/
  src/services/      # API et services métier (aucun fetch dans les pages)
  src/context/       # État de la session et de l'édition
  src/components/cms/  # Éditeur, pages, blocs et thèmes
  src/pages/education/ # Pages pédagogiques originales
  src/pages/editor/    # Administration React intégrée
```

## Développement et paramètres

Les ports dans `.env.example` sont `FRONTEND_PORT=1036` et `BACKEND_PORT=1037`, à adapter à votre installation. **Ils doivent être ajoutés dans le `.env` réel** ; on n'utilise plus de ports internes `80/8000`. `docker compose up -d --build` lance MySQL, Django et Vite Preview, **sans Nginx**. Vite relaie `/api`, `/static` et `/media` à Django sur `BACKEND_PORT` ; sous Compose, le nom réseau `backend` est utilisé, et sous Pterodactyl, `127.0.0.1`. Quand `.git` existe, `start.sh` exécute `git fetch` puis `git reset --hard origin/main`, conformément au script fourni : **pousser les modifications sur Gitea avant de redémarrer**, sous peine de les voir écrasées. Le `start.sh` sert uniquement à un hébergement **hors Compose**, typiquement Pterodactyl, avec les dépendances Python/Node et une base MySQL déjà accessibles. Il garde la séquence Git → vérifications Django → migrations → ensure_admin → collectstatic → npm → build → Vite Preview → arrêt propre. Il ne crée ni n'installe la base MySQL.

Pour une installation locale autonome : dans `backend/`, utiliser `pip install -r requirements.txt`, `python manage.py migrate`, `python manage.py ensure_admin`, `python manage.py runserver 0.0.0.0:$BACKEND_PORT` ; dans `frontend/`, utiliser `npm install` puis `npm run dev -- --port $FRONTEND_PORT`. Oxlint : `npm run lint`.

Le formulaire de contact conserve ses messages en base ; les notifications par e-mail sont optionnelles (`CONTACT_NOTIFICATION_EMAIL`, `DEFAULT_FROM_EMAIL`, `EMAIL_HOST`, `EMAIL_PORT`, `EMAIL_HOST_USER`, `EMAIL_HOST_PASSWORD`, `EMAIL_USE_TLS`).

**Sécurité et données** : l'éditeur est réservé aux comptes `is_staff`, protégé par les sessions Django et CSRF ; les pages publiques ne donnent pas accès aux routes d'écriture administratives. Les médias sont limités à PNG/JPEG/WebP jusqu'à 5 Mo. Pour un site publié en production, activer HTTPS, contrôler les hôtes autorisés et conserver une sauvegarde de la base et des médias.

**Important pour la mise à jour** : si l’ancien fichier `frontend/nginx.conf` existe encore, il peut être supprimé ; il n’est plus lu par le Dockerfile. Ne pas remplacer le fichier `.env` existant par `.env.example` : y ajouter simplement les deux variables de ports. En cas de changement des ports, recréer les deux services avec `docker compose up -d --build --force-recreate`. Pour un domaine public, ajouter le domaine dans `ALLOWED_HOSTS` (et les origines HTTPS dans `CSRF_TRUSTED_ORIGINS`).