/*
 * WordPress/WooCommerce compatibility fixes ONLY — never a place to redesign anything.
 * Every rule here should say, in a comment, why it exists (PROJECT-BRIEF.md build
 * method rule 1). Empty for now; add fixes as real mismatches are found by
 * scrape/computed.mjs-style comparison, not guessed.
 */

/* Source hides the coupon UI site-wide via its own injected custom CSS
   (present verbatim in the homepage's harvested <head>, not page-specific —
   "Hide coupon form on cart (custom layout)" / "Hide 'Have a coupon?' toggle
   on checkout"). Confirmed against scrape/out/shots/desktop/cart-page.png:
   no coupon field appears there at all. Reproduced directly here since this
   theme has no equivalent "custom CSS injection" mechanism of its own. */
.coupon.pt-left {
	display: none !important;
}
.woocommerce-form-coupon-toggle {
	display: none !important;
}
.woocommerce-checkout .checkout_coupon {
	display: none !important;
}
/* Our cart's coupon form doesn't carry the source's exact .pt-left class
   (that class comes from a layout variant we didn't reproduce elsewhere),
   so match on WooCommerce's own standard class too — same source intent,
   just targeting the selector our actual markup has. */
.woocommerce-cart .cart .coupon {
	display: none !important;
}

/* Cart/checkout box headings ("Cart totals", "Your order") and primary
   action buttons (Proceed to Checkout, Update Cart, Place Order) render in
   ALL CAPS on the source (scrape/out/shots/desktop/cart-page.png,
   checkout-page.png) — Porto's own harvested CSS DOES have a generic
   `h2{text-transform:uppercase}` rule, but something with higher specificity
   is resetting it back to none for these specific elements (not worth
   chasing the exact cascade conflict for a casing-only difference); applied
   directly here instead. */
.cart-collaterals h2,
.woocommerce-checkout #order_review_heading,
.woocommerce-checkout .woocommerce-checkout-review-order-table + h3 {
	text-transform: uppercase;
}
.wc-proceed-to-checkout a.checkout-button,
button[name="update_cart"],
#place_order {
	text-transform: uppercase;
}

/* Checkout's macro two-column split (Billing details left, boxed "Your
   order" summary right — scrape/out/shots/desktop/checkout-page.png) isn't
   in any of the harvested stylesheet FILES at all (confirmed by grep across
   every porto-*.css) — it's generated by Porto's Elementor checkout-builder
   widget as per-page inline CSS scoped to that page's own Elementor element
   IDs, which only the homepage's inline Elementor CSS was captured for
   (assets.php only conditionally loads home-inline-elementor.css). #order_review
   and #customer_details are plain siblings of form.checkout with nothing
   placing them side by side, so they just stack. Same "bespoke layout needs
   its own CSS" reasoning as the homepage's FAQ/Contact row fix above. */
.woocommerce-checkout form.checkout {
	display: grid;
	grid-template-columns: 1fr 400px;
	gap: 10px 40px;
	align-items: start;
}
/* #customer_details, #order_review_heading ("Your order"), and #order_review
   are three separate siblings in that DOM order — spanning customer_details
   down both rows lets the heading + box fall into column 2 naturally via
   grid auto-placement, stacked, instead of each competing for its own
   flex slot (which left the heading floating alone with an empty gap
   beside it when this was a flex row). */
.woocommerce-checkout form.checkout #customer_details {
	grid-column: 1;
	grid-row: 1 / span 2;
}
.woocommerce-checkout form.checkout #order_review_heading {
	grid-column: 2;
	grid-row: 1;
	margin: 0;
}
.woocommerce-checkout form.checkout #order_review {
	grid-column: 2;
	grid-row: 2;
	background: #fff;
	border: 1px solid #eee;
	padding: 25px;
}
@media (max-width: 767px) {
	.woocommerce-checkout form.checkout {
		grid-template-columns: 1fr;
	}
	.woocommerce-checkout form.checkout #customer_details {
		grid-column: 1;
		grid-row: 1;
	}
	.woocommerce-checkout form.checkout #order_review_heading {
		grid-column: 1;
		grid-row: 2;
	}
	.woocommerce-checkout form.checkout #order_review {
		grid-column: 1;
		grid-row: 3;
	}
}

