/* ═══════════════════════════════════════════════════════════ CATEGORY PAGE SHELL Shared by every full-width route: page-templates/category-landing.php (a category) page-templates/categories-landing.php (the index) page-templates/providers-landing.php (the /providers/ index) page-templates/resources-landing.php (the /resources/ hub) page-templates/about-us.php (About Us) page-templates/affiliate-disclosure.php (Affiliate Disclosure) page-templates/privacy-policy.php (Privacy Policy) page-templates/terms-of-use.php (Terms of Use) Version: v1.4 (theme v3.40.31 - providers-landing joins the selector) v3.40.31: /providers/ shipped at v3.40.30 WITHOUT a line in the selector below, so it kept GeneratePress's 1200px cap. Measured on staging at 1440: the page rendered on the #F7F8F9 body background instead of white, and its H1 sat 142.5px right of the /categories/ H1. Exactly the failure the warning below predicts. One line fixes both. About Us joined at v1.2. Its CONTENT is a narrow 820px reading column, but its breadcrumb sits on the site's 1500px axis like every other page's, so it needs the same wrapper release. Without it the trail would indent to GeneratePress's 1200px cap and sit on a different left edge from the rest of the site. ⚠ EVERY page on the informational/legal system needs a line in the selector below. Privacy Policy was built without one and its breadcrumb sat 150px right of About Us at 1512 and 40px right at 1280 — measured, not theorised. Below 1200 nothing shows, because that is where GeneratePress's cap starts to bite, so the defect is invisible at 1024 and narrower. Add the body class when you add the template, and check the breadcrumb at 1512 specifically. The .fp-category-main class is a PAGE-SHELL class, not a category-specific one. The /resources/ hub reuses it rather than introducing a second identical shell under a different name. Page-shell concerns only: releasing the GeneratePress wrapper and making
fill it. No component styling lives here. WHY ITS OWN FILE: in v3.12.1 the wrapper release lived in category-hero.css, which is enqueued ONLY on the category template. The selector matched the Categories index perfectly well - the stylesheet carrying it simply never loaded there, so the index kept the 1200px cap and its grey gutters. A shell concern shared by two templates belongs in a file both load. ═══════════════════════════════════════════════════════════ */ /* ── 1. Release the GeneratePress page wrapper ──────────── * GeneratePress caps its wrapper with * .grid-container { max-width: 1200px } (generatepress main.min.css) * applied to #page. Inside it the hero rendered 1200px at a 1440 viewport, * with 120px of body background (#F7F8F9) showing each side as grey gutters. * * Scoped to the two category body classes, so GeneratePress's 1200px default * is untouched on the homepage and every other page. #masthead and the footer * sit OUTSIDE #page, so neither is affected. */ .page-template-category-landing #page.grid-container, .page-template-categories-landing #page.grid-container, .page-template-providers-landing #page.grid-container, .page-template-resources-landing #page.grid-container, .page-template-about-us #page.grid-container, .page-template-affiliate-disclosure #page.grid-container, .page-template-privacy-policy #page.grid-container, .page-template-terms-of-use #page.grid-container, .page-template-cookie-policy #page.grid-container, .page-template-editorial-methodology #page.grid-container, .page-template-contributor #page.grid-container, .page-template-accessibility #page.grid-container, .error404 #page.grid-container { /* v3.57.136: custom 404 (404.php) */ max-width: 100%; margin-left: 0; margin-right: 0; } /* ── 2. Let
fill that released width ─────────────── * GeneratePress renders #content.site-content as display:flex, so
is a * flex item. Without an explicit basis a flex item is sized by its content: * the category hero happens to have a wide max-content (three cards), so it * filled by accident, but the Categories index has a narrow one and collapsed * to 755.5px inside a 1200px wrapper - measured on staging. * * flex-basis 100% makes both routes fill the wrapper deliberately rather than * depending on how wide their content happens to be. min-width:0 lets grid and * flex children shrink below their min-content width instead of forcing * horizontal overflow. */ .fp-category-main { flex: 1 1 100%; min-width: 0; } /* ── 3. Paint the Providers route white ────────────────── * Every other index component paints its own surface - * .fp-categories-index carries `background-color: var(--fp-color-white)`. * The FROZEN Providers Index v1.0 stylesheet declares no background at all, so * with the wrapper released in §1 the body's #F7F8F9 shows straight through and * the page still reads as a grey band. Releasing the wrapper alone does NOT fix * it - measured: (246,247,248) at 1440 after §1 was applied on its own. * * The rule therefore lives here, in the page shell, and is SCOPED TO THIS * TEMPLATE so no other route is touched. It is a deviation from the * component-paints-itself pattern, taken deliberately because the alternative * is editing a frozen checksummed file. If the Index is ever reopened for a new * version, move the background into providers-index.css and delete this. */ .page-template-providers-landing .fp-category-main { background-color: var(--fp-color-white); } /* ── 4. Providers empty state: separate it from the intro ── * The empty-state paragraph is PAGE-LEVEL content and must not sit in * .fp-pi__grid - inside it, it becomes a grid item and renders at one track * width (measured 326.00px at 1440, 224.00px at 768). * * Outside the grid it needs a gap, and markup alone cannot give it one: the * FROZEN .fp-pi__intro is `margin: 0` and the theme has no spacing utility * class. So one rule, scoped to this template. * * The VALUE IS NOT NEW: --fp-space-m (24px) is exactly what the frozen * .fp-pi__grid uses to separate itself from the same intro. The empty state * simply inherits the separation the directory would have had. * * No card, border, background, icon, alert or component - a margin only. */ .page-template-providers-landing .fp-pi__empty { margin-top: var(--fp-space-m); /* 24px, the frozen grid's own value */ } /* ── 5. Paint the Category Landing route white ──────────── * Reported on the live Business Banking page: a light-grey full-width band * immediately above the Top 4 Picks heading. * * IT IS NOT A BAND, A DIVIDER OR A CONTAINER. Measured at 1440: * .fp-category-hero ends 636px, background #FFFFFF (paints itself) * .tp starts 668px, background #FFFFFF (paints itself) * .tp margin-top 32px - transparent, as every margin is * main / #content / #page ALL rgba(0,0,0,0) - transparent * body rgb(247,248,249) * The 32px margin between the two white surfaces is the only strip on the * route that nothing paints, so the BODY BACKGROUND shows through it and reads * as a grey band. Sampled at 1440: (246,247,248), full viewport width. * * It appeared with Top 4 Picks only because the hero used to be the last * element on the route - there was no gap below it to expose. * * SAME CAUSE, SAME CURE AS §3. That rule paints the Providers route white for * exactly this reason, in exactly this file, with exactly this value. This is * the reuse, not a new treatment: no new colour, no new token, no new element, * no wrapper, and NOTHING in the frozen Top 4 Picks stylesheet is touched. * * The 32px margin is UNCHANGED - the approved distance between the disclosure * position and Top 4 Picks is preserved exactly; only its colour changes. * * Scoped to this template, so no other route is affected. At 1440 and 1100 *
ends exactly at the Top 4 Picks bottom edge, so nothing below it * changes. At 1099/768/390 a 16-24px gap below the component is inside
* and turns white too - recorded deliberately: white above the component and * grey below it would be the same defect inverted. */ .page-template-category-landing .fp-category-main { background-color: var(--fp-color-white); } /* ── 6. Major-section rhythm into the Use Case section ──── * Reported from the live v3.40.34 page: Top 4 Picks has visibly more room * above its heading than Top Business Banks by Use Case has above its own. * * MEASURED, from the last visible content to the next section's H2: * hero card bottom -> Top 4 Picks H2 80.00px at 1440 / 1100 / 1099 * Top Picks bottom -> Use Case H2 32.00px at every width * shortfall 48.00px * * THE 32px BOX-EDGE VALUE WAS NEVER WRONG; IT WAS INCOMPLETE. On this route a * major section contributes its OWN bottom space and the next contributes a * 32px margin. .fp-category-hero:47 declares exactly that: * padding-bottom: var(--fp-space-l) 32px (mobile) * @media (min-width:640px) padding-bottom: var(--fp-space-xl) 48px * so the approved distance is 48 + 32 = 80px, and 32 + 32 = 64px below 640. * * Top 4 Picks contributes ZERO below itself - .tp has padding-bottom 0 - so * the Use Case section's own 32px margin was the entire gap. * * TOP 4 PICKS IS CLOSED AND IS NOT TOUCHED. The missing contribution is added * to the space ABOVE the Use Case section instead, here in the page shell, * scoped to this template. The FROZEN Use Case stylesheet is not edited: its * margin-top:32px stands, and this integration rule (0,2,0) overrides it in * page context only. * * The values and the 640px breakpoint are the hero's own - reused, not chosen. * Authored mobile-first to mirror .fp-category-hero exactly. */ .page-template-category-landing .fp-uc { /* ⚠ ONE GOVERNED VALUE (v3.54.2). Was a 64px literal here and an 80px literal in a >=640 block. Both are now --fp-section-gap, which carries exactly those numbers and is shared with the homepage. Same rendered geometry; one place to change it. See base.css. */ margin-top: var(--fp-section-gap); }