j.foucher/AsterionWP2026

Files

j.foucher fba223004f chore: phase 1 reset — minimalist child theme + content-source extraction

Resets the child theme to its Bricks-first minimalist form (per RESTART-PLAN.md
phases 1a-1d) and extracts the textual copy into a runtime-independent
/content-source/ directory.

Child theme files removed
- header.php, footer.php, page.php, index.php, front-page.php
- template-parts/{solution,industry,conversion-form}.php
- templates/page-*.php (10 Custom Page Templates)
- inc/render-blocks.php, render-blocks-native.php, render-bricks.php
- inc/shortcodes.php, i18n.php, form-handler.php, seo.php
- assets/css/components.css, assets/js/main.js

Reasoning: Bricks Templates (Header / Footer / Single — Page) and Bricks-edited
pages now drive every screen. Anything emitted from the child theme would
fight Bricks' own rendering and waste CSS specificity battles.

Child theme now contains only
- style.css, functions.php (simplified to ~60 lines), theme.json
- inc/cpt.php (case_study + scenario + industry taxonomy)
- assets/css/tokens.css (untouched — design system source of truth)
- assets/css/utilities.css (trimmed to skip-link + sr-only + focus-visible
  + reduced motion — everything else handled by Bricks)
- assets/fonts/Inter-Variable*.woff2 (RGPD self-hosted)
- README.md spelling out the Bricks-first contract

Content moved to /content-source/
- solutions-data.php, industries-data.php, technology-data.php,
  editorial-data.php, forms-data.php — git mv preserves history
- README.md explaining their dual role: copy reference while building
  in Bricks, and source for programmatic page generation when we
  replicate an archetype across its variants.

Root README.md updated with the new repo layout + a pointer to
RESTART-PLAN.md and the archive/session-2-php-templates branch.

Memory file project_asterion_status.md updated for next-session resume.

What's preserved as before
- /BRIEF-Claude-Code.md, both PDFs, all .txt extracts
- /MISSING-ASSETS.md
- /ThirdParty/ (Bricks + WPML ZIPs, gitignored)
- LocalWP site at localhost:10004, Bricks v2.3.4 + WPML 4.9.3 active
- WPML EN/FR with directory URL strategy
- All Git history, both main and archive/session-2-php-templates branches

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

2026-05-09 14:36:19 +02:00

3.0 KiB

Raw Permalink Blame History

Content source — copy reference

PHP arrays of all the textual content authored in the Strategy & Content PDF (Asterion-VR_Refonte-2026_Strategie-et-Contenu.pdf, sections D.1 to D.29). Each file holds the EN copy for one site section, keyed by page slug.

These files are not loaded at runtime. They serve two purposes:

Reference while building Bricks pages — open the file matching the page you're editing and copy/paste the EN copy into the Bricks elements (Heading, Basic Text, Button…).
Source for programmatic generation — once a Bricks archetype template is built and validated visually, a one-shot script can iterate over the data here, clone the template, swap in each variant's strings, and create the WP page programmatically. This avoids rebuilding the same layout 4–6 times for similar pages (e.g. the 4 industry detail pages).

Files

File	Pages covered
`solutions-data.php`	`/solutions/my-proserve/`, `/solutions/proserve-flex/`, `/solutions/proserve-academy/`, `/solutions/customization/`
`industries-data.php`	`/industries/police/`, `/industries/special-forces/`, `/industries/military/`, `/industries/firefighters/`
`technology-data.php`	6 technology pillars under `/technology/`
`editorial-data.php`	Why Asterion, About, Customers hub, Trust, Partners
`forms-data.php`	Conversion forms (Demo, T&E Kit, Quote, Contact)

Schema

Every entry follows roughly the same shape :

'slug-of-page' => [
    'eyebrow'          => 'Small overline above the H1',
    'title'            => 'Short page title',
    'tagline'          => 'Hero H1',
    'meta_title'       => 'For <head><title> + OpenGraph',
    'meta_description' => 'For <head> meta description',
    'hero_lead'        => 'Long sub-headline under the H1',
    'ctas'             => [['label' => '...', 'href' => '/...', 'variant' => 'primary'], …],
    'sections'         => [
        ['type' => 'prose'  , 'eyebrow' => '…', 'title' => '…', 'body'  => '…'],
        ['type' => 'cards'  , 'eyebrow' => '…', 'title' => '…', 'items' => [['title' => '…', 'body' => '…'], …]],
        ['type' => 'list'   , 'eyebrow' => '…', 'title' => '…', 'items' => ['line 1', 'line 2', …]],
        ['type' => 'cta'    , 'eyebrow' => '…', 'title' => '…', 'body'  => '…', 'ctas' => […]],
    ],
],

forms-data.php deviates slightly — see its inline header comment.

Why we keep these in PHP arrays (vs JSON / YAML / Markdown)

They were extracted programmatically from the PDF and were already used by the previous PHP-rendering approach. Keeping the format means zero re-extraction work.
A future PHP migration script will include $file_path and use the returned array directly — no parsing layer required.
For the human reading them while building in Bricks, plain PHP arrays are perfectly readable.

French translations

These files are EN only. The FR translations will live inside WordPress, written by the linguist via WPML's Translation Editor against each Bricks-edited page.

3.0 KiB Raw Permalink Blame History Unescape Escape