/* Single product — source wraps the summary in a patterned navy section with
   a white card (scrape/out/shots/desktop/product-top.png). We don't have the
   product-page Elementor template's own generated CSS (only harvested the
   homepage's), so this approximates the look with a flat color rather than
   chasing the exact background pattern asset. */
.ul-product-page-bg {
	background-color: #0f3a5f;
	padding: 40px 0;
}
.ul-product-summary-card {
	background: #fff;
	border-radius: 6px;
	padding: 30px;
	max-width: 1100px;
	margin: 0 auto;
}

/* Gutenberg's block-library CSS (.wp-block-table's overflow-x:auto + width:100%
   on the inner table) was never harvested — we only load Porto/Elementor CSS,
   not WP core's block styles. Without it, the spec tables embedded in product
   descriptions (CAS Number/Other Names/IUPAC Name/etc, confirmed against the
   source's own wp-block-table markup) have no width constraint or word-wrap,
   so long cell content (the IUPAC name, comma-separated alt names) pushes the
   table past .ul-product-summary-card's edge into the navy background instead
   of wrapping or scrolling within its own box like the source. */
.wp-block-table {
	overflow-x: auto;
	max-width: 100%;
}
.wp-block-table table {
	width: 100%;
	table-layout: fixed;
}
.wp-block-table td,
.wp-block-table th {
	word-wrap: break-word;
	overflow-wrap: break-word;
}

/* Single product gallery + summary two-column split. WooCommerce's OWN base
   stylesheet normally provides this (.images/.summary float+width) — Porto's
   CSS only adds typography/spacing on top of it, it doesn't reimplement the
   split itself. We dequeue Woo's base CSS (build method rule 1), so without
   this the summary column collapses to nothing. Found via product-top.png
   comparison: gallery rendered, summary was present in the DOM but invisible. */
.single-product div.product {
	display: flex;
	flex-wrap: wrap;
	gap: 40px;
}
.single-product div.product div.images {
	flex: 0 0 45%;
	max-width: 45%;
}
.single-product div.product div.summary {
	flex: 1 1 0;
	min-width: 280px;
}
/* .woocommerce-tabs (Description/Reviews) is a THIRD flex child of
   div.product, sitting below .images/.summary thanks to flex-wrap, but with
   no flex-basis of its own it falls back to the flex-item default of
   min-width:auto — sized to its content's intrinsic width rather than the
   row. A wide table in the description (CAS Number/Other Names/IUPAC Name
   spec table, confirmed against the source's own wp-block-table) then
   forces this item, and the whole flex row with it, wider than
   .ul-product-summary-card, pushing content into the navy background
   instead of wrapping inside the card like the source. */
.single-product div.product div.woocommerce-tabs {
	flex: 1 1 100%;
	min-width: 0;
}
/* Same root cause as .woocommerce-tabs above, just never caught at the time
   because that investigation was scoped to the spec-table overflow:
   `.related.products` (WooCommerce's own related-products section, output
   by related.php) is a FOURTH flex child of div.product, after images/
   summary/woocommerce-tabs. With no flex-basis of its own it falls back to
   the default flex-item sizing (shrink-to-fit on its intrinsic/max-content
   width), which the floated product grid inside it doesn't naturally
   constrain — confirmed via direct measurement: the section rendered at
   1220px wide inside a 768px viewport, well past its own
   .ul-product-summary-card, with the white card bleeding into the navy
   background behind it (reported as a visual bug: content "spilling past
   its own box"). Giving it the same flex:1 1 100%/min-width:0 treatment
   pins it to the row's actual width at every breakpoint. */
