instock variations
The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday. If you have problems with registration ask help on contact us page pleaseIf you not got email within 24~36 business hours, firstly check your spam box, and if no any email from the support there - back to the forum and read answer here. DO NOT ANSWER ON EMAILS [noreply@pluginus.net] FROM THE FORUM!! Emails are just for your info, all answers should be published only here.
The support doesn work on Saturdays and Sundays, so some Friday requests can be answered on Monday.
Hi There ,
we are using your filter plugin and look at that URL
https://staging31.sportsbrasdirect.com.au/brand/glamorise-sport/?In%20the%20premium%20version=1&In_the_premium_version=1&pa_bra-size=16e&paged=1&pa_features=underwired&paged=1&stock=instock&really_curr_tax=1368-product_brand 16e we have in attributes but not in vairaions then why that product"
Glamorise Sport High Impact Underwire Sport Bra – Pink Blush is
is showing . Its in attribute and not in variations. Can you please tell why its happening.? https://staging31.sportsbrasdirect.com.au/product/glamorise-sport-high-impact-underwire-sport-bra-pink-blush/
"
why no reply ?
Hello
Sorry for delay and thank you for reaching out. Let me explain what's happening here and why WOOF behaves this way.
The Issue:
The product"Glamorise Sport High Impact Underwire Sport Bra – Pink Blush" appears in filter results for pa_bra-size=16e, even though this size doesn't exist as an actual variation of the product.
Why This Happens:
WooCommerce stores attributes at two different levels:
- Product-level attributes - Set on the parent variable product (used to define which variations CAN exist)
- Variation-level attributes - The actual published variations that customers can purchase
HUSKY filters based on product-level attributes, not variation-level. This is intentional for several important reasons:
Performance Optimization:
When filtering, HUSKY queries the wp_term_relationships table to find products that have the selected attribute terms assigned. This is extremely fast because it uses database indexes: SELECT products WHERE term_id = 16e
If HUSKY had to check every individual variation for each product, it would need to:
1. Query all parent products with the attribute
2. Load all variations for each product
3. Check if the specific attribute value exists in published variations
4. Filter out products without matching variations
This would require hundreds of additional database queries on each filter request, causing severe performance issues - especially on stores with many variable products and variations.
The Trade-off:
By filtering at the product level, WOOF ensures:
- Fast filtering performance
- Minimal database load
- Scalability for large catalogs
The trade-off is that products may appear in results if they have an attribute term assigned at the product level, even if no variation exists with that exact combination.
How to Fix This for Your Store:
You need to clean up the product-level attributes to match your actual variations:
1. Go to the product edit page: https://staging31.sportsbrasdirect.com.au/product/glamorise-sport-high-impact-underwire-sport-bra-pink-blush/
2. Scroll to Product Data → Attributes → Bra Size
3. Remove `16E` from the values list (since you don't have a variation with this size)
4. Click Update
5. Go to WooCommerce → Status → Tools and run"Regenerate product lookup tables"
Alternative Approach:
If you want to keep all attribute values at the product level (for example, to show"coming soon" sizes or for SEO purposes), you can:
1. Create the missing variations and set them to"Out of stock"
2. Enable WOOF's"Hide out of stock" option to hide unavailable variations from filter results
This way, the product structure remains complete, but unavailable sizes won't appear in active filter results.