AsterionWP2026/RESTART-PLAN.md

Restart Plan — Asterion VR refonte

Date : 2026-05-09 — fin de session 2 Décision : repartir d'une base propre, avec une approche Bricks-first orthodoxe.

---

1. Pourquoi redémarrer

L'approche actuelle a empilé trois architectures incompatibles :

1. Custom Templates PHP rendant depuis des data files (livrée, fonctionnait visuellement mais non éditable)
2. Migration Gutenberg blocks dans post_content (rendu visuel cassé, blocs core/html non éditables)
3. Migration Bricks data dans _bricks_page_content_2 (Bricks builder UI ne s'affiche pas correctement parce que mes header.php / footer.php interfèrent)

À chaque tentative de fix, je rajoute un patch (override CSS, mu-plugin, conditionnel). Le résultat :

• Code du child theme pollué (multiple renderers coexistent : render-blocks.php, render-blocks-native.php, render-bricks.php)
• Settings Bricks bricolés, pas alignés sur le workflow Bricks officiel
• 35 pages WP créées + 4 doublons supprimés + duplications WPML qui ont nécessité un patch slug
• mu-plugins en cascade (8+ fichiers one-shot dans LocalWP)

Bricks attend que le thème soit minimaliste et qu'il prenne lui-même la main sur le rendu. Mon child theme actuel fait l'inverse : il fournit des templates complets qui combattent Bricks.

---

2. Ce qu'on garde (à préserver dans le repo avant reset)

Asset	Lieu actuel	Sort
Brief + 2 PDFs + .txt extraits	racine repo	garder tel quel — sources de vérité
inc/solutions-data.php + industries-data.php + technology-data.php + editorial-data.php + forms-data.php	child theme	garder, mais déplacer dans /content-source/ — données pures, réutilisables comme source de génération ou comme dictionnaire de traduction WPML
assets/css/tokens.css (palette, typo, spacing, motion)	child theme	garder dans le nouveau child theme — design system partagé entre Bricks et notre CSS
assets/fonts/Inter-Variable.woff2 + Inter-Variable-Italic.woff2	child theme	garder (RGPD, déjà self-hostés)
BRIEF-Claude-Code.md, MISSING-ASSETS.md, README.md	racine	garder, à amender
Repo Git, remote git.polymorph.fr, branche main	—	garder, on continue dessus
LocalWP asterion-2026 site, WordPress 6.9, port 10004	LocalWP	garder, juste reset le contenu pages + theme
Bricks parent v2.3.4 + WPML 4.9.3 + licenses	LocalWP	garder

Ce qu'on supprime / archive

• Tout wp-content/themes/asterion-bricks/ actuel archivé dans une branche archive/php-templates puis ré-init du dossier
• Toutes les pages WP créées (35+) → wipe complet
• Tous les mu-plugins one-shot dans LocalWP → wipe (sauf asterion-debug.php et asterion-status.php que je laisse temporairement comme outils dev)
• Les overrides CSS Gutenberg / Bricks accumulés
• Les Custom Templates templates/page-*.php
• Les renderers PHP render-blocks.php, render-blocks-native.php, render-bricks.php

---

3. Architecture cible — Bricks-first orthodoxe

3.1. Child theme minimaliste

Le child theme asterion-bricks ne fait plus :

• ❌ Pas de header.php / footer.php custom (Bricks gère via ses templates)
• ❌ Pas de front-page.php / page.php / index.php custom (Bricks gère)
• ❌ Pas de Custom Templates page-*.php

Le child theme fait uniquement :

• ✅ style.css : header WP avec Template: bricks (obligatoire)
• ✅ functions.php : enqueue tokens.css + utilities.css en frontend, register CPT (case_study, scenario), self-host fonts
• ✅ assets/css/tokens.css : design tokens (couleurs, typo, spacing) en CSS variables
• ✅ assets/css/utilities.css : helpers très ciblés uniquement (.av-skip-link, .av-sr-only)
• ✅ assets/fonts/ : Inter Variable self-hosté
• ✅ inc/cpt.php : Custom Post Types
• ✅ theme.json : optionnel, pour Gutenberg color picker en cohérence

Total estimé : 8 fichiers, ~400 lignes. Drastiquement plus léger.

3.2. Bricks Templates (= header / footer / archives / single)

Tout le shell visuel devient des Bricks Templates créés via le builder :

Template Bricks	Type	Rôle
Header	header	Logo + nav (Solutions / Industries / Technology / Why Asterion / Insights) + CTA + lang switcher
Footer	footer	5 colonnes + bottom strip
Archive — Insights	archive	Liste des posts (blog hub)
Single — Insight	single	Article de blog
Archive — Customers	archive	Liste case_study
Single — Case Study	single	Page case_study individuelle
(option) Single — Page	single	Fallback si une page n'a pas de Bricks data

Ces templates s'appliquent automatiquement à toutes les pages/posts via les Bricks "Conditions" (par exemple "Apply on : All pages"). Tu (Jérôme) construis ces 5-7 templates une seule fois dans Bricks, à ton rythme.

3.3. Pages individuelles

Pour chaque page (Home, Solutions hub, MY PROSERVE, Industries hub, Police, etc.), 2 options selon l'effort qu'on veut investir :

Option A — Build visuel dans Bricks (recommandé pour les 7 templates de page)

1. Tu (Jérôme) construis 1 page de chaque archetype dans Bricks builder :

   • Home
   • Solution detail (1 fois → réutilisable pour les 4 tiers)
   • Industry detail (1 fois → 4 industries)
   • Technology detail (1 fois → 6 tech pages)
   • Editorial (1 fois → 5 pages)
   • Conversion form (1 fois → 4 forms)
   • Legal (1 fois → 4 legals)

2. Pour chaque archetype, tu sauvegardes en Template Bricks avec un nom (ex. "Solution Detail") dans Bricks → Templates.

3. Pour les variantes (4 solutions, 4 industries, etc.) : tu importes le template puis change juste le contenu textuel (Bricks "Bulk Edit" ou copy-paste).

Effort estimé : 7 templates × 30-60 min de build visuel = 4-7h de ton temps.

Option B — Génération programmatique depuis les data files

Une fois UN template Bricks finalisé visuellement pour un archetype, je peux :

1. Récupérer son JSON via _bricks_page_content_2
2. Identifier les "slots" textuels (le titre h1, les paragraphes, les card items, etc.)
3. Pour chaque variante (Police, Military, etc.), prendre les data du fichier industries-data.php, faire un templating substitution, écrire dans la nouvelle page WP.

Je l'ai prouvé techniquement — la difficulté c'est de partir d'un template Bricks bien construit pour ne pas inventer le format.

→ Je propose qu'on fasse A pour 1 industrie + 1 solution + 1 tech, puis B pour les 11 autres similaires (4 industries × 4 solutions × 6 tech, soit 14, dont 3 déjà manuels = 11 à générer).

3.4. Traduction WPML

Méthode standard :

1. Une fois une page EN finalisée dans Bricks (template + contenu), elle a son _bricks_page_content_2
2. Dans WPML → Translation Dashboard → choisir la page → "Translate"
3. WPML Translation Editor scanne les valeurs textuelles dans le JSON Bricks et expose un éditeur côté-à-côté EN/FR
4. Tu / le linguiste rentre les traductions, valide, publie

Pour pré-remplir : on peut écrire un mu-plugin one-shot qui pour chaque page EN crée la page FR via WPML API + pré-remplit les traductions en utilisant les data files (déjà bilingues si je les structure ainsi). Mais à faire APRÈS qu'au moins 1 page soit validée en Bricks.

3.5. Tokens et style cohérence

Mes tokens CSS (couleurs, typo, spacing) doivent être accessibles dans Bricks pour qu'on puisse les sélectionner via les controls Bricks (color picker, font picker, etc.).

Bricks a une feature Theme Styles qui permet de définir une palette globale et des variables CSS. On va :

1. Importer tokens.css via functions.php (chargé sur frontend ET dans builder)
2. Configurer Bricks → Theme Styles avec la même palette (color slugs brand-navy, brand-gold, etc.) référençant nos variables
3. Quand tu construis dans Bricks builder, tu choisis "Brand Navy" dans le color picker → Bricks émet var(--bricks-color-brand-navy) que je mappe à var(--color-brand-navy) dans tokens.css

Résultat : le design system est centralisé dans tokens.css, mais accessible visuellement dans Bricks builder. Tu modifies un token → tout le site update.

---

4. Étapes de restart (ordre)

Phase 0 — Backup (avant compactage)

1. Créer une branche archive/session-2-php-templates depuis main
2. Pousser sur le remote
3. La branche main reste là où elle est (juste un commit "archive snapshot" et on continue)

Phase 1 — Reset du theme

1. git rm -r wp-content/themes/asterion-bricks/
2. Recréer le child theme minimaliste (8 fichiers, comme décrit en 3.1)
3. tokens.css repris en l'état (déjà parfait)
4. Ré-importer Inter fonts (déjà téléchargées)
5. Activer le child theme

Phase 2 — Reset des pages WP

1. Mu-plugin one-shot qui : wp_delete_post(force) sur tous les posts type=page. Garde le post Sample Page ou wipe complet. Reset des options _bricks_page_content_2 partout.
2. Reset Bricks settings : delete_option('bricks_global_settings') puis re-set juste postTypes = ['page','post','case_study','scenario'].

Phase 3 — Bricks Theme Styles

1. Tu ouvres Bricks → Theme Styles dans WP admin
2. Tu crées une theme style "Asterion VR" appliquée à tout le site
3. Tu y configures : couleurs (utilise mes hex de tokens.css), typo (Inter), heading sizes
4. Sauvegarde

Phase 4 — Templates Bricks

1. Header : Bricks → Templates → Add New → type "Header" → tu construis le menu sticky avec 5 items + CTA + lang switcher → conditions "Apply on : Entire website"
2. Footer : pareil, type "Footer", 5 colonnes + bottom strip
3. (option) Single — Page fallback pour les pages sans Bricks data

Phase 5 — Première vraie page

1. WP admin → Pages → Add New → "Industries" (slug industries) → publier vide
2. Ouvrir Edit with Bricks
3. Construire la page hub Industries (hero + 4 cards) en Bricks éléments natifs, en utilisant le copy depuis content-source/industries-data.php
4. Sauver → exporter le template → versionner le JSON dans wp-content/themes/asterion-bricks/templates/industries-overview.json

Phase 6 — Validation

Tu valides visuellement Industries. Si OK, on continue avec :

• 4 pages industry detail (template "Industry Detail")
• Solutions hub + 4 tiers
• Technology hub + 6 pillars
• Editorial × 5
• Conversion × 4
• Legal × 4
• Insights / Resources
• Home

Soit 34 pages à construire au total. Avec mon aide pour la génération programmatique (option B en 3.3), on en fait probablement 7 manuellement, 27 générées à partir des templates manuels.

Phase 7 — WPML

Une fois EN finalisé, mu-plugin one-shot qui :

• Duplique chaque page EN en FR via WPML API (utilise les data FR des data files comme pré-remplissage)
• Tu valides, le linguiste affine

---

5. Risques résiduels

• Bricks license : si elle expire (annuelle), le builder est bridé. Vérifier renouvellement.
• Format JSON Bricks : peut changer entre versions Bricks majeures (v3.x). On versionne nos exports template JSON pour pouvoir les re-importer.
• Performance : Bricks ajoute du CSS / JS supplémentaire vs HTML pur. Lighthouse cible (90+) atteignable mais demande optimisation (lazy load, caching).
• WPML traduction : le linguiste doit comprendre Bricks Translation Editor (formation 30 min suffisent normalement).

---

6. Compactage du contexte

Avant de redémarrer, il faut :

1. Mettre à jour les memories (project_asterion_status.md, etc.) avec :
   • L'état archivé en branche
   • Le plan ci-dessus
   • Les data files (sources de vérité textuelle)
   • Les tokens.css (à reprendre tel quel)
   • Les contraintes (XAMPP intouchable, Bricks-first, etc.)
2. Compactage du contexte : tu commandes /compact ou redémarres une nouvelle session, je reprends depuis les memories.

---

7. Time-box

Phase	Effort dev (moi)	Effort utilisateur (toi)	Calendrier
0 — Backup	5 min	0	jour J
1 — Theme reset	30 min	valider	jour J
2 — Pages reset	15 min	0	jour J
3 — Theme Styles	0	30 min	jour J
4 — Templates header/footer	0	1-2h	jour J/J+1
5 — 1ère page (Industries)	30 min guidance	30 min	jour J+1
6 — Validation + autres pages	2-3h génération	4-7h build	semaine
7 — WPML traductions	1h génération	30 min × 35 pages = ~17h	linguiste 1-2 semaines

On peut avoir un site EN complet en Bricks dans 1 semaine si tu mets 4-7h de build visuel. La trad FR vient ensuite.

---

8. Ce que je veux que tu confirmes avant de démarrer

1. OK pour archiver la session actuelle dans une branche archive/session-2-php-templates ? (rien ne se perd, juste isolé)
2. OK pour le child theme minimaliste sans header.php / footer.php ? (Bricks gère via templates)
3. Tu acceptes de construire 5-7 templates Bricks visuels (1-2h chacun) ? Ou tu préfères que je tente une génération 100% programmatique (plus risqué, format JSON instable) ?
4. OK pour les CPT case_study + scenario en plus de page/post ? (déjà déclarés, on les garde)

Réponds aux 4. Ensuite : /compact et on redémarre propre.