.single-product div.product section.related.products {
	flex: 1 1 100%;
	min-width: 0;
}
@media (max-width: 767px) {
	.single-product div.product div.images,
	.single-product div.product div.summary {
		flex-basis: 100%;
		max-width: 100%;
	}
}

/* Checkout's billing / order-review two-column split — same root cause as
   the two fixes above: WooCommerce's base CSS normally gives col2-set >
   .col-1/.col-2 a 48% width + float, and without it the columns collapse
   toward zero width. This was the REAL cause of every checkout field
   looking tiny — found by walking the DOM chain and seeing .col-1 computed
   at 98px wide on a 1440px page, not a field-level CSS problem. */
.col2-set {
	width: 100%;
	display: flex;
	flex-wrap: wrap;
	gap: 30px;
}
.col2-set .col-1,
.col2-set .col-2 {
	flex: 1 1 400px;
	width: auto;
}

/* The field-level rule Woo's base CSS also provides — belt-and-suspenders
   now that .col-1/.col-2 actually have real width to fill. */
.form-row .woocommerce-input-wrapper {
	display: block;
}
.form-row input.input-text,
.form-row select,
.form-row textarea {
	width: 100%;
	box-sizing: border-box;
	padding: 0.6em 0.8em;
}

/* Cart/wishlist table thumbnail — WooCommerce's own base CSS normally caps
   this image at a small fixed size (we dequeue that CSS, build method rule
   1); Porto's CSS only has a hint toward the intended size
   (`product-thumbnail>div{width:80px}`) but nothing constraining the <img>
   itself, so it rendered at its full natural size (300px) and blew out the
   whole table's column widths under table-layout:auto. */
.shop_table td.product-thumbnail img {
	width: 80px;
	height: auto;
}

/* My Account nav/content split — same root cause as the checkout col2-set
   fix: WooCommerce's base CSS normally floats these into a sidebar + content
   layout, and without it they stack full-width as a plain list. */
.woocommerce-account .woocommerce-MyAccount-navigation {
	float: left;
	width: 25%;
}
.woocommerce-account .woocommerce-MyAccount-navigation ul {
	list-style: none;
	padding: 0;
	margin: 0;
}
.woocommerce-account .woocommerce-MyAccount-content {
	float: right;
	width: 70%;
}
@media (max-width: 767px) {
	.woocommerce-account .woocommerce-MyAccount-navigation,
	.woocommerce-account .woocommerce-MyAccount-content {
		float: none;
		width: 100%;
	}
}

/* Generic fallback for ANY WooCommerce [products] shortcode grid that isn't
   going through our own post_class fix (e.g. the New Releases / All
   Products pages, which use the native shortcode) — restores Woo's classic
   columns-N grid behavior directly off its OWN standard markup, so every
   product grid works regardless of which code path rendered it. */
.products.columns-2 li.product,
.products.columns-3 li.product,
.products.columns-4 li.product,
.products.columns-5 li.product,
.products.columns-6 li.product {
	float: left;
	box-sizing: border-box;
	padding: 0 15px;
	margin-bottom: 30px;
}
/* Clearfix: forcing `ul.products` back to `display:block` below (to fix the
   overflow bug) means these li's `float:left` is no longer overridden by a
   flex container (which ignores float and auto-sizes to contain its flex
   items) — the very first time this float rule has actually taken effect.
   A block with only floated children collapses to 0 height without this,
   confirmed by measurement after the display fix (ul.products rendered at
   height:0, hiding the whole grid's layout from anything that reads its
   box, e.g. scrollIntoView). */
