Hi bricks team,
It would be great if there was a query loop to display the variables of a product. For example, in the product archive, the variables of each product are listed and users can easily add their desired variable to the Cart without visiting the product page. It would be a very interesting UI. Of course, this is not a unique case and has been implemented on some websites. Please see the UI below. I will also post an idea for it on the idea board. Thanks
It’s already doable with Query Editor (PHP):
return [
‘post_type’ => ‘product_variation’,
‘post_status’ => ‘publish’,
‘posts_per_page’ => -1,
‘post_parent’ => {post_id},
‘orderby’ => ‘menu_order’,
‘order’ => ‘ASC’,
];
Because variations are technically normal products too (hidden ‘child’ posts) the standard add to card element works on them perfectly too. For name you can use dynamic data to get attribute name.
That’s for single product page but on archive you can just nest this loop inside main product loop without issue.
I’d like to reinforce this request as a native Bricks feature.
Primary request: Please add a Product Variations Query Loop usable on Single Product templates, archives, and regular pages. Each loop item should represent a real WC_Product_Variation and expose native dynamic data/elements for the variation image, attributes/title, description, SKU/GTIN, price/sale price, stock status, variation ID, quantity, and AJAX Add to Cart. It should correctly handle required attributes, stock limits, backorders, sold-individually rules, and WooCommerce notices/fragments.
This would allow layouts where every variation appears in a separate row or card with its own image, details, quantity, and Add to Cart button—fully designable in Bricks without custom PHP.
Secondary suggestion: Extend native variation support with separate Variation Image, Attributes, Price, Stock, Quantity, and Add to Cart elements, plus variation-aware conditions, sorting/filtering, and dynamic tags. This would also solve cases where users need custom placement instead of the current combined variable-product form.
The Query Loop should remain the main priority; the separate elements could follow as the second stage.
