`) supplies that ".woocommerce" ancestor, so the rule still applies here even though this ul is now a grid container. Generated pseudo-elements with a `content` value and a non-"none" `display` become real grid items in their own right — the ::before lands in row1/col1 (browsers always place it before DOM children in source order), silently occupying the first cell and pushing every actual one cell later. That's what produced the "3 + 4 + 1" stair-step instead of "4 + 4": row1's first slot went to an invisible pseudo-element, not to a missing product. Confirmed via inspect_design: li post-195 (DOM's first child) rendered at x=326 (column 2) instead of x=120 (column 1). Neutralizing the pseudo-elements removes them from grid flow entirely; the clearfix itself is redundant once the container is `display:grid` (grid doesn't need float clearing). !important needed to outrank WooCommerce's own un-flagged rule regardless of selector specificity — same pattern used throughout this block. */ ul.products::before, ul.products::after { content: none !important; display: none !important; } ul.products.columns-1 { grid-template-columns: 1fr; } ul.products.columns-2 { grid-template-columns: repeat(2, 1fr); } ul.products.columns-3 { grid-template-columns: repeat(3, 1fr); } ul.products.columns-5 { grid-template-columns: repeat(5, 1fr); } ul.products.columns-6 { grid-template-columns: repeat(6, 1fr); } ul.products li.product { float: none !important; width: auto !important; /* Row gap kept equal to the grid's own column-gap (24px, declared above) instead of an arbitrarily larger value — the two together read as one uniform gutter, and it also trims the trailing whitespace a section's last (often incomplete) row leaves before the next section heading. */ margin: 0 0 24px !important; display: flex; flex-direction: column; } ul.products li.product .add_to_cart_button, ul.products li.product a.button.product_type_simple, ul.products li.product a.button.product_type_variable, ul.products li.product a.added_to_cart.wc_forward { /* !important needed here: the card-look rules above (further up this file) already set a shorthand `margin: 10px 0 0 !important`, which — same selector, same specificity — would otherwise win this margin-top:auto override by appearing earlier in the cascade. Being later in source order + equally `!important` is what lets this one win instead, so the button still settles at a consistent bottom baseline across every card in an equal-height row regardless of how many lines the title/price above it took (see the file-level comment above ul.products for the full equal-height rationale). */ margin-top: auto !important; } @media (max-width: 768px) { ul.products { grid-template-columns: repeat(2, 1fr) !important; } } /* Classic loop engine only (ul.products): WooCommerce's own add-to-cart.js keeps the original "Adicionar ao carrinho" button in the DOM (just marking it ".added") and inserts the "Ver carrinho" link as a new sibling next to it, rather than replacing it — confirmed in wp-content/plugins/woocommerce/assets/js/frontend/add-to-cart.js (onAddToCartActions: "$thisbutton.addClass('added')" then "$thisbutton.after(...)"). Left alone that stacks two buttons in the same card. The product-collection block (Interactivity API-driven) doesn't have this — it already swaps to a single "Ver carrinho" link on its own — so this rule is scoped to the classic ul.products engine only. */ ul.products li.product .add_to_cart_button.added { display: none; } .star-rating { color: #caa77c; } /* ---------- Buttons ---------- */ a.button, button.button, .wc-block-components-product-button__button, .single_add_to_cart_button, input.button, .wp-element-button { background-color: #5c4535 !important; color: #ffffff !important; border-radius: 4px !important; border: none !important; font-weight: 700; } a.button:hover, button.button:hover, .single_add_to_cart_button:hover, .wc-block-components-product-button__button:hover { background-color: #ffffff !important; color: #0a0809 !important; } .is-style-outline .wp-block-button__link { background: transparent; border: 2px solid #ffffff; color: #ffffff; } /* ---------- Forms ---------- */ input, textarea, select, .select2-container .select2-selection { background: #171310 !important; border: 1px solid #412817 !important; color: #ffffff !important; border-radius: 4px !important; } /* Browser autofill (root cause of the store owner's "amber/orange border on Endereço and Apartamento" report on the checkout's address form — those two are exactly the fields a browser-saved address profile fills in together). Chromium (Chrome/Edge) renders autofilled fields with its own internal `:-webkit-autofill` background/text treatment at a specificity that even `background`/`color` with `!important` above cannot override — the only reliable fix is repainting the field with an inset box-shadow the size of the input (long-standing, documented Chromium workaround) plus forcing the text back to white via `-webkit-text-fill-color`. Left unstyled, Chromium's own autofill treatment shows through with its own (light/amber-tinted) colors, clashing with this dark theme — exactly what was reported. `border` is repeated here too so it never gets a chance to differ from every other field's normal state. `transition: background-color 9999s …` is the standard trick to stop Chromium's own yellow-flash transition from animating in before the override paints. Scoped to the same input/textarea/select selectors as the "Forms" rule above (not just `.woocommerce-checkout`) since the same autofill mismatch can happen on any form on the site (login, my account, contact) — not a checkout-only bug. */ input:-webkit-autofill, input:-webkit-autofill:hover, input:-webkit-autofill:focus, input:-webkit-autofill:active, textarea:-webkit-autofill, textarea:-webkit-autofill:hover, textarea:-webkit-autofill:focus, select:-webkit-autofill, select:-webkit-autofill:hover, select:-webkit-autofill:focus { -webkit-box-shadow: 0 0 0px 1000px #171310 inset !important; box-shadow: 0 0 0px 1000px #171310 inset !important; -webkit-text-fill-color: #ffffff !important; caret-color: #ffffff !important; border: 1px solid #412817 !important; -webkit-transition: background-color 9999s ease-in-out 0s; transition: background-color 9999s ease-in-out 0s; } /* Firefox's standard (non-prefixed) :autofill pseudo-class is better behaved than Chromium's but still worth pinning explicitly so the border/background never drifts from the rest of the form there either. */ input:autofill, textarea:autofill, select:autofill { background: #171310 !important; border: 1px solid #412817 !important; color: #ffffff !important; } /* Native radio inputs are themselves the visible control in WooCommerce Blocks' Cart/Checkout (shipping method, payment method): WooCommerce's own CSS draws them as a circle (border-radius:50%, position:absolute over the option label) with a small inner dot drawn on top when :checked, and gives checked vs. unchecked options two different background colors so they're easy to tell apart at a glance. The generic 4px radius above overrides that circle into a rounded square, and forcing the exact same dark background on every input regardless of state also erases the visual difference WooCommerce relies on to show which option is currently selected — together, on the shipping/payment method lists, this reads as a small dark blob sitting on/under the option text rather than a clean selection control. Restore the circular shape and a clear checked state using the theme's own palette instead of overriding shape/state away. */ input[type="radio"] { border-radius: 50% !important; background: #171310 !important; border-color: #412817 !important; } input[type="radio"]:checked { border-color: #caa77c !important; } input[type="radio"]:checked::before { background: #caa77c !important; } /* WooCommerce Blocks' own checkbox control (Cart/Checkout — e.g. "Usar o mesmo endereço para cobrança" on the shipping address step, and "Criar uma conta?"/terms checkboxes wherever this same component is used) is not a plain native `` rendered by the browser: the input itself is invisible (opacity/position tricks) and the square + checkmark the shopper actually sees are drawn by the theme/plugin around it — the square via the generic `input` rule above (dark background, brown border, both fine as-is), and the checkmark via a separate inline `

