/* Brand accent override for the "Good" theme's default teal (--bs-primary: #4FC9DA) -- same green, same hue-rotation method, as login.registrostupefacenti.it's brand.css (H 187 -> H 140, each token's own saturation/lightness preserved). Kept as a separate file per subdomain rather than one shared stylesheet, since each subdomain has its own document root and the two files will diverge as each app grows its own page-specific overrides -- same reasoning login's brand.css already documents for why the register-photo rule lives there and not here. */ @font-face { font-family: 'Inter'; font-style: normal; font-weight: 300 700; font-display: swap; src: url(../fonts/inter/inter-latin-variable.woff2) format('woff2'); } :root { --bs-primary: #4FDA7D; --bs-primary-rgb: 79, 218, 125; --bs-primary-active: #30B65C; --bs-primary-light: #DDFCE7; --bs-primary-inverse: #FFFFFF; --bs-primary-text-emphasis: #205732; --bs-primary-bg-subtle: #DCF8E6; --bs-primary-border-subtle: #B9F0CB; } /* The sidebar's active/hovered ("here") menu-item color is hardcoded to the theme's original teal (#4FC9DA) in style.bundle.css's :root block, not derived from --bs-primary like ~200 other rules are -- the same kind of locally-scoped override login's brand.css already found for .btn-primary's button states. Using --bs-primary-active rather than the brighter --bs-primary itself: the base green is light enough that as small menu-item text/icon color on the sidebar's near-white active background (#F8F6F2) it would be low-contrast, the same reasoning that picked --bs-primary-text-emphasis over the base green for the password-reset email's plain-text link. */ :root { --bs-menu-link-color-active: #30B65C; --bs-menu-link-color-here: #30B65C; } /* Swap the light-sidebar layout's default canvas (page white, sidebar cream #F8F6F2) for the more common admin-dashboard convention: sidebar white, page/content area light gray -- cards stay white (they follow --bs-body-bg, untouched) so they read as boxes floating on the gray canvas. Same specificity/selector as style.bundle.css's own [data-bs-theme=light] block these two variables come from, so source order (brand.css loads after) is enough to win, no !important needed. */ [data-bs-theme=light] { --bs-app-light-sidebar-page-bg-color: var(--bs-app-bg-color); --bs-app-light-sidebar-bg-color: #FFFFFF; } /* This theme's whole "gray" family isn't neutral -- every shade carries a warm cream/brown tint (e.g. --bs-gray-600 #8E887A: R=8E, G=88, B=7A, not R=G=B), matching the original cream sidebar/card look brand.css already overrides above. The first pass here only touched the --bs-gray-N scale, --bs-text-gray-N, --bs-text-muted, --bs-light and --bs-secondary, and the UI still read yellowish, because Keenthemes bakes this same warm palette into ~90 OTHER root-level custom properties that don't chain back to the --bs-gray-N scale at all -- most visibly the whole family of sidebar and header custom properties (menu link, icon, bullet and arrow colors, search input color, sidebar background), plus --bs-body-color, --bs-heading-color, --bs-tertiary-bg, --bs-secondary-bg, several inverse, subtle and active variants, the scrollbar colors, and the menu colors. Every property below was found programmatically -- scanning this theme's four light-mode root-scoped blocks in style.bundle.css (lines 7-128, 28507-28666, 48127-48135, 49885-49979) for any custom property whose literal value was one of this palette's 9 warm hex codes -- then mapped through the same neutral equivalents as before (R=G=B, computed by averaging each source color's channels), so nothing in this family was missed by hand. Re-asserted here rather than patched in the vendor file, same reasoning as every other override in this file. --bs-app-bg-color (the page canvas, tinted #F5F8FA, not an exact palette match so the scan didn't catch it) gets the same treatment by hand. Dark theme's gray scale is left alone -- data-bs-theme is hardcoded to "light" in _layout.html.twig with no toggle, so that block is unreachable. CAUTION for future edits to this comment: never place a star character directly next to a slash character anywhere in this comment's own text, in either order -- that two-character sequence is a CSS comment boundary marker even inside a comment's own prose, and the parser honors it there too, ending the comment wherever it first occurs. That exact typo shipped here once already, from writing wildcard property names joined by bare slashes (a star-ending name immediately followed by a slash-leading one): it silently ended this comment after only three lines, dumped the rest as exposed raw text, and a later occurrence of the other ordering of that same two-character sequence opened a second real comment -- which swallowed the entire :root block below as the discarded body of an invalid rule, so the whole gray-neutralization fix silently never applied in any real browser, despite reading fine in a plain-text diff, passing every grep, php -l and brace-count check, and being reachable at the right URL with the right bytes on disk the whole time. Only inspecting the browser's own parsed/matched-rules view (DevTools Computed/Styles panel) surfaced it. Use commas, not slashes, when listing a family of property names in a comment, and spell out either boundary marker in words rather than typing its literal two characters if it ever needs to be mentioned. */ :root { --bs-app-bg-color: #F8F8F8; --bs-app-light-header-btn-custom-color: #6C6C6C; --bs-app-light-header-menu-arrow-color: #8B8B8B; --bs-app-light-header-menu-arrow-color-hover: #858585; --bs-app-light-header-menu-bullet-color: #8B8B8B; --bs-app-light-header-menu-bullet-color-active: #3C3C3C; --bs-app-light-header-menu-bullet-color-hover: #858585; --bs-app-light-header-menu-icon-color: #8B8B8B; --bs-app-light-header-menu-icon-color-hover: #858585; --bs-app-light-header-menu-link-color: #858585; --bs-app-light-header-menu-link-color-hover: #3C3C3C; --bs-app-light-header-search-icon-color: #6C6C6C; --bs-app-light-header-search-input-color: #6C6C6C; --bs-app-light-header-search-input-placeholder-color: #ADADAD; --bs-app-light-sidebar-bg-color: #F5F5F5; --bs-app-light-sidebar-btn-custom-color: #8B8B8B; --bs-app-light-sidebar-header-navbar-btn-custom-color: #6C6C6C; --bs-app-light-sidebar-header-navbar-btn-custom-icon-color: #6C6C6C; --bs-app-light-sidebar-header-search-icon-color: #6C6C6C; --bs-app-light-sidebar-header-search-input-color: #6C6C6C; --bs-app-light-sidebar-header-search-input-placeholder-color: #ADADAD; --bs-app-light-sidebar-logo-icon-custom-color: #ADADAD; --bs-app-light-sidebar-menu-arrow-color: #8B8B8B; --bs-app-light-sidebar-menu-arrow-color-hover: #858585; --bs-app-light-sidebar-menu-bullet-color: #D0D0D0; --bs-app-light-sidebar-menu-bullet-color-hover: #ADADAD; --bs-app-light-sidebar-menu-heading-color: #ADADAD; --bs-app-light-sidebar-menu-icon-color: #8B8B8B; --bs-app-light-sidebar-menu-icon-color-hover: #8B8B8B; --bs-app-light-sidebar-menu-link-color: #6C6C6C; --bs-app-light-sidebar-menu-link-color-hover: #3C3C3C; --bs-app-light-sidebar-menu-root-arrow-color: #8B8B8B; --bs-app-light-sidebar-menu-root-arrow-color-hover: #858585; --bs-app-light-sidebar-menu-root-bullet-color: #D0D0D0; --bs-app-light-sidebar-menu-root-bullet-color-hover: #ADADAD; --bs-app-light-sidebar-menu-root-icon-color: #ADADAD; --bs-app-light-sidebar-menu-root-icon-color-hover: #8B8B8B; --bs-app-light-sidebar-menu-root-link-color: #6C6C6C; --bs-app-light-sidebar-menu-root-link-color-hover: #3C3C3C; --bs-app-light-sidebar-select-custom-color: #ADADAD; --bs-body-color: #1F1F1F; --bs-component-hover-bg: #F5F5F5; --bs-dark-bg-subtle: #ADADAD; --bs-dark-border-subtle: #8B8B8B; --bs-dark-text-emphasis: #6C6C6C; --bs-engage-btn-color: #3C3C3C; --bs-engage-btn-color-active: #3C3C3C; --bs-engage-btn-icon-color: #858585; --bs-gray: #858585; --bs-gray-100: #F5F5F5; --bs-gray-100-rgb: 245, 245, 245; --bs-gray-200: #F0F0F0; --bs-gray-200-rgb: 240, 240, 240; --bs-gray-300: #D0D0D0; --bs-gray-300-rgb: 208, 208, 208; --bs-gray-400: #ADADAD; --bs-gray-400-rgb: 173, 173, 173; --bs-gray-500: #8B8B8B; --bs-gray-500-rgb: 139, 139, 139; --bs-gray-600: #858585; --bs-gray-600-rgb: 133, 133, 133; --bs-gray-700: #6C6C6C; --bs-gray-700-rgb: 108, 108, 108; --bs-gray-800: #3C3C3C; --bs-gray-800-rgb: 60, 60, 60; --bs-gray-900: #1F1F1F; --bs-gray-900-rgb: 31, 31, 31; --bs-gray-dark: #3C3C3C; --bs-heading-color: #1F1F1F; --bs-highlight-color: #1F1F1F; --bs-light: #F5F5F5; --bs-light-active: #F0F0F0; --bs-light-border-subtle: #F0F0F0; --bs-light-inverse: #3C3C3C; --bs-light-rgb: 245, 245, 245; --bs-light-text-emphasis: #6C6C6C; --bs-menu-heading-color: #8B8B8B; --bs-menu-link-bg-color-active: #F5F5F5; --bs-menu-link-bg-color-here: #F5F5F5; --bs-menu-link-bg-color-hover: #F5F5F5; --bs-menu-link-bg-color-show: #F5F5F5; --bs-rating-color-default: #ADADAD; --bs-scrollbar-color: #F0F0F0; --bs-scrollbar-hover-color: #D0D0D0; --bs-secondary: #F0F0F0; --bs-secondary-active: #ADADAD; --bs-secondary-bg: #F0F0F0; --bs-secondary-inverse: #3C3C3C; --bs-secondary-rgb: 240, 240, 240; --bs-tertiary-bg: #F5F5F5; --bs-text-gray-100: #F5F5F5; --bs-text-gray-200: #F0F0F0; --bs-text-gray-300: #D0D0D0; --bs-text-gray-400: #ADADAD; --bs-text-gray-500: #8B8B8B; --bs-text-gray-600: #858585; --bs-text-gray-700: #6C6C6C; --bs-text-gray-800: #3C3C3C; --bs-text-gray-900: #1F1F1F; --bs-text-light: #F5F5F5; --bs-text-muted: #8B8B8B; --bs-text-secondary: #F0F0F0; } /* Round 2 of the gray sweep above missed two more things, both because the first scan only matched literal hex-equality against the 9 known --bs-gray-* codes: 1. A second family of cream-tinted border/bg colors that are DIFFERENT shades of the same warm cream (sidebar scrollbar, custom-button bg, search-input border, header page-card border, header active-menu-link bg) -- e.g. #EFE9E1, #E8E5DD -- close enough to the gray-100/200 family to read as "still yellowish" but not an exact match to those 9 codes, so the hex-equality scan walked right past them. Found the same way as before but by eye against the same four line ranges, then neutralized the same way (channel-average -> R=G=B). 2. --bs-success itself (#B8D935) is a genuine yellow-green/lime, not a cream-gray at all -- it was never in scope for the "grays" scan, but it's exactly the color the "yellowish green" report was about: it's what "Attivo"/"OK" badges and the "+qty" carico figures render in (badge-light-success / text-success, substance.html.twig, substances. html.twig, movement.html.twig). Fixed with the same hue-rotation method as the --bs-primary teal->green swap at the top of this file: every member of the --bs-success family (active/light/text-emphasis/ bg-subtle/border-subtle/rgb, plus the --bs-text-success/--bs-form- valid-* aliases that mirror it 1:1) rotated by the same delta (+78deg, taking the base color's H72 to a true H150 green) with each color's own saturation/lightness preserved, landing near but distinct from the brand primary (#4FDA7D, H140) so success still reads as its own accent. */ :root { --bs-app-light-sidebar-scrollbar-color: #EEEEEE; --bs-app-light-sidebar-btn-custom-bg-color: #E6E6E6; --bs-app-light-sidebar-btn-custom-bg-color-active: #E1E1E1; --bs-app-light-sidebar-header-search-input-border-color: #E8E8E8; --bs-app-light-sidebar-header-navbar-btn-custom-border-color: #E8E8E8; --bs-app-dark-sidebar-btn-custom-color: #727272; --bs-app-dark-sidebar-header-search-input-border-color: #E8E8E8; --bs-app-dark-sidebar-header-navbar-btn-custom-border-color: #E8E8E8; --bs-app-light-header-page-card-border-color: #E3E3E3; --bs-app-light-header-menu-link-bg-color-active: #F9F9F9; --bs-app-dark-header-page-card-border-color: #E3E3E3; --bs-app-mini-sidebar-header-search-input-border-color: #E8E8E8; --bs-app-mini-sidebar-header-btn-custom-border-color: #E8E8E8; --bs-app-mini-sidebar-header-btn-custom-border-color-active: #E8E8E8; --bs-app-overlay-page-card-border-color: #E3E3E3; --bs-success: #35D987; --bs-success-rgb: 53, 217, 135; --bs-success-active: #22BE70; --bs-success-light: #DBFBEC; --bs-success-text-emphasis: #155736; --bs-success-bg-subtle: #D7F7E7; --bs-success-border-subtle: #AEF0CF; --bs-text-success: #35D987; --bs-form-valid-color: #35D987; --bs-form-valid-border-color: #35D987; } /* style.bundle.css has a stray, unscoped ".card" rule (right after its testimonials-slider component's rules -- almost certainly meant to be nested under .testimonials-slider-* in the vendor's SCSS and leaked to the top level) that repaints EVERY card's background to a 30%-opacity cream tint and its border to a slightly different color, silently overriding the real ".card" rule's --bs-card-bg/--bs-card-border-color-driven values. Invisible while the page background was white (30%-opacity near-white on white looks white); surfaced as "cards aren't white" the moment the page canvas above became gray. Re-asserted here rather than patched in the vendor file, consistent with brand.css being the place for this kind of override. */ .card { background-color: var(--bs-card-bg); border-color: var(--bs-card-border-color); } /* The overlay layout's sidebar (icon rail) doesn't route its active/hover/ here icon color through --bs-menu-link-color-active at all -- it's a second, separate hardcoded color (#F06445, orange) scoped under [data-kt-app-layout=overlay], so the :root override above doesn't reach it. Same root cause as that override, different rule to patch. */ [data-kt-app-layout=overlay] .app-sidebar .menu > .menu-item.hover:not(.here) > .menu-link:not(.disabled):not(.active):not(.here) .menu-icon i, [data-kt-app-layout=overlay] .app-sidebar .menu > .menu-item:not(.here) .menu-link:hover:not(.disabled):not(.active):not(.here) .menu-icon i, [data-kt-app-layout=overlay] .app-sidebar .menu > .menu-item.here > .menu-link .menu-icon i, [data-kt-app-layout=overlay] .app-sidebar .menu > .menu-item.show > .menu-link .menu-icon i, [data-kt-app-layout=overlay] .app-sidebar .menu > .menu-item .menu-link.active .menu-icon i { color: #30B65C; } /* Chrome/Edge/Safari paint their own yellow "remembered value" background on any text input via the UA-only :-webkit-autofill pseudo-class, as soon as the browser has -- or thinks it might get -- a saved value for that field. This can't be reached with a plain background-color override (the UA background wins over authored background-color no matter its specificity/ origin); the only thing that beats it is an opaque inset box-shadow big enough to cover the whole field, plus -webkit-text-fill-color since autofill also forces its own text color. autocomplete="off" on the two free-text search fields (substance.html.twig, _layout.html.twig) was tried first and wasn't enough -- recent Chrome still applies this styling to off inputs it has prior page-visit values for, and the effect isn't scoped to the two search boxes anyway (any .form-control the browser has seen a value in before shows the same yellow). Blanket-covering every .form-control here rather than chasing which specific fields Chrome decides to flag. Solid/plain fill colors mirror each variant's own resting background (--bs-gray-100/--bs-gray-200 solid vs --bs-body-bg plain) so autofill is invisible rather than just "less yellow". No Firefox equivalent needed -- Gecko has never painted an autofill background. */ .form-control:-webkit-autofill, .form-control:-webkit-autofill:hover, .form-control:-webkit-autofill:focus, .form-control:-webkit-autofill:active { box-shadow: 0 0 0 1000px var(--bs-body-bg) inset; -webkit-text-fill-color: var(--bs-gray-700); caret-color: var(--bs-gray-700); transition: background-color 600000s 0s, color 600000s 0s; } .form-control.form-control-solid:-webkit-autofill, .form-control.form-control-solid:-webkit-autofill:hover, .form-control.form-control-solid:-webkit-autofill:focus, .form-control.form-control-solid:-webkit-autofill:active { box-shadow: 0 0 0 1000px var(--bs-gray-100) inset; } .form-control.form-control-solid:-webkit-autofill:focus, .form-control.form-control-solid:-webkit-autofill.focus { box-shadow: 0 0 0 1000px var(--bs-gray-200) inset; }