/** * WB Listora — BuddyX Pro 5.1.0 theme integration bridge (dedicated) * * When BuddyX is the active theme, remap Listora's color / surface / * border / button tokens to BuddyX's --bx-color-* token system. This * makes every Listora block render with the customer's chosen BuddyX * palette (light or dark, customizer-driven) instead of Listora's * default brand colors. * * Loaded automatically by class-assets.php when get_template() === * 'buddyx' OR get_stylesheet() === 'buddyx-pro'. Both consume this single * Free-level map (no Pro-side copy). Mapped against BuddyX Pro 5.1.0's * canonical --bx-color-* vocabulary, emitted at render by the theme's * inc/Tokens/Component.php (see the theme's docs/buddyx-pro-design-tokens.md). * Only tokens 5.1.0 actually emits are referenced; everything else derives * from those via color-mix so it still follows the theme palette. * * Dark mode: the theme flips its own --bx-color-* tokens for dark, but the * trigger differs by version: BuddyX 5.1.0 uses `` * (and `data-bx-mode="auto"` to follow the OS), while older builds used the * legacy `body.buddyx-dark-theme` class. Because the :root remap below binds * Listora tokens at :root specificity, they do NOT inherit the theme's dark * values automatically — the dark block at the bottom re-binds them at the * dark-trigger scope (both `body.buddyx-dark-theme` AND `[data-bx-mode="dark"]`, * plus a prefers-color-scheme query gated on `[data-bx-mode="auto"]`). BG-3: * the old comment here wrongly claimed no dark block was needed. * * Architecture note: the bridge ONLY remaps semantic tokens (colors, * surfaces, borders, buttons). Geometry tokens (spacing, radius, * shadow, type scale) stay on Listora's values so the directory * keeps its own visual rhythm independent of theme defaults. * * Font family: NOT mapped here, on purpose. The plugin's components * use `font-family: inherit`, so BuddyX Pro's body face (the theme * emits `--global-font-family`, Inter stack by default) flows through * CSS inheritance — verified live: body, card title (h3), card body, * button, input, and pagination all render in Inter. Adding a * `--listora-font` mapping would be redundant; touch this only if a * future block hardcodes `font-family` (don't — fix the block to * `font-family: inherit` instead). * * @package WBListora */ :root { /* ── Brand / accent ─────────────────────────────────────────── */ --listora-primary: var(--bx-color-accent, var(--wp--preset--color--primary, #2271b1)); --listora-primary-hover: var(--bx-color-button-bg-hover, #135e96); --listora-primary-fg: var(--bx-color-button-fg, #ffffff); /* ── Page + surface backgrounds ─────────────────────────────── */ --listora-bg-base: var(--bx-color-bg, var(--wp--preset--color--base, #ffffff)); --listora-bg-elevated: var(--bx-color-bg-elevated, #ffffff); --listora-bg-muted: var(--bx-color-bg-muted, var(--wp--preset--color--contrast-4, #fafafa)); /* 5.1.0 has no bg-subtle token — bg-muted is its muted surface. */ --listora-bg-surface: var(--bx-color-bg-muted, color-mix(in srgb, var(--listora-bg-base) 95%, #1a1a1a)); /* ── Foreground / text ──────────────────────────────────────── */ --listora-fg-default: var(--bx-color-fg, var(--wp--preset--color--contrast, #1a1a1a)); --listora-fg-strong: var(--bx-color-heading, var(--bx-color-fg, #1a1a1a)); /* * fg-muted is NOT mapped to the theme's muted colour. * * BuddyX Pro's `--bx-color-fg-muted` resolves to #757575, which measured * 4.41:1 on Listora's card and tab surfaces — under the 4.5:1 AA floor * (BC 10208336512). A theme's muted colour is tuned to recede against the * theme's own backgrounds; Listora paints its own, and uses fg-muted for * real information (tab labels, metadata, counts), not decoration. Same * call already documented for fg-faint below. Brand, buttons and surfaces * still bridge to the theme, so the directory keeps looking like the site. */ /* 5.1.0 has no fg-subtle — derive faint by mixing muted toward the bg. */ /* * fg-faint is NOT derived here. Mixing the muted text colour TOWARD the * page background is contrast-destroying by construction: the closer the * mix gets to the surface, the less readable it is. On BuddyX Pro 5.1.0 * it landed at roughly #777 on a near-white page, measuring 3.72:1 on the * listing-card feature badge - under the 4.5:1 AA floor for text that * carries real information (BC 10208336512). Listora's own value applies * instead, which is picked against the surfaces we actually paint. */ /* 5.1.0 has no fg-inverse — the button fg IS the on-accent foreground. */ --listora-fg-inverse: var(--bx-color-button-fg, #ffffff); /* ── Borders ────────────────────────────────────────────────── */ --listora-border-default: var(--bx-color-border, var(--wp--preset--color--contrast-3, #e0e0e0)); --listora-border-subtle: var(--bx-color-border, #e2e8f0); /* 5.1.0 has no border-strong — derive by mixing the border toward fg. */ --listora-border-strong: color-mix(in srgb, var(--bx-color-border, #e0e0e0) 65%, var(--bx-color-fg, #1a1a1a)); /* ── Buttons (when blocks bind directly to button tokens) ──── */ --listora-button-bg: var(--bx-color-button-bg, var(--listora-primary)); --listora-button-bg-hover: var(--bx-color-button-bg-hover, var(--listora-primary-hover)); --listora-button-fg: var(--bx-color-button-fg, #ffffff); --listora-button-fg-hover: var(--bx-color-button-fg-hover, #ffffff); --listora-button-border: var(--bx-color-button-border, var(--listora-primary)); --listora-button-border-hover: var(--bx-color-button-border-hover, var(--listora-primary-hover)); } /* ────────────────────────────────────────────────────────────────── * Dark mode — the theme flips its --bx-color-* tokens under * body.buddyx-dark-theme, but the bridge's :root block above re-binds * the Listora tokens at :root specificity so they would NOT inherit * the dark values automatically. This block re-binds at the same * dark-class scope so Listora tokens follow the theme dark palette. * * Each mapping mirrors the corresponding :root binding above so the * token graph stays consistent (light/dark differ only in source * values, not in mapping logic). No !important. * ────────────────────────────────────────────────────────────────── */ /* * BRAND ONLY in dark. Surfaces, text and borders are deliberately not mapped. * * This block used to remap them from the theme's `--bx-color-*` namespace, on * the assumption that those tokens hold dark values under the dark trigger. * On BuddyX Pro 5.1.0 they do not. Measured on a live site with * `` set by the theme's own toggle: * * --bx-color-bg-elevated #ffffff * --bx-color-bg #f7f7f9 * --bx-color-fg #505050 * --bx-color-heading #003049 * --bx-color-border #e4e3e3 * * Every one is the LIGHT value. The theme ships its dark treatment as a * separate stylesheet (dark-mode.min.css) that restyles elements rather than * rebinding the custom properties, so the `var( …, #1e293b )` dark fallbacks * written here were unreachable: a fallback fires only when the token is * UNSET, and these are set — to white. * * The result was Listora's dark foreground on the theme's light surface: * rgb(245,245,245) on rgb(255,255,255) — 1.09:1 — across Directory selects, * dashboard filters, contact inputs and Needs controls (BC 10208289895). * * Brand colours stay mapped because an accent is the same colour in both * modes. Surfaces, text and borders now fall through to Listora's own dark * palette in listora-base.css: one AA-verified set, rather than a copy per * theme bridge that has to be re-verified every time the theme ships. * * If a future BuddyX genuinely flips `--bx-color-*` under the dark trigger, * re-mapping is a deliberate change to make then. Re-run the measurement * first — this failure mode is silent. */ body.buddyx-dark-theme, :root[data-bx-mode="dark"], [data-bx-mode="dark"] { --listora-primary: var(--bx-color-accent, #ff6b6b); --listora-primary-hover: var(--bx-color-button-bg-hover, #ff8585); --listora-primary-fg: var(--bx-color-button-fg, #0f172a); --listora-button-bg: var(--bx-color-button-bg, var(--listora-primary)); --listora-button-bg-hover: var(--bx-color-button-bg-hover, var(--listora-primary-hover)); --listora-button-fg: var(--bx-color-button-fg, #0f172a); --listora-button-fg-hover: var(--bx-color-button-fg-hover, #0f172a); --listora-button-border: var(--bx-color-button-border, var(--listora-primary)); --listora-button-border-hover: var(--bx-color-button-border-hover, var(--listora-primary-hover)); } /* BuddyX 5.1.0 "auto" mode follows the OS. Honored ONLY when the OS is dark — * this prefers-color-scheme query is GATED on the attribute, so it is NOT a bare * OS-dark flip (BC-9919496983 still holds). Same mappings as the dark block above. */ @media (prefers-color-scheme: dark) { :root[data-bx-mode="auto"], [data-bx-mode="auto"] { --listora-primary: var(--bx-color-accent, #ff6b6b); --listora-primary-hover: var(--bx-color-button-bg-hover, #ff8585); --listora-primary-fg: var(--bx-color-button-fg, #0f172a); --listora-button-bg: var(--bx-color-button-bg, var(--listora-primary)); --listora-button-bg-hover: var(--bx-color-button-bg-hover, var(--listora-primary-hover)); --listora-button-fg: var(--bx-color-button-fg, #0f172a); --listora-button-fg-hover: var(--bx-color-button-fg-hover, #0f172a); --listora-button-border: var(--bx-color-button-border, var(--listora-primary)); --listora-button-border-hover: var(--bx-color-button-border-hover, var(--listora-primary-hover)); } } /* ────────────────────────────────────────────────────────────────── * Component coverage — places where Listora blocks fight BuddyX's * own component rules. Each rule documents why it's here so future * theme migrations can keep / drop intentionally. * ────────────────────────────────────────────────────────────────── */ /* ────────────────────────────────────────────────────────────────── * Bridge intentionally contains NO selector-specificity fixes. * * Listora's primitive layer (assets/css/listora-components.css) lifted * every .listora-btn variant rule to specificity 0,2,0 — that beats * BuddyX's .entry-content a (0,1,1) on every theme without per-theme * patches. This file's only job is colour-token remapping. If you * find yourself adding component overrides here, fix the primitive * instead so the same fix benefits Reign, Astra, and every future * theme. * ────────────────────────────────────────────────────────────────── */