/* SiteWarp Canvas — Canvas-Rendering-Korrekturen (Breite + Icons + Hero-Overlay). Alles wirkt nur im Canvas-Body und kompensiert Effekte der WordPress-/Multisite- Umgebung, die das mitgelieferte Lovable-Design sonst stoeren. */ /* 1) VOLLE BREITE — WordPress/Theme-Beschraenkung neutralisieren, OHNE die des Designs zu zerstoeren. WordPress' constrained-Layout begrenzt direkte Kinder normalerweise auf die globale content-size (Classic-Themes wie Divi z.B. ~820px) -> Seite als schmaler Streifen. Das Lovable-Design bringt seine EIGENE Breiten-Logik mit (Sektionen full-bleed, innere Container max-width via eigene Klassen wie .hero-content:720px, .container, max-w-5xl, .sws-N). FRUEHER wurde das mit `max-width:none !important` auf ALLE is-layout-constrained>* erschlagen. PROBLEM (gemessen 2026-06-18): das nuked auch Lovables EIGENE max-width auf semantisch benannten Containern (.hero-content 720px wurde none -> Hero-Titel lief 1325px breit / zu weit links; callcenter/influencer u.a.). Eine Ausnahmeliste (max-w-/container/sws-) deckte solche Klassen NICHT ab. FAKT: In der Canvas-Umgebung spielt WP GAR KEINEN constrained-max-width ein — global-styles, wp-block-library, classic-theme-styles sind dequeued + Blank-Template (im gerenderten : 0 Treffer fuer is-layout-constrained{max-width}). Der Nuke bekaempfte also eine Beschraenkung, die nicht existiert, und schadete nur. Daher ENTFERNT. Sektionen sind ohne den Nuke von sich aus full-bleed (block-level, keine WP-Begrenzung mehr); innere Container behalten ihre Lovable-max-width. Falls doch ein Theme die WP-content-size-Variable konsumiert, setzen wir sie auf 100% (entschaerft die WP-Regel, ohne die hoeher spezifischen Lovable-max-widths zu ueberschreiben) — das ersetzt den frueheren !important-Hammer verlustfrei. */ .sw-canvas-body { --wp--style--global--content-size: 100%; --wp--style--global--wide-size: 100%; } /* 2) DEKO-ICONS sichtbar machen. Der Multisite-kses-Filter entfernt beim Speichern/Import das stroke-Attribut der inline-SVG-Icons (Lucide-Outline-Icons mit fill:none) -> ohne Strich sind sie unsichtbar (leere Kreise). Strich wiederherstellen via currentColor: - currentColor = die geerbte Textfarbe des Icon-Kontexts. Das ist EXAKT der Mechanismus, den Lovable selbst nutzt (Lucide-Icons haben stroke="currentColor" + eine Tailwind-Farbklasse wie text-accent/text-destructive). So bekommt jedes Icon automatisch seine ORIGINAL-Farbe zurueck — Akzent, Warn-Rot, Neutral-Dunkel, Footer-Hell — pixelgenau wie im Original. - WICHTIG: NICHT var(--accent) verwenden. Viele Portale speichern --accent als rohe HSL-Komponenten ("190 52% 35%", shadcn/Tailwind-Konvention fuer hsl(var(--accent))) -> stroke:var(--accent) ergibt einen UNGUELTIGEN Farbwert -> kein Strich -> Icon unsichtbar (verifiziert: 37 von 80 Portalen betroffen). currentColor umgeht das formatunabhaengig und ist zugleich farbtreuer (mehrfarbige Icons bleiben mehrfarbig). Betrifft nur fill:none-Outline-Icons; gefuellte Grafiken bleiben unberuehrt. WICHTIG (Praezisierung 2026-06-19): Die Strichfarbe NUR dort auf currentColor setzen, wo der kses-Filter das stroke-Attribut wirklich ENTFERNT hat -> `:not([stroke])`. Icons, die ihr stroke="#..." behalten haben (z.B. cybersecurity: stroke="#00C8A0" Teal-Akzent), wurden vorher von `stroke:currentColor` faelschlich auf die dunkle Erbfarbe ueberschrieben -> dunkel-auf-dunkel, unsichtbar. Mit :not([stroke]) behalten sie ihre Originalfarbe; kses-gestrippte bleiben gefixt. */ .sw-canvas-body svg[fill="none"] { stroke-width: 2; stroke-linecap: round; stroke-linejoin: round; } .sw-canvas-body svg[fill="none"]:not([stroke]) { stroke: currentColor; } /* 3) HERO / core-cover-Overlay wiederherstellen. Die Isolation entfernt das wp-block-library-CSS, das dem Cover-Overlay position:absolute/inset:0 gibt. Ohne das kollabiert der grüne Marken-Overlay auf 0x0 -> das Hintergrundbild bleibt ungedaempft (zu hell/hart). Hier die noetige Cover-Geometrie zuruecksetzen: Bild fuellend darunter, Overlay deckend darueber, Inhalt (Text/Buttons) obenauf. */ /* :not(.absolute): manche Heroes nutzen das Cover NICHT als Inhalts-Container, sondern als reine Hintergrund-Ebene mit eigener Klasse "absolute inset-0" hinter einer separaten Inhaltsgruppe (prpartnerportal/getraenkepartnerportal). Ohne die Ausnahme zwingt position:relative dieses BG-Cover in den Fluss (min-height:100vh) -> es schiebt den weissen Hero-Titel nach unten in die naechste helle Sektion (unsichtbar). Mit :not(.absolute) behaelt das BG-Cover sein Tailwind position:absolute und fuellt den Hero als Ebene. */ .sw-canvas-body .wp-block-cover:not(.absolute) { position: relative; } .sw-canvas-body .wp-block-cover img.wp-block-cover__image-background { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; z-index: 0; } .sw-canvas-body .wp-block-cover__background { position: absolute; inset: 0; z-index: 1; } .sw-canvas-body .wp-block-cover__inner-container { position: relative; z-index: 2; }