.products.columns-2::after,
.products.columns-3::after,
.products.columns-4::after,
.products.columns-5::after,
.products.columns-6::after {
	content: "";
	display: table;
	clear: both;
}
.products.columns-2 li.product { width: 50%; }
.products.columns-3 li.product { width: 33.333%; }
.products.columns-4 li.product { width: 25%; }
.products.columns-5 li.product { width: 20%; }
.products.columns-6 li.product { width: 16.666%; }
/* Woo's plain columns-N class (unlike Porto's own pcols-xs-N system used
   elsewhere on this site, which responsively drops to fewer columns under
   767px — see porto-theme-shop.css) is a static count with no responsive
   variant — at a 390px phone width, 4+ fixed columns leaves ~70px per card,
   not enough room for price/review-count text, which wraps and overlaps
   between columns (part of the same "columns not evenly separated" report
   this fix addresses). Match Porto's own xs breakpoint/column-count
   convention here instead of leaving it fixed at the desktop count. */
@media (max-width: 767px) {
	.products.columns-3 li.product,
	.products.columns-4 li.product,
	.products.columns-5 li.product,
	.products.columns-6 li.product {
		width: 50%;
	}
}

/* porto-theme-shop.css gives EVERY `ul.products` (unconditionally — not
   scoped to Porto's own `li.product-col` flex-grid markup) a negative
   left/right margin: `margin-left/right: calc(var(--porto-el-spacing) / -2)`,
   meant to let Porto's OWN grid system's columns (which get their gutter
   from `li.product-col`'s matching `padding: 0 calc(.../2)`) sit flush
   against the containing row's edges. Our fallback grid above already
   creates its own gutters independently via the `li.product` padding (with
   box-sizing: border-box, so the 25%/33%/etc. width already accounts for
   it) — it was never designed to pair with that negative margin. Woo's
   native `related.php` template (no `product-col` class, just plain
   `ul.products.columns-4`) was the case that exposed this: the card
   wrapping the single-product page (`.ul-product-summary-card`, 30px
   padding) is unrelated to Porto's own spacing system, so the leftover
   negative margin pushed the grid up to ~180px past the card's right edge,
   bleeding into the navy background behind it instead of staying inside
   the white box. Cancel it for every grid this fallback styles.
   porto-theme-shop.css also has `ul.products:not(.owl-carousel) {
   display:flex; flex-wrap:wrap}` — again unconditional, and specifically
   targets exactly this non-carousel case (Woo's native related.php output
   has no owl-carousel class). Turning the UL into a flex container breaks
   our simple float-based fallback grid below it (float is ignored on a
   flex item, and in testing the UL's own width then stopped matching its
   containing card at narrower breakpoints — up to 825px of overflow at
   390px wide). Force it back to a plain block so the `float:left`/`width:N%`
   li rule above lays the grid out the way it was actually designed to.
   `:not(.owl-carousel)` gives that Porto rule specificity (0,2,1); matching
   it needs `!important` here since `ul.products.columns-N` alone only ties
   at (0,2,1) and stylesheet load order isn't worth relying on. */
.products.columns-2,
.products.columns-3,
.products.columns-4,
.products.columns-5,
.products.columns-6 {
	display: block !important;
	margin-left: 0;
	margin-right: 0;
}

/* Category archive toolbar (Sort by / Show count) — source lays these out as
   a flex row with the sort control left, result count right
   (scrape/out/shots/desktop/category-sarm-liquid.png); WooCommerce's default
   markup has no shared wrapper for the two, so this just positions them. */
