/* Native shop/archive layout -- scoped by conditional enqueue (see functions.php: is_shop() || is_product_taxonomy()), so no extra selector scoping is needed here the way header/footer.css need it. The parent theme's own WooCommerce archive template already renders a real widget-area sidebar (Product Search + Product Categories, configured in wp-admin > Widgets) plus WooCommerce's native sort-by dropdown -- none of that had to be built. This file restyles those stock widgets to match the site's palette (bg #191919, accent #75CABA -- same tokens as header.css/footer.css) and turns .content_wrap into a real two-column layout (sidebar beside the grid, not below it) -- see the note below on the approach. */ /* NOTE (2026-08-21): a flex version of this rule (flex:1 1 0% on .content, flex:0 0 280px on .sidebar) collapsed .content to 0px wide -- confirmed via live devtools. The product grid is isotope/masonry- style with absolutely-positioned cards, and flex's flex-basis:0% sizing measures an item's own intrinsic content size before growing it, which for a container whose children are all position:absolute (contributing ~0 to intrinsic size) came out wrong. CSS Grid's `1fr` track doesn't work that way -- a fixed 280px track plus a 1fr track divides the *container's* width deterministically and doesn't need to measure .content's own content at all, which is why this uses grid instead of flex for the same visual result. Re-verified via devtools after this change: .content came back to its real ~840px+ width and all 19 products render. */ /* 2026-08-26: scoped to `body:not(.sidebar_hide)` -- shop.css now also loads on single-product pages (added 2026-08-25 for the quote-button DOM-order fix, see below), which never render a `.sidebar` at all (the theme sets `sidebar_hide` on there). This grid used to apply unconditionally, permanently reserving an empty 280px sidebar column on those pages with nothing in it, and pinning `.content` to the narrower remaining column via `grid-column: 2` -- reading as the whole page shoved right instead of centered. Pages with a real sidebar (shop/taxonomy archives) are unaffected; single-product pages now fall through to the theme's own default block layout, which already has its own centering rule for exactly this case (`.sidebar_hide [class*="content_wrap"] > .content { margin: auto }`, parent theme's style.css) -- nothing extra needed here for that. */ body:not(.sidebar_hide) .content_wrap { display: grid; grid-template-columns: 280px 1fr; gap: 40px; align-items: start; /* 2026-08-22 direct request: "don't let anything touch the browser edge at any scale" -- this had zero horizontal padding at every width above the old ≤900px-only fix, so the sidebar and product grid both sat flush against the viewport edge on any wider desktop window. box-sizing:border-box so this padding doesn't also reopen the 100vw-plus-padding overflow class of bug fixed earlier today, even though this element isn't 100vw-based itself. */ padding: 0 40px; box-sizing: border-box; /* 2026-08-26 direct request: "allow the filter results to spread wider on big screens." Two other rules (the parent theme's own `.content_wrap, .content_container { width: var(--theme-var-page) }`, ~1290px, and a separate WPCode inline snippet hardcoding `width: 1200px` on the same selector) were capping this at 1200px regardless of viewport -- confirmed via computed style on a 2560px-wide screen: the whole sidebar+grid sat in a 1200px island with ~670px of empty space on each side, and the product grid itself was squeezed to under 600px. Neither of those two rules uses !important, and this selector is already more specific than both (body:not() + a class beats a plain class), so this alone is enough to win -- widened the cap rather than removing it outright, so it still reads as a contained page on truly huge (5K+) displays instead of stretching edge to edge forever. */ max-width: 1800px; width: 100%; margin: 0 auto; } body:not(.sidebar_hide) .content_wrap > .sidebar { grid-column: 1; grid-row: 1; width: auto; } body:not(.sidebar_hide) .content_wrap > .content { grid-column: 2; grid-row: 1; min-width: 0; /* 2026-08-26 direct follow-up: widening .content_wrap (above) wasn't enough on its own -- confirmed via computed style that this real theme rule was still the actual bottleneck: `body.body_style_wide:not(.expand_content) [class*="content_wrap"] > .content { width: var(--theme-var-content); }`. That variable is a fixed px value computed from the theme's *old* page-width model (~980px), and an explicit width on a grid item overrides the track's own 1fr sizing outright -- the grid still reserved the full wide 1fr track, but .content itself stayed pinned to that old fixed size inside it, sitting left-aligned with all the extra room going unused on the right (exactly what showed up in a real screenshot at 2560px: 3-column product grid, big empty gap next to it). Overriding back to 100% here lets it actually fill its grid track at any container width. */ width: 100% !important; } /** * 2026-08-26 direct follow-up: "go 4 wide on very big screens instead * of 3 with giant pictures." Now that .content actually fills its * available width (above), the theme's own fixed 3-per-row percentage * (`.woocommerce ul.products.columns-3 li.product { width: 33.3333% }`) * meant each of those 3 cards just grew huge on a wide monitor instead * of the grid gaining a column. Switched to 4-per-row -- reuses this * theme's own existing 22.05% figure (its normal 4/5-column math * elsewhere, confirmed via matched styles, not a made-up number) rather * than inventing a new percentage from scratch. No nth-child override * needed for the row-end margin: ul.products is a real flex container * (flex-wrap: wrap, confirmed via computed style), and 4 x 22.05% + 3 x * 3.8% margin ≈ 99.6%, comfortably under 100% -- the 4th item never * overflows into wrapping onto its own row. * * Cutoff moved from 1900px down to 1500px (direct follow-up, "still way * too big") -- .content_wrap's own 1800px cap (above) means 3 columns * were already stretching to fill a genuinely wide container well * before 1900px, not just on true ultra-wide/4K displays. */ @media (min-width: 1500px) { .woocommerce.columns-3 ul.products li.product, .woocommerce ul.products.columns-3 li.product { width: 22.05% !important; } } .sidebar.widget_area .sidebar_inner { /* 2026-08-26 direct request: "put the rental filters in a single card." Reversed from the 2026-08-21 transparent-wrapper look (history below, kept for context) -- this wrapper is now the one solid card (dark fill, border, rounded corners), and each widget inside it goes borderless/transparent with a thin divider between them instead of being its own separate box. Was: "The theme's own default gives this wrapper a solid dark fill (rgb(29,29,29), confirmed via computed style) -- a big rectangle enclosing all three widgets, on top of each widget's own already-transparent background. 2026-08-21 direct request: removed, so only each individual widget's own border remains, sitting directly on the page's gradient background." */ background: #1f1f1f; border: 1px solid rgba(255, 255, 255, 0.1); border-radius: 12px; display: flex; flex-direction: column; position: sticky; top: 24px; /* 2026-08-26: the parent theme's own default padding on this exact element (30px, all sides -- never actually reset, just painted over by the background/border changes above) was stacking on top of each widget's own padding, making the gap above the very first title (30px card padding + that widget's own top padding) much bigger than the gap below the very last one -- confirmed via computed style, not guessed. Zeroed here; each widget's own equal top/bottom padding (below) is what actually insets the card now, so the first title and the last section's content sit the exact same distance from the card's edges as every divider gap in between. */ padding: 0; } .sidebar.widget_area .widget { /* 2026-08-26: no longer its own card (see .sidebar_inner above) -- history of the previous back-and-forth on this rule, kept for context: briefly made transparent (2026-08-21), reverted same day ("the filter boxes should remain black"), and today merged into one shared card instead of either. A thin bottom border in place of the old individual box is what visually separates Search / Categories / Filter now; the last widget in the card has none (below). padding stays !important for the same reason noted here originally: the parent theme's own responsive rule at ~725px (__responsive.css: ".sidebar:not(.sidebar_float) .widget { padding: 0; width: 100%; }") is the same specificity as this rule and would otherwise win on load order alone. */ background: transparent; border: 0; border-bottom: 1px solid rgba(255, 255, 255, 0.1); border-radius: 0; /* 2026-08-26: equal top and bottom now (was 0 top / 20px bottom, direct complaint: "much more padding above the title than below the filter"). Also what makes the card's own top/bottom edges match now that .sidebar_inner's own padding is zeroed above. Direct follow-up request, still perceiving the top as bigger even after this measured out equal (16px both sides, confirmed via computed style at real mobile width too) -- "vertically center the filters in their sections" implemented literally now: each section's own title+content block centers within whatever height the section actually ends up at, rather than assuming top/bottom padding numbers alone guarantee centered *content*. */ display: flex; flex-direction: column; justify-content: center; padding: 16px 20px !important; } /* 2026-08-26: the REAL source of "Categories and Price have way more padding above their title than Search does" -- found via a full matched-styles dump on the actual Price widget element, not guessed. The parent theme carries three separate rules (different stylesheets/ breakpoints, none of them scoped this file was already fighting) all targeting `.sidebar .widget + .widget` -- an adjacent-sibling selector that only matches the 2nd/3rd/etc. widget in a list, never the first -- adding a real MARGIN-top (2.4rem / 38px / 30px depending on which one currently wins) between every widget and the one before it. A margin sits outside the widget's own border box, so comparing the title's position to its own widget's top edge (as every previous check in this file did) could never see it -- the right comparison is against the PREVIOUS widget's bottom edge, i.e. the divider line. That's why Search (no preceding sibling, the selector never matches it) looked fine while Categories and Price (both matched by it) carried an extra 30-38px on top of this file's own equal 16px padding. */ .sidebar.widget_area .widget + .widget { margin-top: 0 !important; } .sidebar.widget_area .widget:last-of-type { border-bottom: 0; } .sidebar.widget_area .widget_title { margin: 0 0 14px; font-size: 16px; text-transform: uppercase; letter-spacing: 0.04em; /* 2026-08-26 direct request: centered, cyan (was left-aligned white). */ text-align: center; color: #75CABA; } /* All controls in this sidebar (search, category dropdown, sort dropdown, price-filter button) share one border-radius so the panel doesn't mix pill/circle/square shapes -- confirmed a real complaint, not a style nitpick: the price-filter button in particular inherits the theme's global CTA-pill button style by default, which reads as a totally different shape than the boxier search/dropdown controls right next to it. Every rule below is pinned to this one value. */ .widget_product_search .search_form { display: flex; align-items: center; background: rgba(255, 255, 255, 0.06); border: 1px solid rgba(255, 255, 255, 0.2); border-radius: 10px; padding: 4px 4px 4px 14px; /* 2026-08-21 direct request: breathing room on the right, inside the card. First attempt used margin-right, which made things WORSE -- this element has a real `width: 100%` from elsewhere (confirmed via computed style, not the `auto` a plain block box would need for a margin to shrink it), so adding margin-right just pushed it 14px past the card's own right edge instead of creating a gap. max-width is a hard cap that wins regardless of what else is setting width, so it actually shrinks the box instead. */ max-width: calc(100% - 14px); } .widget_product_search .search_field { flex: 1 1 auto; min-width: 0; background: transparent; /* The theme's own global text-input reset (style.css) puts a real 1px border on every input[type="text"] -- confirmed via computed style, not guessed, same class of bug as the header search fix and the logo-cursor fix earlier this project. A plain `border: 0` loses to it, stacking a second border inside .search_form's own rounded box. !important is fighting that one specific foreign rule, not a general pattern to repeat. */ border: 0 !important; outline: 0; color: #ffffff; font-size: 14px; } .widget_product_search .search_field::placeholder { color: rgba(255, 255, 255, 0.55); } .widget_product_search .search_button { flex: 0 0 auto; border: 0; border-radius: 8px; padding: 8px 16px; background: #75CABA; color: #191919; font-size: 13px; font-weight: 600; cursor: pointer; transition: background 0.2s ease; } .widget_product_search .search_button:hover { background: #63AC9E; } /* 2026-08-26: the Categories widget's single-select dropdown (and all of the select2 restyling that used to live in this spot -- double- chevron fixes, the dark dropdown panel, its scrollbar, etc.) is gone. Direct request: "allow the categories to be checkboxes so users can see more than one category at a time." functions.php now replaces that whole widget's render with a checkbox list (`widget_display_ callback`, real 6 Rental subcategories) instead of the dropdown -- removed rather than left dead, since this was the widget's only appearance anywhere on the site. */ .cwm-cat-checkboxes { list-style: none; margin: 0; padding: 0; display: flex; flex-direction: column; gap: 10px; } .cwm-cat-checkboxes label { display: flex; align-items: center; gap: 10px; color: #ffffff; font-size: 14px; cursor: pointer; } .cwm-cat-checkboxes input[type="checkbox"] { /* Plain custom checkbox, same cyan accent as every other control in this card rather than the browser's default (usually blue). */ width: 18px; height: 18px; flex: 0 0 auto; appearance: none; -webkit-appearance: none; background: rgba(255, 255, 255, 0.06); border: 1px solid rgba(255, 255, 255, 0.3); border-radius: 4px; cursor: pointer; position: relative; } .cwm-cat-checkboxes input[type="checkbox"]:checked { /* 2026-08-26 direct request: no checkmark glyph -- it rendered off-center (this theme's own line-height/font-size resets on inputs nudge a checkmark drawn as a rotated border-box out of the middle of a 18px square), and the plain solid-fill box reads fine on its own without one. */ background: #75CABA; border-color: #75CABA; } .cwm-cat-count { color: rgba(255, 255, 255, 0.5); } /* "Clear Filters" -- functions.php prints it right after the sidebar's widgets finish (dynamic_sidebar_after), so it starts out as a block sitting below the whole Price widget. 2026-08-26 direct request: same shape as the Filter button (below) but inverted -- transparent fill, cyan border/text -- and moved onto the same line, to its left. Getting it there is a DOM move (shop.js), not just CSS, since it isn't actually adjacent to that button in the markup at all today; this rule assumes that move has already put it inside .cwm-price-filter-actions next to the button. box-sizing:border-box so its 1px border doesn't add on top of its own padding and make it taller than the (border-0) Filter button next to it. 2026-08-26, found via a real computed-style comparison, not guessed: this link was rendering in the site's plain body font (Roboto) with a 24px inherited line-height, while the Filter button next to it uses "Bebas Neue" -- the same all-caps display font used everywhere else on the site (nav, "View Options", every heading) -- at a 19px line- height. That mismatch, not just the border, is what was actually pushing them out of vertical alignment (Roboto's taller line-height sits the text 12-13px lower inside an otherwise-same-height box). Font-family and line-height are both pinned explicitly now to match Filter exactly, and the padding math from the border-compensation fix above (7px vs Filter's 8px) still holds on top of that. */ .cwm-clear-filters { display: inline-flex; align-items: center; justify-content: center; box-sizing: border-box; flex: 0 0 auto; width: auto !important; white-space: nowrap; margin: 0; padding: 7px 16px !important; background-color: transparent !important; border: 1px solid #75CABA !important; border-radius: 8px !important; color: #75CABA !important; font-family: "Bebas Neue", cursive !important; font-size: 13px !important; font-weight: 600 !important; line-height: 19px !important; text-transform: uppercase; text-decoration: none; transition: background-color 0.2s ease; } .cwm-clear-filters:hover { background-color: rgba(117, 202, 186, 0.15) !important; } /* The parent theme's own .price_slider_amount is itself only as wide as its content (confirmed via computed style: flex, but shrink-wrapped to ~178px inside a widget with ~218px of actual room), so a plain width:100% on the wrapper below inherits that same too-narrow box instead of the widget's real available width -- widened explicitly so Clear Filters and Filter actually fit on one line instead of wrapping. */ .woocommerce .widget_price_filter .price_slider_amount { width: 100% !important; } .cwm-price-filter-actions { display: flex; /* 2026-08-26: was align-items:stretch, forcing both to match the row's tallest -- reverted to center now that Clear Filters' own padding is corrected for its border (above), so they're already the same natural height without needing to stretch either one. */ align-items: center; /* 2026-08-26 direct request: center the pair in the card -- both buttons are flex:0 0 auto (sized to their own content, not stretched to fill the row), so without this they just sit at the row's left edge instead. */ justify-content: center; flex-wrap: nowrap; width: 100%; gap: 10px; /* 2026-08-26 direct request: a divider between the price range and the buttons, so the two read as separate sections within this one Price card. .price_slider_amount renders column-reverse (its own theme default), so in DOM order this wrapper actually comes right after the slider/price-range text -- a top border here is visually the line between them, same treatment as the divider already separating Search / Categories / Price from each other. */ margin-top: 14px; padding-top: 14px; border-top: 1px solid rgba(255, 255, 255, 0.1); } /* Native Price Filter widget -- its "Filter" button otherwise inherits the theme's global CTA-pill button (see shop.css's header note on this file's approach to that same fight on the header search icon). Pinned explicitly so it matches the search button above instead of showing up as a full pill next to boxy controls. The theme's own extra-styles.css carries ".woocommerce .widget_price_filter .price_slider_amount .button" with !important on background-color -- one more class than the selector below, so it was winning the purple theme-accent color through regardless of !important on either side (specificity beats !important-vs-!important ties). Matched here with the same ".woocommerce" prefix so this rule's own specificity is no longer lower, letting !important + this stylesheet's later load order actually decide it. */ .woocommerce .widget_price_filter .price_slider_amount .button { width: auto !important; /* 2026-08-26 direct request: "match the Clear Filters style but shorter" -- flex:1 1 auto (grow) was what made this button stretch to fill the whole rest of the row, much wider than Clear Filters right next to it; flex:0 0 auto sizes it to its own content instead, the same sizing behavior Clear Filters already uses. */ flex: 0 0 auto; box-sizing: border-box; /* The parent theme also carries its own `margin-top: 23px` / `margin-top: 20px` on this exact selector (two separate rules, confirmed via matched-styles) -- harmless back when this button just sat below the price slider on its own, but with Clear Filters now next to it in a flex row, that top margin was the real cause of them not lining up: align-items:center was centering the button's margin BOX, which this top margin made asymmetric. */ margin-top: 0 !important; border-radius: 8px !important; padding: 8px 16px !important; background-color: #75CABA !important; /* background-color alone wasn't enough -- the theme also sets a separate background-image (a purple gradient) on the generic button reset this element inherits from, which paints on top of background-color regardless of which one "wins" the cascade, since they're different properties. Confirmed via full matched- rules dump, not guessed. */ background-image: none !important; border-color: #75CABA !important; color: #191919 !important; font-size: 13px !important; font-weight: 600 !important; } .woocommerce .widget_price_filter .price_slider_amount .button:hover { background-color: #63AC9E !important; background-image: none !important; border-color: #63AC9E !important; } /* Product grid "Buy Now" / "Add to Cart" buttons -- 2026-08-21 direct request. Same exact bug and same fix as the price-filter button above: the theme's generic button reset sets a separate purple background-image (gradient) that paints over any plain background-color, so both have to be overridden together. */ .woocommerce ul.products li.product .button, .woocommerce ul.products li.product a.add_to_cart_button { background-color: #75CABA !important; background-image: none !important; border-color: #75CABA !important; color: #191919 !important; } .woocommerce ul.products li.product .button:hover, .woocommerce ul.products li.product a.add_to_cart_button:hover { background-color: #63AC9E !important; background-image: none !important; border-color: #63AC9E !important; } /* 2026-08-25: the child theme's own (pre-migration, Envato-scaffolded) style.css sets a hardcoded `width: 60%` on this exact button (.post_data_inner .button, style.css line ~320) -- narrow enough for the original short "Buy now" label, but "View Options" (the fix for variable-type products going quote-only, see functions.php) is visibly wider than that and was overflowing past the pill's own rounded background instead of being contained by it. Letting the button size to its own content instead of a fixed percentage is the correct general fix -- not just for today's text, but for any future label change too. */ .woocommerce ul.products li.product .post_data .post_data_inner .button { width: auto; white-space: nowrap; } /** * 2026-08-26: real root cause of "no slider handles, wrong colors" -- * found via a full matched-styles dump on the live handle/range/track * elements, not guessed. Three separate theme rules were stacked here: * (1) `.woocommerce .widget_price_filter .ui-slider .ui-slider-handle` * sets `opacity: 0` -- the handles exist, sit at the right position, * and are fully draggable, they're just invisible outright, regardless * of any background color. (2) The plain rule above this comment * (background:#75CABA on both range and handle, no !important) was * never winning against the theme's own later, more specific rules * either. (3) The colors were backwards from what's wanted: the outer * TRACK (`.price_slider_wrapper .ui-widget-content`, the part outside * the selected min/max) was rendering a leftover Envato-demo green * (var(--theme-color-alter_link)), while the RANGE (the selected * portion in the middle, which should read as the "active" cyan) was * rendering dark gray (var(--theme-color-bd_color)) -- exactly * inverted. Direct request: track black outside the selected range, * cyan inside it, real visible round handles to grab. */ .woocommerce .widget_price_filter .price_slider_wrapper .ui-widget-content { /* Pure black, not the card's own #1f1f1f dark-gray tone -- the two were too close in value to read as a real black/cyan contrast against each other; confirmed too subtle via screenshot, not guessed. */ background: #000000 !important; } .woocommerce .widget_price_filter .ui-slider .ui-slider-range { background-color: #75CABA !important; } .woocommerce .widget_price_filter .ui-slider .ui-slider-handle { opacity: 1 !important; background-color: #75CABA !important; border: 2px solid #191919 !important; box-shadow: 0 0 0 1px rgba(255, 255, 255, 0.4); width: 16px !important; height: 16px !important; top: -5px !important; margin-left: -8px !important; cursor: ew-resize; } .woocommerce .widget_price_filter .ui-slider .ui-slider-handle:hover, .woocommerce .widget_price_filter .ui-slider .ui-slider-handle.ui-state-active { background-color: #63AC9E !important; } /* Native WooCommerce sort-by bar above the product grid */ .list_products_header .woocommerce-ordering { margin: 0 0 24px; } /** * 2026-08-26 direct request: "use smaller circle numbers for the * pages." The theme's own default pagination numbers are plain 52x52px * squares (confirmed via computed style, not guessed) -- shrunk to * round pills matching this page's cyan-accent language instead. */ .woocommerce nav.woocommerce-pagination ul li a, .woocommerce nav.woocommerce-pagination ul li span { width: 34px !important; height: 34px !important; line-height: 34px !important; min-width: 0 !important; border-radius: 50% !important; font-size: 14px !important; background-color: #1f1f1f !important; border: 1px solid rgba(255, 255, 255, 0.2) !important; color: #ffffff !important; } .woocommerce nav.woocommerce-pagination ul li a:hover { background-color: #75CABA !important; border-color: #75CABA !important; color: #191919 !important; } .woocommerce nav.woocommerce-pagination ul li span.current { background-color: #75CABA !important; border-color: #75CABA !important; color: #191919 !important; } .woocommerce nav.woocommerce-pagination ul li span.dots { background-color: transparent !important; border: 0 !important; color: rgba(255, 255, 255, 0.5) !important; } .woocommerce-ordering .orderby { background: #1f1f1f; border: 1px solid rgba(255, 255, 255, 0.2); border-radius: 10px; padding: 10px 14px; color: #ffffff; font-size: 14px; } @media (max-width: 899px) { /* 2026-08-26: real regression, found from a live mobile screenshot -- these three selectors used to be specific enough (plain `.content_wrap` etc.) to beat the base desktop 2-column rule at any width, back when that base rule was also just plain `.content_wrap`. Once the single-product centering fix (elsewhere in this file) scoped the base rule to `body:not(.sidebar_hide) .content_wrap` -- a real specificity increase -- these plain selectors stopped being specific enough to win here, so shop/ category archives (which DO have a sidebar, i.e. body never carries .sidebar_hide) kept the desktop 280px-sidebar-column grid at every width, including phones. Confirmed via real mobile emulation: sidebar took up most of the screen with a barely-visible sliver of product grid squeezed down to single characters per line. Matching the same `body:not(.sidebar_hide)` prefix here restores equal specificity, so this later rule in the cascade correctly wins at narrow widths again. Tried lowering this to 399px alongside the header nav fix (same direct request: "the site goes to mobile too soon -- ipads and 400+ screens can stay in desktop") -- reverted back to 899px after testing: unlike the nav (which just needed more breathing room, fixed separately in header.css), the sidebar's fixed 280px width genuinely doesn't leave a usable product column below roughly 900px -- confirmed via screenshot at 500px, same letter-by-letter wrapping disaster came right back. The header nav itself still correctly stays in full desktop mode (no hamburger) all the way down to 400px per the separate fix below; only this sidebar+grid side-by-side layout keeps its wider cutoff, stacking into one clean full-width column (sidebar card on top, multi-column grid below -- not a cramped "mobile" look) between 400-899px instead. */ body:not(.sidebar_hide) .content_wrap { grid-template-columns: 1fr; } body:not(.sidebar_hide) .content_wrap > .sidebar { grid-column: 1; grid-row: 1; } body:not(.sidebar_hide) .content_wrap > .content { grid-column: 1; grid-row: 2; /* No padding here anymore -- .content_wrap itself now carries a permanent 0 40px at every width (see that rule's own comment), so this no longer needs its own separate copy. */ } .sidebar.widget_area .sidebar_inner { /* 2026-08-26: this used to fan the (previously separate) widget cards out into a wrapped row at tablet width. Now that they're one shared card (see the base rule above), that would split the single card back into several boxes side by side -- kept as one vertical stack at every width instead, just no longer sticky once the sidebar isn't beside a tall product grid. */ position: static; } } /* Rental archives: the two-tone gradient covers the *entire* page top to bottom (2026-08-21, direct request -- "only the footer doesn't use it"), not a fixed-height banner. Same dark purple-to-near-black tones already used on the service-detail pricing cards (service-detail.css), reused rather than inventing a third palette. .page_content_wrap already spans exactly from right after the header to right before the footer_wrap (a separate sibling with its own opaque background, untouched) -- painting the gradient directly on it needs no extra markup. Scoped to body.tax-product_cat (2026-08-22, broadened from body.term-rental) -- the 11 real subcategory archives (dj-audio-equipment, lighting, etc.) are WooCommerce's own native per-term pages, not something built for this migration, and every product category on this site is Rental inventory (the merch catalog was removed entirely earlier this project) -- so there's no "other" product_cat archive on this site that should look different. Was inconsistent black-vs-gradient across the parent term and its own subcategories; this makes every one of them match. */ body.tax-product_cat .page_content_wrap { background: linear-gradient(160deg, #2a1a3d 0%, #150c22 45%, #010101 100%); /* Same root-cause fix as the service-detail pages (see service-detail.css's own comment on this): the header here is a transparent absolute overlay (header-custom.php), so the parent theme's default 7.1rem top padding on this element would otherwise leave a gap of plain gradient with no header floating over it at all, and push the real content down for no reason. Zeroed here; the content itself gets its own clearance padding below instead, so it doesn't render hidden behind the nav. */ padding-top: 0; } body.tax-product_cat .content_wrap { padding-top: 120px; } @media (max-width: 767px) { body.tax-product_cat .content_wrap { padding-top: 90px; } /* Back down to the 20px side gutter already verified across 320-390px earlier today -- .content_wrap's own base rule is 40px each side, sized for tablet/desktop; on a real phone that eats too much of the already-narrow width. */ .content_wrap { padding-left: 20px; padding-right: 20px; } } /** * 2026-08-25: single-product page, variable products only -- the quote * plugin's own quantity/"Add To Quote" button block was rendering BEFORE * the actual variation selector (Rental Duration dropdown) instead of * after it, reading as "mashed together" / backwards. Root cause (found * via real DOM inspection, not guessed): the plugin hooks its own button * onto `woocommerce_single_product_summary` at the same priority (30) as * WooCommerce core's own variations-form renderer, and its callback * happens to have registered first -- there's no theme-safe way to * change a same-priority registration order for someone else's object * instance without touching the vendor plugin file (against this * project's own rule, see MIGRATION.md). Reordering visually via flexbox * `order` avoids needing to touch DOM/render order at all: default * `order: 0` keeps title/price/description first, the variations form * explicitly comes before the quote button block, and product meta * (SKU/category) stays last. */ .single-product .summary { display: flex; flex-direction: column; } .single-product .summary .variations_form { order: 5; } .single-product .summary .woocommerce-variation-add-to-cart { order: 10; } .single-product .summary .product_meta { order: 20; } /** * 2026-08-25: the quote plugin's own single-product button * (`.wc_quote_single_page`) renders with zero top spacing of its own, * so it sits flush against the price/description directly above it. * Theme-only margin, not a plugin-file edit -- needs `!important` * because the parent theme's own `.woocommerce div.product form.cart * .button { margin-top: 0; }` (woocommerce.css) is one class more * specific than a plain `.wc_quote_single_page` override and would * otherwise win regardless of load order (confirmed via matched-styles * inspection, not guessed). */ .single-product .summary .wc_quote_single_page { margin-top: 20px !important; } /** * 2026-08-25, direct request: "make the heart just a heart, not a * square background." The parent theme's own woocommerce.css * (`.woocommerce div.product form.cart .tinv-wraper > .tinvwl_add_to_wishlist_button`) * turns the wishlist plugin's plain heart-icon link into a solid white * 50x50 card with a drop shadow -- that rule also hardcodes the icon * itself to black (`color:#000000 !important`), which is presumably * *why* it needed an opaque light square underneath in the first place * (its own `:hover` state already switches to this site's cyan accent, * var(--theme-color-text_link) -- reused here as the base color too, * so removing the background doesn't leave a black heart invisible * against this site's dark pages). */ .woocommerce div.product form.cart .tinv-wraper > .tinvwl_add_to_wishlist_button { background-color: transparent !important; box-shadow: none !important; color: var(--theme-color-text_link) !important; width: 32px !important; height: 32px !important; line-height: 32px !important; }