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

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).