.ul-shop-toolbar {
	display: flex;
	justify-content: space-between;
	align-items: center;
	margin: 20px 0;
}
.ul-shop-pagination {
	text-align: center;
	margin: 30px 0;
}
.ul-shop-pagination .page-numbers {
	display: inline-block;
	padding: 8px 14px;
	margin: 0 3px;
	border: 1px solid var( --porto-input-bc, #ddd );
}
.ul-shop-pagination .page-numbers.current {
	background: var( --porto-primary-color, #7c1010 );
	color: #fff;
}

/* Homepage FAQ + Contact Us: source lays these out side-by-side in a single
   66%/33% row (elementor-element-22f41fc0), not as two stacked full-width
   sections — this is bespoke markup (not reproduced from the harvested
   page CSS, which only covers Elementor's own generated classes), so it
   needs its own layout rule here rather than relying on Porto's CSS. */
.ul-home-faq-contact-row {
	display: flex;
	flex-wrap: wrap;
	gap: 40px;
}
.ul-home-faq-col {
	flex: 2 1 500px;
}
.ul-home-contact-col {
	flex: 1 1 280px;
}

/* Homepage "50+ Pharmaceutical Grade SARMS..." block: source pairs this
   copy with a COA image in a 50/50 column split (elementor-col-50 x2).
   Same bespoke-markup reasoning as the FAQ/Contact row above. */
.ul-home-content-block-split .container {
	display: flex;
	flex-wrap: wrap;
	align-items: center;
	gap: 40px;
}
.ul-home-content-block-split .ul-home-content-block-text,
.ul-home-content-block-split .ul-home-content-block-image {
	flex: 1 1 320px;
}
.ul-home-content-block-image img {
	max-width: 100%;
	height: auto;
	display: block;
}
.ul-home-content-block-image figcaption {
	text-align: center;
	margin-top: 10px;
}

/* Homepage section background colors — confirmed via CDP computed-style
   checks against the live source (not guessed): the intro block + all four
   plain text/CTA content blocks (SEO block, best-source block, manufacturing
   block, shortcuts block) sit on solid maroon with white text; the NEW
   RELEASES product carousel sits on a light blue band; the LAB SUPPLIES
   carousel, FAQ/Contact row, and both "What Are SARMS" headings sit on a
   ~6%-opacity maroon tint, all keeping the default dark heading color. Every
   other homepage section (the other product carousels, the social banner)
   has no background on the source and is left untouched. */
.ul-home-intro,
.ul-home-content-block {
	background-color: var( --e-global-color-primary, #7c1010 );
	padding: 50px 0;
}
.ul-home-intro *,
.ul-home-content-block * {
	color: #fff;
}
.ul-home-bg-blue {
	background-color: #42c2fa;
	padding: 50px 0;
}
/* Video showcase section right after the SEO content block — plain solid
   maroon (confirmed via computed style on the live source: no background-
   image/clip-path anywhere in this section's ancestor chain; the "diagonal
   red/navy split" look is baked into the embedded video's own YouTube
   thumbnail artwork, not a page effect). */
.ul-home-video-showcase {
	background-color: var( --e-global-color-primary, #7c1010 );
	padding: 50px 0;
}
.ul-home-video-wrap {
	position: relative;
	max-width: 874px;
	margin: 0 auto;
	aspect-ratio: 16 / 9;
}
.ul-home-video-wrap iframe {
	width: 100%;
	height: 100%;
	display: block;
}
/* "FOLLOW US ON SOCIAL MEDIA" bar (ul_social_banner()) — the heading/icons
   markup and Porto's own .share-links icon-badge styling were already
   wired up correctly (confirmed via screenshot: icons render fine as
   colored circles), but this section never had the source's own USA-flag
   background image rule, so it was just plain white locally — easy to
   mistake for a missing/broken section at a glance. Image + position/size/
   repeat values confirmed via the live source's computed style (same
   recovered file as the homepage hero's hexagon pattern work). */
.ul-home-social-banner {
	background-image: url("../img/home/usaflag-1.jpg");
	background-position: center center;
	background-repeat: no-repeat;
	background-size: cover;
	padding: 50px 0;
	text-align: center;
}
.ul-home-social-banner .share-links {
	display: flex;
	justify-content: center;
}
.ul-home-bg-tint,
.ul-home-faq-contact,
.ul-home-what-are-sarms {
	background-color: var( --e-global-color-471984f, rgba( 124, 16, 16, 0.06 ) );
	padding: 50px 0;
}

/* Per-page Elementor hero (see inc/page-heroes.php) — a full-bleed photo
   with a dark overlay and a large white heading, replacing the maroon
   breadcrumb bar on the handful of pages that build their own hero section.
   Values match the source's computed styles (Payment Options page). */
.ul-page-hero {
	position: relative;
	display: flex;
	align-items: center;
	justify-content: center;
	min-height: 300px;
	padding: 100px 0;
	background-position: 50% 0;
	background-size: cover;
	background-repeat: no-repeat;
}
.ul-page-hero-overlay {
	position: absolute;
	top: 0;
	right: 0;
	bottom: 0;
	left: 0;
	background-color: #000;
	opacity: 0.57;
}
.ul-page-hero .container {
	position: relative;
	z-index: 1;
}
.ul-page-hero-title {
	margin: 0;
	color: #fff;
	font-family: "Nova Square", "Open Sans", sans-serif;
	font-size: 40px;
	font-weight: 700;
	letter-spacing: 4px;
	text-align: center;
	text-transform: uppercase;
}

/* Single-product "Description / Additional information / Reviews" tab bar —
   Porto's own CSS only styles `.resp-tabs-list`/`.resp-tab-item`/
   `.resp-tab-active` markup, produced by a jQuery "responsive tabs" plugin
   that was never ported into this child theme (assets/js/site.js only wires
   up the Elementor FAQ accordion). WooCommerce's own wc-single-product.js
   already switches tabs correctly on its native `ul.tabs.wc-tabs li` /
   `li.active` markup (verified: click handler toggles .active + panel
   display) — only the visual styling was missing, so the tab bar rendered as
   a plain bulleted list instead of Porto's horizontal red/white tab bar.
   Restyling that native markup directly (rather than porting the whole
   resp-tabs plugin) reproduces the same look child-theme.css already defines
   for `.resp-tabs-list li.resp-tab-active` (dark red #7c100f / white active
   tab) against the live source's product-description tab bar. */
.woocommerce-tabs ul.tabs.wc-tabs {
	display: flex;
	flex-wrap: wrap;
	margin: 5px 0 0;
	padding: 0;
	border-bottom: 1px solid var(--porto-gray-2, #e7e7e7);
	list-style: none;
}
.woocommerce-tabs ul.tabs.wc-tabs li {
	display: block;
	list-style: none;
	margin: 0 1px 0 0;
	padding: 10px 30px;
	font-weight: 700;
	font-size: 13px;
	text-transform: uppercase;
	letter-spacing: 0.02em;
	color: var(--porto-primary-color, #7c100f);
	background: var(--porto-gray-1, #f7f7f7);
	border-top: 3px solid transparent;
	cursor: pointer;
}
.woocommerce-tabs ul.tabs.wc-tabs li a {
	color: inherit;
	text-decoration: none;
}
.woocommerce-tabs ul.tabs.wc-tabs li.active,
.woocommerce-tabs ul.tabs.wc-tabs li:hover {
	background-color: #7c100f;
	color: #fff;
	border-top-color: #fff;
}
.woocommerce-tabs .woocommerce-Tabs-panel,
.woocommerce-tabs .panel {
	padding-top: 20px;
}

/* 8-icon trust-badge row in each product's own description ("How To
   Purchase...?" section — Authenticity Seal / Batch Tracking / COA /
   Customer Service / Fast Shipping / Purity / Safe & Secure Ordering / 3rd
   Party Lab Tested). Each badge's label is baked into its own PNG — the raw
   HTML is just N bare `<img width="128" height="128" class="alignnone">`
   tags separated by whitespace inside one centered <p>, relying on default
   inline wrapping. That only fits 7 across before the description column's
   actual width (narrower than the full viewport once the card padding and
   flex layout are accounted for) wraps the 8th onto its own row, where the
   source renders all of them on one line. Target the icons by their literal
   128x128 HTML attributes — distinct from every other inline-icon pattern
   on this template (hand-click icons are 32x21, the PDF icon is 32x32, the
   COA/MSDS buttons are full-size) — and lay them out as a shrink-to-fit flex
   row instead of relying on raw inline wrap, so however many badges a given
   product has always fit on one line at desktop widths. Left to wrap
   naturally below 768px so the icons stay a legible size on mobile. */
@media (min-width: 768px) {
	p:has( > img[width="128"][height="128"] ) {
		display: flex;
		flex-wrap: nowrap;
		justify-content: center;
		align-items: flex-start;
		gap: 6px;
	}
	img[width="128"][height="128"].alignnone {
		width: 100%;
		max-width: 128px;
		height: auto;
		flex: 1 1 0;
		min-width: 0;
	}
}

/* Homepage top banner's white hexagon honeycomb background — present on the
   source (assets/css/source/home-inline-elementor.css already has the right
   background-image/position/size/repeat, confirmed via the harvested CSS)
   but the rule there is scoped to the exact numbered Elementor element class
   (`.elementor-266730 .elementor-element.elementor-element-73338e24`) that a
   literal Elementor export would carry — front-page.php's hand-built
   recreation of this section uses a plain semantic class instead
   (`.newthreeitembanner`), so that rule never matches anything here and the
   image was reported missing entirely. Target the real local class directly
   instead of fighting the harvested selector.

   On the source, this same section ALSO contains the "50+ Sarms for
   Sale..." heading text directly below the 3 product columns (confirmed via
   CDP: both the product photos/buttons AND that heading text sit inside the
   one Elementor section, same hexagon background behind all of it). Our
   hand-built markup splits that into two separate adjacent sections
   (`.newthreeitembanner` for the photos/buttons, `.futuretense` for the
   heading text) with no gap between them, so the same background needs
   applying to both — confirmed via screenshot the hexagon pattern was
   hard-cutting off exactly at that section boundary, going straight to
   plain white behind the heading, before this fix. */
.newthreeitembanner,
.futuretense {
	background-image: url("../img/home/White-Hexagons-Popping-Up-Background-FULL.jpg");
	background-position: center center;
	background-repeat: no-repeat;
	background-size: cover;
}
@media (max-width: 767px) {
	.newthreeitembanner,
	.futuretense {
		background-image: url("../img/home/White-Hexagons-Popping-Up-Background-FULL-Mobile-Version-500x1900-SMALLERHexagons.webp");
	}
}

/* Single-product gallery thumbnail strip (.flex-control-thumbs) — WooCommerce's
   native FlexSlider gallery only actually runs when the theme declares the
   wc-product-gallery-* theme-support flags (added in inc/setup.php; without
   them wc_single_product_params reports every slide/zoom/lightbox feature
   disabled and ALL gallery images render as a plain stacked block list
   instead of one slide + a horizontal thumbnail row — this was the real
   cause of the thumbnail strip looking "detached"/wrong on every product).
   Once that's turned on, FlexSlider itself (bundled in WooCommerce's own
   single-product.js, no separate library needed) correctly hides all but
   the active slide and builds the `.flex-control-nav.flex-control-thumbs`
   thumbnail list — but we dequeue WooCommerce's own CSS (build method rule
   1: Porto's CSS replaces it), and Porto's own harvested CSS never styles
   this class at all since Porto normally replaces the whole gallery with
   its own `.product-thumbs-slider` owl-carousel instead of using FlexSlider
   (confirmed: no JS in this theme ever references that Porto system
   either). So neither stylesheet covers `.flex-control-thumbs` — reproduced
   here directly from WooCommerce's own default (dequeued) stylesheet. */
.flex-control-thumbs {
	overflow: hidden;
	margin: 0;
	padding: 0;
}
.flex-control-thumbs li {
	width: 25%;
	float: left;
	margin: 0;
	list-style: none;
	position: relative;
}
.flex-control-thumbs li img {
	cursor: pointer;
	opacity: 0.5;
	margin: 0;
	width: 100%;
	display: block;
}
.flex-control-thumbs li img.flex-active,
.flex-control-thumbs li img:hover {
	opacity: 1;
}
.flex-control-thumbs li:nth-child(4n + 1) {
	clear: left;
}