, unaffected by this rule, so it already renders at the intended 40px). Re-declare the sizes here with an element+class selector: specific enough to beat core's class-only rule, but still less specific than an explicit `.has--font-size` class (e.g. the homepage section titles, which deliberately opt into a smaller size) — so per-block size choices making in the editor still win, and only the unstyled default* is corrected. / h1.wp-block-heading { font-size: var(--wp--preset--font-size--xx-large); } h2.wp-block-heading { font-size: 40px; } h3.wp-block-heading { font-size: 26px; } / WooCommerce's own block-library CSS additionally scopes that same 14px default specifically to headings inside a `.wp-block-woocommerce-product-collection` block (the "Produtos relacionados" pattern is exactly that) with one extra ancestor class — `.wp-block-woocommerce-product-collection h2.wp-block-heading` — which outranks the element+class rule above. This selector only ever matches WooCommerce's own auto-generated collection heading (it never carries an explicit `.has--font-size` class to opt into a different size), so restoring the intended size here can't clash with a deliberate per-block choice the way overriding every `.wp-block-heading` with !important would. / .wp-block-woocommerce-product-collection h2.wp-block-heading { font-size: 40px !important; } /* ---------- Category/archive product grid (woocommerce/product-collection block) ---------- Category pages (e.g. /product-category/natal/) render through the native woocommerce/product-collection block — a different rendering engine from the [featured_products]/[recent_products]/[sale_products] shortcodes that power the homepage's card look (see content-product.php + the ".onsale" rules above). Left with WooCommerce Blocks' own defaults, this grid's sale badge was a white, top-right, bordered pill ("Oferta") and its title/price were centered — visibly a different card design from every other product grid on the site (home sections) and from the reference store's own category page (confirmed via take_screenshot: dark pill, bottom-left, left-aligned text there too). Reusing the same visual language here instead of duplicating the whole block-template markup keeps both engines looking like one consistent card component. / .wc-block-components-product-sale-badge { position: absolute !important; top: auto !important; bottom: 8px !important; left: 8px !important; right: auto !important; margin: 0 !important; background: rgba(10, 8, 9, 0.82) !important; color: #ffffff !important; border: none !important; font-weight: 600 !important; border-radius: 20px !important; text-transform: none !important; font-size: 11px !important; line-height: normal !important; padding: 4px 10px !important; letter-spacing: 0.2px; } .wc-block-product-templateresponsive .wp-block-post-title, .wc-block-product-templateresponsive .wp-block-woocommerce-product-price, .wc-block-product-templateresponsive .wc-block-components-product-rating { text-align: left !important; } .wc-block-product-templateresponsive .wp-block-post-title a { color: #ffffff; } / ---------- Category/archive grid: reserve image space (CLS) ---------- WooCommerce's own woocommerce/product-image block already inlines a matching `aspect-ratio` on each here today (its "Image sizing: Thumbnail" attribute resolves to the store's thumbnail-cropping setting — see ProductImage::resolve_aspect_ratio() in the plugin), confirmed via inspect_design: the rendered wrapper already reserves the correct square before any photo loads. This rule is a defensive fallback, not a fix for an active gap — it means the grid can't silently regress into CLS if a Product Collection instance's own "Image sizing" setting is ever changed away from "Thumbnail" (e.g. to "Full Size", which resolves to no aspect-ratio at all), without touching that block's own attributes. / .wc-block-components-product-image { aspect-ratio: 1 / 1; } .wc-block-components-product-image img { aspect-ratio: 1 / 1; object-fit: cover; } / ---------- Single product: redundant meta line ---------- / / WooCommerce's default single-product template prints a "Category: X" line (via the woocommerce/product-meta → core/post-terms hooked block) directly under the Add to cart form. The breadcrumb at the top of the page already shows the same category, and — since that "Category: " prefix is a literal string baked into WooCommerce's block markup rather than run through this site's pt_BR translations — it renders in English, which doesn't belong on an otherwise fully-Portuguese storefront. The reference store doesn't repeat the category here either. Hide the (redundant, English-only) line rather than deleting the block, so the taxonomy data/markup/functionality stays intact if ever needed again. / .wp-block-woocommerce-product-meta { display: none; } / ---------- Single product: image gallery layout shift (CLS) ---------- Confirmed via `curl` on the raw server-rendered HTML: no `.flex-viewport` element exists anywhere in the page until WooCommerce's own single-product.js builds one at runtime. Until that JS runs, WooCommerce's own base stylesheet (unrelated to this theme — see `.woocommerce div.product div.images .woocommerce-product-gallery__image: nth-child(n+2){width:25%;display:inline-block}` in wp-content/plugins/woocommerce/assets/css/woocommerce.css) lays out every secondary gallery photo as a 25%-wide thumbnail in a row below the main photo — space that's about to disappear the moment the slider mounts and shows exactly one image at a time. Confirmed via inspect_design: after JS, every `.woocommerce-product-galleryimage` (not just the first) is full width, stacked inside `.flex-viewport` with overflow:hidden — the 25%-wide row never actually appears in the finished page, it's purely a transient pre-JS layout. WooCommerce's own single-product.js (ProductGallery.prototype.initFlexslider) then also explicitly re-measures and resizes `.flex-viewport`'s height 100ms after the main photo's `load` event — a second, deliberate resize baked into WooCommerce core itself, not something this theme's CSS can prevent by adding a fixed aspect-ratio (this catalog's own photos aren't all one ratio — some are 1:1, most are 4:5 — so hardcoding one here would just crop/distort the others instead of fixing anything). The fix that is safe: hide every secondary image from the very first paint, since none of them are meant to be visible outside the slider anyway. That leaves the gallery's reserved height coming from the first image alone — sized by its own width/height attributes, i.e. its real, per-product aspect ratio, already correct before and after the slider/ JS-resize finish. No functionality is lost: flexslider re-reveals every image itself the instant it initializes, via jQuery's `.css()` — an inline style, which overrides this plain (non-!important) rule — and the photoswipe lightbox reads each image's data-* attributes directly from the DOM regardless of whether it's currently hidden. / .wp-block-woocommerce-product-image-gallery .woocommerce-product-galleryimage:nth-child(n+2) { display: none; } / ---------- Single product: gallery thumbnail strip spacing ---------- WooCommerce's own flexslider stylesheet lays the thumbnail
s out at a flat 25% width with no margin/gap and butts the whole strip directly against the bottom of the main image viewport above it, via `.woocommerce div.product div.images .flex-control-thumbs{margin:0; padding:0}` / `...flex-control-thumbs li{width:25%;float:left;margin:0}` in wp-content/plugins/woocommerce/assets/css/woocommerce.css. That selector's specificity (4 classes + 3 elements) beats a plain `.flex-control-thumbs`/`.flex-control-thumbs li` rule regardless of load order, so an earlier version of this fix silently lost the cascade on every contested property (margin, padding, width, float) while non-contested properties (display, gap, img border-radius) visibly applied — confirmed via curl on the raw served CSS plus a side-by-side with the live page: rounded thumbnail corners showed up, the gap above the strip didn't. `!important` here is deliberate and necessary, not defensive — matches how the rest of this stylesheet already overrides WooCommerce's own non-!important defaults (see the sale-badge rules above). The `li` width used to be `calc(25% - 7.5px)` — a flat 4-column grid. That reserved a slot for a 4th thumbnail even on products with only 3 images (e.g. /product/porta-terco-nossa-senhora/), leaving a visibly empty gap on the right inside the shaded panel — confirmed via inspect_design: 3 × 115px items + gaps only filled 365px of the panel's 512px content width. Switching each `
` to a fixed pixel width instead of a percentage-of-4 means the strip now sizes itself to however many thumbnails actually exist — 1, 3, 5, whatever — and simply wraps to a new row once it runs out of horizontal space, like any ordinary thumbnail grid, instead of reserving phantom columns. This still only applies below the 782px breakpoint (mobile/narrow tablet); see the min-width:782px block further down for the desktop layout. The single shared gray "panel" that used to sit behind the whole strip (background + border on `.flex-control-thumbs` itself) was removed at the store owner's request: with a real gap between items it read as one solid box with images floating inside it, rather than a row of distinct thumbnails — and the reference store doesn't have that outer panel either (confirmed via take_screenshot on a live reference product page: plain thumbnails, no shared backdrop). Each thumbnail now carries its own "card" framing instead — visible border + border-radius on the `` itself (below), matching the same 6px radius already used on every product-grid thumbnail elsewhere on the site (see `.padddo-product-thumb img` near the top of this file) — so they read as individual, well-defined cards with clear gaps between them instead of photos loose inside (or glued together inside) a single container. / .flex-control-thumbs { display: flex !important; flex-wrap: wrap !important; gap: 10px !important; margin: 16px 0 0 !important; box-sizing: border-box !important; padding: 0 !important; background: transparent !important; border: none !important; } .flex-control-thumbs li { width: 72px !important; flex: 0 0 72px !important; float: none !important; } .flex-control-thumbs img { display: block; border-radius: 6px; border: 1px solid rgba(255, 255, 255, 0.16); } / ---------- Single product: thumbnails as a left-hand column (desktop) ---------- The reference store (padddo.lojavirtualnuvem.com.br, confirmed via take_screenshot on a real product page) doesn't stack thumbnails under the main photo on desktop — it runs them as a vertical strip to the LEFT of the main image, Amazon-style. Reproducing that here (rather than keeping the horizontal strip from the mobile rules above) also happens to be the more robust fix for the "phantom 4th column" bug this block was written for: a vertical column's width is fixed and independent of how many thumbnails exist, so there's never a row of unfilled slots to notice, regardless of image count (1, 3, 5, ...). `.woocommerce-product-gallery` in the DOM is [.flex-viewport, ol.flex- control-thumbs] in that order — `flex-direction: row-reverse` puts the thumbs (the second/last child) visually first (left) without needing a manual `order` on either element. `align-items` is left at its default (stretch) on purpose: `.flex-viewport` gets an explicit inline height from WooCommerce's own single-product.js (ProductGallery.prototype. initFlexslider, re-measured after the main photo's `load` event — see the CLS comment above), and default stretch makes the thumbnail column match that same height automatically, with no JS or duplicated height value needed on this side. If the thumbnail count doesn't fit that height (e.g. a product with many photos), the column scrolls internally via overflow-y instead of growing taller than the photo it sits beside. Only enabled at the same 782px breakpoint the rest of this stylesheet already uses for "desktop" (see the mega-menu and cookie-notice rules above) — below that, the mobile rules above keep the strip under the photo, since a narrow side column doesn't fit a phone screen. / @media (min-width: 782px) { / WooCommerce's own product-image-gallery.css ships `.woocommerce .wp-block-woocommerce-product-image-gallery{max-width: 512px}` — a hardcoded cap baked into the plugin, independent of whatever width the theme's column around it actually is. It was invisible before because the single-product template's gallery column also happened to be exactly 512px wide, so the cap and the column agreed by coincidence; widening that column (to make the main photo bigger/taller) didn't grow the photo at all, because this cap silently won the argument first. Confirmed via inspect_design: the column measured 640px but `.wp-block-woocommerce-product-image- gallery` itself still measured exactly 512px. `!important` needed to beat the plugin's rule regardless of stylesheet load order. / .wp-block-woocommerce-product-image-gallery { max-width: 100% !important; } .woocommerce-product-gallery { display: flex; flex-direction: row-reverse; gap: 12px; } .woocommerce-product-gallery .flex-viewport { flex: 1 1 auto; min-width: 0; } / Widening the gallery column (above) grows the main photo's box proportionally, but this catalog's source photos are mostly wide landscape crops (~600x383, ratio ~1.57:1) — scaling a shape that wide up uniformly barely reads as "taller" next to the narrow, tall 84px thumbnail column beside it, even though the rendered height did increase in absolute pixels. Two forced-aspect-ratio attempts were tried and rejected here before this one — worth recording so nobody re-tries them: 1. `aspect-ratio:4/5` + `object-fit:cover` cropped real content on wide/low products (the "Porta Terço" tray): cut off the statue's head and part of the tray. 2. `aspect-ratio:4/5` + `object-fit:contain` avoided cropping but left the tray photo only ~347px tall inside a 680px box — ~330px of empty letterbox, roughly half the frame — confirmed too much empty space via a follow-up screenshot regardless of whether that space was centered or pushed to one edge with object-position. The actual fix: don't force the photo itself into an unrelated ratio at all. Give the frame (`.flex-viewport`) a modest min-height instead, well below the ~680px the 4:5 attempts produced, and let the `` keep its own natural width:100%/height:auto sizing. A photo already taller than that floor (near-square or portrait shots) is completely unaffected — the frame just grows to fit it, same as before this whole chain of fixes. Only photos shorter than the floor (this catalog's wide/low products) get topped up, and only by the gap between their natural height and the floor — nowhere near a full 680px box. `.flex-viewport` is `position:relative` in normal block flow, so the shorter image inside it naturally sits at the top with the leftover space below, with no object-position trick needed. / .woocommerce-product-gallery .flex-viewport { min-height: 420px !important; } / Store-owner request: make this specific product's photo actually read as square, not just sit in a taller box. A plain min-height (like the 420px floor above) doesn't achieve that — the keeps its own natural width:100%/height:auto box (347px tall here), so a taller frame only adds invisible empty space below it; confirmed via inspect_design + take_screenshot that a 540px-tall frame rendered pixel-identical to the 420px one, because the extra 120px was blank space blending into the black background, not a bigger photo. Making the photo itself square requires object-fit:cover on a 1:1 box, which does crop — here it crops the left/right edges only (the tray's rim on one side, some background past the rosary's cross pendant on the other), not the statue on top: this photo (600x383, ratio ~1.57:1) is wider than a 1:1 box, so object-fit:cover's fill-by-the-limiting-dimension math scales by height to cover the box with zero vertical cropping, and only trims width. Confirmed acceptable via take_screenshot — full statue and rosary intact. Scoped to this product's body class (`postid-193`) rather than applied catalog-wide, since forcing every photo — including much wider ones — into a hard square would crop some of them far more aggressively than this one. / body.postid-193 .woocommerce-product-gallery__image img { width: 100%; aspect-ratio: 1 / 1; object-fit: cover; } .flex-control-thumbs { flex: 0 0 84px !important; width: 84px !important; max-width: 84px !important; flex-direction: column !important; flex-wrap: nowrap !important; align-content: flex-start; overflow-y: auto; margin: 0 !important; } .flex-control-thumbs li { width: 100% !important; flex: 0 0 auto !important; } } / ---------- Single product: description/attributes/reviews tabs (CLS) ---------- Confirmed via `curl` on the raw server-rendered HTML: none of the three tab panels ("Descrição", "Informação adicional", "Avaliações") carry a `style="display:none"` attribute in the initial response — all three render fully visible, stacked one after another (full description text + the complete attributes table + the complete reviews section), and it's WooCommerce's own wc-single-product.js (the `.wc-tabs-wrapper` init, unrelated to this theme) that adds `display:none` to every panel except the active one — after it runs. Confirmed via inspect_design: the two inactive panels currently carry an inline `style="display: none"` that only JS could have added. On this product that's a ~550px-tall block collapsing down to ~230px once JS catches up — a real, large, reproducible shift on every single-product page load, unrelated to price/ cart data. WooCommerce always marks the first tab ("Descrição") active by default in its own server-rendered markup (`
`) — the same default JS itself would apply — so hiding every other panel here via CSS doesn't guess at anything, it just makes the very first paint match what WooCommerce's own JS was always going to set a moment later. No functionality lost: clicking another tab is a direct result of that click (CLS explicitly excludes shifts within 500ms of user input), and WooCommerce's JS sets `display` via inline style either way, which overrides this plain (non-!important) rule when the user switches tabs. / .woocommerce-tabs.wc-tabs-wrapper .panel:not(.woocommerce-Tabs-panel--description) { display: none; } / ---------- Melhor Envio: calculadora de frete na página do produto ---------- / / O plugin "Melhor Envio" (wp-content/plugins/melhor-envio-cotacao) já injeta nativamente um formulário de CEP + resultado de frete antes do botão "Adicionar ao carrinho" (ver Controllers/ShowCalculatorProductPage.php), com CSS próprio claro (fundo #f2f2f2) que destoa do tema escuro da Padddo. Estas regras só re-skinam esse bloco existente com as cores/tipografia já usadas no resto do site — não alteram HTML, JS nem a lógica de cálculo do plugin. !important é necessário porque o CSS do plugin é carregado depois deste arquivo em algumas páginas de produto (enqueue tardio, no hook que imprime o próprio formulário). Observação: este plugin não renderiza nenhum botão "Calcular" — a cotação é disparada automaticamente (shipping-product-page.js) assim que o campo de CEP atinge 9 caracteres (00000-000). A regra de `input[type=submit]` do CSS do próprio plugin (calculator.css) é código morto: esse elemento não existe no DOM desta tela, então não há botão para restilizar aqui. 2026-08: a pedido do dono da loja, o "card" (fundo #171310 + borda marrom) que envolvia todo o bloco foi removido — fica só o texto/campos soltos sobre o fundo da página, no mesmo estilo "sem container" do resto da coluna de compra (SKU, price-perks, stepper de quantidade etc., ver bloco "Single product: reorganized purchase area" logo abaixo, nenhum dos quais usa um wrapper com fundo/borda próprios). / #woocommerce-correios-calculo-de-frete-na-pagina-do-produto.containerCalculator, .containerCalculator { background-color: transparent !important; border: none !important; border-radius: 0 !important; color: var(--wp--preset--color--foreground) !important; box-sizing: border-box !important; padding: 0 !important; / Alinha o ritmo vertical ao block-gap (24px) usado no resto da coluna de compra, em vez do 10px/20px assimétrico original. / margin: 4px 0 24px !important; } / Label "Simulação de frete". O seletor original (`.calculatorRow > p`) nunca batia: no HTML gerado pelo plugin o
não é filho direto de `.calculatorRow`, fica dentro de `.row > .col-75` — a regra de tipografia nunca chegou a ser aplicada. Trocado para seletor descendente e alinhado ao mesmo peso/tamanho do label "Tamanho" já usado na tabela de variações (700 / 16px / cor --foreground), para os dois labels da coluna de compra ficarem no mesmo nível hierárquico. / .containerCalculator .row p, .containerCalculator .calculatorRow p { margin: 0 0 10px !important; font-family: inherit !important; font-size: var(--wp--preset--font-size--base) !important; font-weight: 700 !important; color: var(--wp--preset--color--foreground) !important; } .containerCalculator input[type="text"].iptCep, .containerCalculator input[type="text"] { background-color: #0a0809 !important; border: 1px solid var(--wp--preset--color--button) !important; color: var(--wp--preset--color--accent) !important; border-radius: 4px !important; / Sem isso o input herda a fonte padrão do navegador (Arial ~13px) em vez da Plus Jakarta Sans/16px usada em todo o resto do site. / font-family: inherit !important; font-size: var(--wp--preset--font-size--base) !important; transition: border-color 0.2s ease; / Compacto o suficiente para "00000-000" (9 caracteres mascarados) sem sobrar espaço vazio dentro do campo — antes ocupava a largura inteira da coluna de compra ao lado do botão "Calcular". Largura fixa (em vez de flex:1 puro) para não esticar de novo em telas largas; ver .padddo-cep-actions .iptCep abaixo, que também limita o flex-grow. / width: 160px !important; max-width: 100%; } .containerCalculator input[type="text"]:focus { border-color: var(--wp--preset--color--accent) !important; outline: 2px solid var(--wp--preset--color--accent); outline-offset: 1px; } .containerCalculator input[type="text"]::placeholder { color: var(--wp--preset--color--foreground); opacity: 0.7; } / Spinner exibido enquanto a cotação real é buscada na API do Melhor Envio / .containerCalculator #calcular-frete-loader { padding: 8px 0 4px; } .containerCalculator #calcular-frete-loader img { width: 26px; height: 26px; } / "Frete para {cidade}", preenchido acima da tabela quando a cotação volta / .containerCalculator #destiny-shipping-mehor-envio { display: block; font-size: var(--wp--preset--font-size--medium) !important; font-weight: 600; color: var(--wp--preset--color--accent) !important; margin-top: 14px; margin-bottom: 4px; } .containerCalculator .resultado-frete table { width: 100%; border-collapse: collapse; margin-top: 4px; } .containerCalculator .resultado-frete table td { padding: 10px 0; border-bottom: 1px solid rgba(191, 186, 186, 0.15); color: var(--wp--preset--color--foreground); font-size: var(--wp--preset--font-size--medium); line-height: 1.5; } .containerCalculator .resultado-frete table tr:last-child td { border-bottom: none; } / Observação especial de frete (ex.: condição para frete grátis) usa a cor de aviso do tema. Escopado só para essa small — a linha "Frete para {cidade}" acima tem regra própria e não deve ficar com a mesma cor de alerta, porque não é um aviso, é só informação de contexto. / .containerCalculator small.observation-shipping-free { display: block; color: var(--wp--preset--color--warning) !important; font-size: var(--wp--preset--font-size--small); margin-top: 6px; } / ---------- Single product: reorganized purchase area (2026-08) ---------- See templates/single-product.html and the "Single product page reorganization" section of functions.php for the full rationale. Kept in the site's own dark palette (theme.json tokens) — the store owner's reference layout is only followed for structure/hierarchy, not its (light-theme) colors. / / SKU, right under the title — the native woocommerce/product-sku block already prints "SKU: " translated + the value; only needs restyling to a small, discreet, secondary-text treatment instead of its block default. / .padddo-product-sku { color: var(--wp--preset--color--foreground); opacity: 0.75; font-size: var(--wp--preset--font-size--small); margin: 4px 0 0; } .padddo-product-sku .sku { font-weight: 400; } / Pix discount + interest-free installments + "Ver mais detalhes", injected right after the price by padddo_render_price_perks_block(). The warning token (already used elsewhere for the shipping calculator's "frete grátis" callout) doubles as this theme's "gold/orange highlight" color — the closest existing token to the reference's own accent color. / .padddo-price-perks { margin: 6px 0 16px; } .padddo-price-perks p { margin: 0 0 4px; } .padddo-pix-label, .padddo-installments { color: var(--wp--preset--color--warning); font-size: var(--wp--preset--font-size--medium); font-weight: 700; } .padddo-pix-label strong { font-weight: 700; } .padddo-pix-note { color: var(--wp--preset--color--foreground); font-size: var(--wp--preset--font-size--small); } .padddo-see-more-details { margin-top: 8px !important; } .padddo-see-more-details-link { color: var(--wp--preset--color--foreground); font-size: var(--wp--preset--font-size--small); text-decoration: underline; } .padddo-see-more-details-link:hover { color: var(--wp--preset--color--accent); } / Quantity stepper (+/- buttons flanking the number) + "Comprar" button row. WooCommerce Blocks' own "stepper" quantity style ships unstyled on this theme's dark palette by default — restyled to match the button/input language used everywhere else on the site. Scoped to `body.single-product .wc-block-add-to-cart-form` (on top of the block's own classes) for two reasons: 1) `woocommerce/add-to-cart-form` with `quantitySelectorStyle: "stepper"` is only used in templates/single-product.html, so this scoping doesn't change what renders anywhere — it's defensive, not a behavior change. 2) `.wc-block-components-quantity-selectorbutton` / `input` are the exact same class names WooCommerce Blocks uses for the Cart block's and the header's mini-cart drawer's own line-item quantity stepper (see wp-content/plugins/woocommerce/assets/client/blocks/cart.css and mini-cart-contents.css) — the mini-cart can be opened from the header on a product page too, so scoping by body class alone isn't enough; every selector below also requires the `.wc-block-add-to-cart-form` ancestor so the mini-cart's own stepper is left untouched. The `!important`s aren't stylistic: WooCommerce Blocks ships its own default styles for this block as an inline