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.