/* ============================================================ gemuese-balkon.de — Theme-Glue ------------------------------------------------------------ Was hier hineingehört: WordPress-Brücken. Regeln, die es nur deshalb gibt, weil das Design-System in WordPress läuft und nicht in einer leeren HTML-Seite — Core-Kaskaden-Fallen, Block-Editor-Marker-Klassen, geerbte Twenty-Twenty-Five-Stile, Übergangsregeln für noch nicht umbenannten Altcontent. Was hier NICHT hineingehört: Gestaltung. Die steht vollständig in gb-design-system.css von Claude Design. Diese Datei existiert, damit jene Datei beim nächsten Sync unverändert ersetzt werden kann, ohne dass die Brücken mitverloren gehen. Lädt nach gb-design-system.css (deps-Kette in functions.php) und damit auch nach global-styles-inline-css. ============================================================ */ /* ---------- 1. Tote Twenty-Twenty-Five-Slugs auffangen ---------- Übernommen aus der kitchencouple-Migration (Fund 26.07.2026). theme.json ERSETZT die Eltern-Palette, die Eltern-STYLES bleiben aber gemergt. Twenty Twenty-Five verweist darin auf base, contrast und accent-1…6 — Slugs, die unsere Palette nicht kennt. Die Verweise laufen ins Leere und fallen still auf currentColor zurück. Sichtbarste Folge bei KC: der Fokus-Rahmen auf Buttons (outline-color: accent-4) wurde auf hellem Grund praktisch unsichtbar — ein echter WCAG-2.4.7-Verstoß, der in keiner Sichtprüfung auffällt, weil man den Fokus-Ring nur mit der Tastatur zu sehen bekommt. Auf eigene Tokens mappen statt die Slugs in die Palette aufzunehmen: die Palette soll im Editor sauber bleiben und nur zeigen, was CDs System wirklich vorsieht. */ :root { --wp--preset--color--base: var(--wp--preset--color--surface); --wp--preset--color--base-2: var(--wp--preset--color--surface-cream); --wp--preset--color--contrast: var(--wp--preset--color--ink); --wp--preset--color--contrast-2: var(--wp--preset--color--ink-muted); --wp--preset--color--contrast-3: var(--wp--preset--color--ink-soft); --wp--preset--color--accent-1: var(--wp--preset--color--green-800); --wp--preset--color--accent-2: var(--wp--preset--color--green-600); --wp--preset--color--accent-3: var(--wp--preset--color--lime); --wp--preset--color--accent-4: var(--wp--preset--color--green-700); --wp--preset--color--accent-5: var(--wp--preset--color--surface-cream); --wp--preset--color--accent-6: var(--wp--preset--color--ink-muted); } /* ---------- 2. has-text-color schlägt die gewählte Farbe ---------- WordPress-Core-Kaskaden-Falle, bei kitchencouple am 31.07.2026 per CSSOM-Diagnose im Live-Browser verifiziert. Sobald ein Block über den Farb-Picker eine BENANNTE Preset-Textfarbe bekommt (z. B. has-lime-ink-color), hängt der Block-Editor IMMER zusätzlich die generische Marker-Klasse has-text-color an dasselbe Element. Das ist Gutenberg-Standardverhalten und nicht abschaltbar. WordPress gibt in global-styles-inline-css für BEIDE Klassen einen Regelsatz mit exakt gleicher Spezifität (0,1,0) UND !important aus — has-text-color aber NACH der benannten Klasse. Bei Gleichstand in Spezifität und Wichtigkeit entscheidet allein die Reihenfolge, also gewinnt die generische Klasse und fällt auf die Standard-Textfarbe zurück. Die eigentlich gewählte Farbe kommt nie an. ⚠️ Bei KC war das dreimal einzeln als „Fusion Builder überschreibt die Farbe" fehldiagnostiziert und mit Element-!important gepatcht. Fusion war nicht die Ursache — das Plugin klebt seine Klasse nur zufällig gleichzeitig auf fast jede Überschrift. Reine Korrelation. Wer diesen Fehler bei GB sieht, sucht bitte nicht wieder bei Avada. Alle Slugs außer "ink" selbst — has-text-color allein, ohne benannte Preset-Klasse, ist ohnehin korrekt. */ .has-green-900-color.has-text-color { color: var(--wp--preset--color--green-900) !important; } .has-green-800-color.has-text-color { color: var(--wp--preset--color--green-800) !important; } .has-green-700-color.has-text-color { color: var(--wp--preset--color--green-700) !important; } .has-green-600-color.has-text-color { color: var(--wp--preset--color--green-600) !important; } .has-green-500-color.has-text-color { color: var(--wp--preset--color--green-500) !important; } .has-lime-color.has-text-color { color: var(--wp--preset--color--lime) !important; } .has-lime-ink-color.has-text-color { color: var(--wp--preset--color--lime-ink) !important; } .has-orange-color.has-text-color { color: var(--wp--preset--color--orange) !important; } .has-orange-ink-color.has-text-color { color: var(--wp--preset--color--orange-ink) !important; } .has-surface-color.has-text-color { color: var(--wp--preset--color--surface) !important; } .has-surface-cream-color.has-text-color { color: var(--wp--preset--color--surface-cream) !important; } .has-surface-cream-warm-color.has-text-color{ color: var(--wp--preset--color--surface-cream-warm) !important; } .has-surface-green-color.has-text-color { color: var(--wp--preset--color--surface-green) !important; } .has-surface-lime-color.has-text-color { color: var(--wp--preset--color--surface-lime) !important; } .has-surface-orange-color.has-text-color { color: var(--wp--preset--color--surface-orange) !important; } .has-ink-heading-color.has-text-color { color: var(--wp--preset--color--ink-heading) !important; } .has-ink-muted-color.has-text-color { color: var(--wp--preset--color--ink-muted) !important; } .has-ink-soft-color.has-text-color { color: var(--wp--preset--color--ink-soft) !important; } .has-ink-on-dark-color.has-text-color { color: var(--wp--preset--color--ink-on-dark) !important; } .has-link-color.has-text-color { color: var(--wp--preset--color--link) !important; } /* ---------- 3. Seitenrand nach CDs Staffelung ---------- CDs Abschnitt 35b regelt den Rand über eine eigene Klasse .gb-page. In WordPress kommt derselbe Rand aus dem Root-Padding, weil davon auch alignfull/alignwide abhängen (useRootPaddingAwareAlignments). Die Grundstufe steht in theme.json, die Stufen brauchen Media Queries und damit diese Datei. Die Werte sind CDs, nicht neu erfunden: mobil bewusst schmal, weil 16 px bei 390 px Schirmbreite noch 358 px Textbreite lassen — bei 40 px wären es 310 und die Zeile bräche mitten im Wort. */ @media (min-width: 620px) { :root { --wp--style--root-padding-left: 24px; --wp--style--root-padding-right: 24px; } } @media (min-width: 1024px) { :root { --wp--style--root-padding-left: 40px; --wp--style--root-padding-right: 40px; } } /* ---------- 4. Query-Loop im Kartenraster ---------- ⚠️ Hier bewusst KEIN display/gap/grid-template-columns. Das gehört vollständig CD (Abschnitt 19 Grundregel, Abschnitt 36 Modifier). Eine Regel .gb-cards{…} an dieser Stelle stünde auf derselben Spezifität wie .gb-cards--3 (beide 0,1,0), lüde aber später — und würde die feste Spaltenzahl still aushebeln. Beim Schreiben dieser Datei genau so passiert und vor dem ersten Deploy korrigiert. Übrig bleiben zwei Dinge, die nur WordPress erzeugt: */ /* Core hängt dem Query-Block eine Layout-Klasse an und setzt darüber Abstände zwischen Geschwistern (.is-layout-flow > * + *). Im Raster regelt das gap — die Core-Margins kämen obendrauf und verzögen die Zeilenhöhe unregelmäßig, je nachdem welche Karte ein Bild hat. */ .gb-cards:where(.is-layout-flow, .is-layout-constrained) > * { margin-block-start: 0; margin-block-end: 0; } /* Paginierung und Leer-Meldung sind Kinder des Query-Blocks und zählen sonst als Rasterzelle mit — sichtbar als leere Lücke neben der letzten Karte. Über die volle Zeile ziehen statt aus dem Raster nehmen, damit sie zentrierbar bleiben. */ .gb-cards > .wp-block-query-pagination, .gb-cards > .wp-block-query-no-results { grid-column: 1 / -1; } /* ---------- 5. Video-Rahmen: Sicherheitsnetz ---------- ⚠️ Bewusste Ausnahme von CDs Grundsatz „keine Legacy-Regeln". 283 Videos in 160 unmigrierten Beiträgen stecken in base64-kodierten Fusion-Code-Blöcken und tragen dort die alte Klasse .videoWrapper. Diese Beiträge lassen sich nicht per Skript umbenennen — der Content ist kodiert. Die Brücke ist ein the_content-Filter im mu-plugin gb-fusion-fallback.php, der .videoWrapper auf CDs .gb-video umschreibt. Diese fünf Zeilen sind das Netz darunter. Sie greifen, wenn das mu-plugin fehlt, deaktiviert wird oder — der realistische Fall — nach Phase 6.2 planmäßig entfernt wird, während irgendwo noch ein Rest .videoWrapper liegt. Ohne sie kollabiert das Video auf Höhe 0 und der Beitrag sieht aus, als fehle er ganz. Selbsttragend formuliert: eigenes aspect-ratio, keine Abhängigkeit von .gb-video. Wenn diese Regel eines Tages nichts mehr trifft, kann sie ersatzlos weg — sie hängt an nichts anderem. Prüfen mit: Suche nach "videoWrapper" über alle Posts, Soll = 0. */ .videoWrapper { position: relative; aspect-ratio: 16 / 9; width: 100%; margin: var(--gb-space-lg) 0; max-width: var(--gb-text-max); } .videoWrapper > iframe, .videoWrapper > video, .videoWrapper > object, .videoWrapper > embed { position: absolute; inset: 0; width: 100%; height: 100%; border: 0; } /* Alte Padding-Hack-Varianten setzten die Höhe über ein ::before mit padding-top: 56.25%. Zusammen mit aspect-ratio ergäbe das doppelte Höhe. */ .videoWrapper::before { content: none; } /* ---------- 5b. Geschlossener Zustand der Panels ---------- 📮 GEHÖRT EIGENTLICH ZU CD — bitte bei nächster Gelegenheit dorthin zurückspielen und hier wieder entfernen. Lücke im gelieferten System (gefunden 08.08.2026 beim Verdrahten): .gb-mobilenav ist position:fixed; inset:0; display:flex — ohne Gegenstück für „zu". .gb-search__panel ebenso. Die Entwurfsseiten zeigen beide isoliert im offenen Zustand, dort fällt es nicht auf. Im echten Theme läge das Mobil-Menü damit permanent über der Seite. Der Zustand wird von assets/js/gb-header.js über die Klasse is-open geschaltet (Attributpaare data-gb-toggle / data-gb-panel / data-gb-scrim). ⚠️ Nicht mit [hidden] lösen: die Regel .gb-mobilenav{display:flex} steht auf 0,1,0 und schlägt das UA-Stylesheet, das Panel bliebe trotz Attribut sichtbar. Der Zustand muss über eine Klasse derselben Ebene laufen. ⚠️ An [data-gb-panel] gebunden, NICHT an die Bausteinklasse allein. .gb-search__panel kommt auch dort vor, wo es nichts zu schalten gibt — CDs 404-Seite nutzt es als ganz normal sichtbares Suchformular. Eine Regel auf .gb-search__panel:not(.is-open) hätte es dort unsichtbar gemacht. Nur was das Skript kennt, darf es auch verstecken. */ [data-gb-panel]:not(.is-open) { display: none; } /* Scrim hinter dem offenen Panel. Liegt unter .gb-mobilenav (z-index 90) und über allem anderen. */ .gb-scrim { display: none; position: fixed; inset: 0; z-index: 80; background: rgba(26, 61, 29, 0.5); } .gb-scrim.is-open { display: block; } /* Hintergrund nicht mitscrollen lassen, solange ein Panel offen ist. Das JS setzt gb-panel-open auf . */ .gb-panel-open { overflow: hidden; } /* ---------- 5c. screen-reader-text ---------- WordPress-Konvention, kein Designelement — deshalb hier und nicht bei CD. Core-Blöcke (Suchformular, Kommentar-Navigation, Paginierung) geben die Klasse selbst aus und erwarten, dass das Theme sie definiert. Twenty Twenty-Five bringt sie mit; nach dem Wechsel auf unser Stylesheet käme sonst überall sichtbarer Hilfstext zum Vorschein. clip-path statt des alten clip: die veraltete Variante entfernt das Element in manchen Screenreadern mit aus dem Baum. */ .screen-reader-text { position: absolute !important; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; border: 0; } /* Beim Tabben sichtbar werden — sonst wäre ein Sprunglink wertlos. */ .screen-reader-text:focus { clip-path: none; width: auto; height: auto; margin: 0; padding: var(--gb-space-xs) var(--gb-space-sm); background: var(--gb-surface); color: var(--gb-ink); z-index: 100; } /* ---------- 5d. Nackte Trennlinie ---------- Gehört zu den drei fusion_separator-Fundstellen, die das mu-plugin als
ohne Klasse ausgibt. Warum ohne Klasse: CDs .gb-divider ist KEIN Ersatz für eine Trennlinie, sondern ein Bereichstrenner-Baustein mit grüner Fläche, Nummern-Badge, Titel und Notiz (Abschnitt 42, fünf Kindklassen). Ein
hätte einen leeren grünen Balken ergeben. Der Plan hatte diese Zuordnung vorgesehen — beim Nachsehen im Stylesheet widerlegt, 08.08.2026. Ein nacktes
stylt das Design-System nicht, weil es dort schlicht nicht vorkommt. Diese Regel ist deshalb bewusst zurückhaltend: eine Haarlinie in der Randfarbe, mehr nicht. Sie gilt auch für den wp:separator-Block, falls in neuem Content einer gesetzt wird. */ hr, .wp-block-separator { height: 0; border: 0; border-top: 1px solid var(--gb-border); margin: var(--gb-space-xl) auto; max-width: var(--gb-text-max); } /* ---------- 5e. Block-Markup an CDs Bausteine anpassen ---------- CDs Entwurfsseiten sind handgeschriebenes HTML. Die Core-Blöcke geben dieselbe Sache leicht anders aus. Drei Stellen, an denen das auffällt — alle drei sind WordPress-Eigenheiten, keine Designfragen. */ /* wp:post-featured-image rendert ein
, CD hatte ein
.
bringt vom Browser 1em/40px Rand mit und würde die 120px-Spalte der Beitragszeile sprengen. */ .gb-postrow__media, .gb-card__media { margin: 0; } /* wp:post-excerpt legt den Text in ein

innerhalb des Block-

. Die Klasse landet am div, das line-clamp also auch — der Rand des inneren

stünde sonst zusätzlich unter der abgeschnittenen Zeile. */ .gb-postrow__text > p, .gb-card__text > p { margin: 0; } /* wp:query-pagination-numbers schiebt einen -Wrapper um die Zahlen. CDs Regel ".gb-pagination span" trifft ihn mit und machte aus dem Wrapper selbst eine 44px-Schaltfläche mit Rahmen — sichtbar als leerer Kasten vor den Seitenzahlen. display:contents nimmt ihn aus dem Layout, ohne ihn aus dem Screenreader-Baum zu entfernen. */ .gb-pagination > .wp-block-query-pagination-numbers { display: contents; } /* Core benennt den aktuellen Zustand .current und die Auslassung .dots, CD nennt sie __current und __gap. Beide Namen auf dieselbe Darstellung führen, statt am Markup zu drehen. */ .gb-pagination .page-numbers.current { background: var(--gb-green-800); border-color: var(--gb-green-800); color: #fff; } .gb-pagination .page-numbers.dots { border: 0; min-width: 24px; color: var(--gb-ink-muted); font-weight: 400; } /* ---------- 6. Icons im Übergang ---------- ⏳ BEFRISTET. Entfernen, sobald das Umbenennungsskript gelaufen ist und eine Suche nach "gb-icon-" (einfacher Bindestrich) über alle Posts und Pages 0 Treffer liefert. Der Bestand schreibt gb-icon-calendar, CDs System erwartet gb-icon--calendar (zwei Bindestriche). Die Basisklasse .gb-icon trägt CDs Datei bereits, es fehlen also nur die ::before-Glyphen. ⚠️⚠️ ZWEI ZUORDNUNGEN SIND NICHT DIE NAHELIEGENDEN (gefunden 08.08.2026 beim Öffnen von gb-fonts.css). CD hat zwei Namen neu belegt: Bestand Glyphe CDs Klasse für diese Glyphe gb-icon-calendar \e953 .gb-icon--calendar-solid (NICHT --calendar, das ist \ea5e) gb-icon-store \ea4e .gb-icon--store-front (NICHT --store, das ist \ea5c) Eine stumpfe Umbenennung ein Bindestrich → zwei Bindestriche würde hier ein ANDERES Bild rendern. Kein Fehler, keine leere Kachel, keine Konsolenmeldung — einfach das falsche Icon, 34 Aktivitätsboxen weit. Das Umbenennungsskript muss diese beiden Fälle gesondert behandeln. Die Codepoints unten sind deshalb die des Bestands, nicht die der gleichnamigen CD-Klasse. */ .gb-icon-calendar::before { content: "\e953"; } /* = CDs --calendar-solid */ .gb-icon-store::before { content: "\ea4e"; } /* = CDs --store-front */ .gb-icon-leaf::before { content: "\e9f3"; } .gb-icon-seedling::before { content: "\ea63"; } .gb-icon-inbox::before { content: "\e9fe"; } .gb-icon-hand-lizard::before { content: "\e917"; } .gb-icon-edit::before { content: "\e9f5"; } .gb-icon-hands-wash::before { content: "\ea51"; } .gb-icon-braille::before { content: "\ea50"; } .gb-icon-spa::before { content: "\ea4b"; }