j.foucher
026be81373
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>
39 lines
1.2 KiB
PHP
39 lines
1.2 KiB
PHP
<?php
|
|
/**
|
|
* Asterion Bricks — Default page template
|
|
*
|
|
* If the current page has Bricks data in its `_bricks_page_content_2` post
|
|
* meta, defer to Bricks' own renderer (Bricks\Frontend::render_content). This
|
|
* is the same pattern Bricks parent's page.php uses; we keep it here so the
|
|
* child theme stays in charge of the markup wrapping (header, footer).
|
|
*
|
|
* Otherwise fall back to the standard the_content() loop — covers pages
|
|
* still rendered from post_content (Gutenberg) and any temporarily-empty
|
|
* page that just hits a non-Bricks Custom Template.
|
|
*
|
|
* @package AsterionBricks
|
|
*/
|
|
defined('ABSPATH') || exit;
|
|
|
|
get_header();
|
|
|
|
$av_bricks_data = class_exists('\\Bricks\\Helpers')
|
|
? \Bricks\Helpers::get_bricks_data(get_the_ID(), 'content')
|
|
: null;
|
|
|
|
if (! empty($av_bricks_data) && class_exists('\\Bricks\\Frontend')) {
|
|
// Bricks emits its own <main id="brx-content"> wrapper — render with `div`
|
|
// tag so we don't end up with double <main> (the global one comes from
|
|
// header.php / footer.php).
|
|
\Bricks\Frontend::render_content($av_bricks_data, ['id' => 'brx-content'], '', '', 'div');
|
|
} else {
|
|
if (have_posts()) {
|
|
while (have_posts()) {
|
|
the_post();
|
|
the_content();
|
|
}
|
|
}
|
|
}
|
|
|
|
get_footer();
|