Hi Charlie,
Found a possible bug, this one on CS Forms driving a Looper Provider via AJAX.
On our product-type filter (checkbox list, data-cs-ajax="1" , targeting a Looper Provider via data-cs-ajax-selectors ), the grid layout breaks completely once a filter is applied. Products go from a proper multi-column grid to a single stacked column with oversized images.
Worth noting: filtering on product_cat (native WooCommerce Product Category) works fine through the same Looper setup. The issue only appears when filtering on a custom taxonomy (in our case ew_subject , registered on the product CPT). That distinction may point you straight at the cause.
I compared the DOM before and after filtering. The atomic class hashes are entirely different between the two:
- Initial page load:
<article class="x-col e2669-e23 m225-10 m225-11 m225-13" id="product-posts">, with each product column asx-col e2669-e27 m225-10 m225-11 m225-3 m225-4 - After the AJAX filter fires:
<article class="x-col e2710-e23 m23a-v m23a-w m23a-y" id="product-posts">, with each product column asx-col e2710-e27 m23a-v m23a-w m23a-3 m23a-4
The e2669 / m225 classes carry the grid column width, image sizing, and spacing rules from the page’s loaded stylesheet. The AJAX response swaps in an entirely different e2710 / m23a hash set, and there’s no matching CSS for those classes anywhere on the page, so the browser falls back to unstyled block defaults (full native image width, one column per row).
It looks like the AJAX partial is being rendered through a fresh Cornerstone instance that generates its own class hash, and that instance’s CSS was never enqueued to the page, but only when the underlying query is against a custom taxonomy rather than the native category taxonomy.
Thanks,
Christopher