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>
This commit is contained in:
52
content-source/README.md
Normal file
52
content-source/README.md
Normal file
@@ -0,0 +1,52 @@
|
||||
# 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:
|
||||
|
||||
1. **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…).
|
||||
2. **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 :
|
||||
|
||||
```php
|
||||
'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.
|
||||
Reference in New Issue
Block a user