chore: session 2 snapshot — archive before Bricks-first restart
Snapshots the project at the end of session 2, just before resetting to a Bricks-first orthodox architecture. RESTART-PLAN.md at the root explains why this approach is being abandoned and what the next session will look like. Why we restart - Three architectures got stacked: Custom PHP Templates → Gutenberg blocks in post_content → Bricks data in post meta. Each layer fights the next. - Bricks Builder UI does not load because our header.php / footer.php / page.php emit chrome that conflicts with Bricks' own template-parts. - CSS overrides multiplied (Gutenberg + Bricks variants) and still don't pixel-match the original PHP-rendered visual. - 8+ one-shot mu-plugins live in LocalWP to patch over inconsistencies. What survives the restart (preserved here on main) - BRIEF, both PDFs, .txt extracts (sources of truth) - assets/css/tokens.css (full design system, untouched) - assets/fonts/Inter-Variable*.woff2 (RGPD self-hosted) - inc/<section>-data.php files (text copy from PDF strategie, will become /content-source/ on next session for reuse as translation dictionary and as input to programmatic page generation) - The Git repo, remote, branch main - LocalWP site, Bricks v2.3.4, WPML 4.9.3 with active licenses - WPML EN + FR setup with directory URL strategy What gets wiped at the start of next session - wp-content/themes/asterion-bricks/header.php / footer.php / page.php / index.php / front-page.php / template-parts/ / templates/ - inc/render-blocks.php, inc/render-blocks-native.php, inc/render-bricks.php - inc/shortcodes.php, inc/i18n.php, inc/form-handler.php - 35+ WP pages created over the session - All one-shot mu-plugins in LocalWP/wp-content/mu-plugins/ Restart approach (detailed in RESTART-PLAN.md) - Minimalist child theme: style.css, functions.php, theme.json, tokens.css, trimmed utilities.css, fonts, inc/cpt.php — that's it. - No header.php / footer.php / page.php in child theme — Bricks Templates (Header / Footer / Single — Page) take over via Bricks' Conditions. - User builds 5-7 archetype Bricks templates visually (~1-2h each) then programmatic generation fills the variants from inc/*-data.php sources. - WPML duplication after EN is validated. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
250
RESTART-PLAN.md
Normal file
250
RESTART-PLAN.md
Normal file
@@ -0,0 +1,250 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user