In Layered Navigation not show attributes with "Filterable (with Results)"

apiuser · ‎01-17-2018

Feature request from redicer, posted on GitHub Jan 29, 2016

Preconditions

I am installing Magento 2.0.2. No customization. No sampledata. Apache 2.4, PHP 5.6.

Steps to reproduce

Create test category. Is Anchor - Yes.
Create test product.
I look my test category on the storefront. Layered navigation filter with 'Price' is not displayed.
Returns to the Admin page, and add to the my product test attribute 'Color'. (Filterable (with results)).
Attribute 'Color' is also not displayed in the filter.
Returns to the Admin page, and change attribute 'Color'. from 'Filterable (with results)' to 'Filterable (no results)'.

Expected result

Price filter is visible.

Actual result

Attribute 'Сolor' display begins. But the "Price" is still not visible.

In /var/log/system.log

[2016-01-29 23:21:49] main.INFO: Cache file with merged layout: LAYOUT_frontend_STORE1_28f8f27b8478aea82e0ee080b652907b7: Please correct the XML data and try again. [] [] [2016-01-29 23:21:49] main.INFO: Cache file with merged layout: LAYOUT_frontend_STORE1_2a7ccd8094436548b564a588f6303121c: Please correct the XML data and try again. [] [] [2016-01-29 23:21:49] main.CRITICAL: Broken reference: the 'store.settings.currency' tries to reorder itself towards 'store_language', but their parents are different: 'store.settings' and 'header.panel' respectively. [] [] [2016-01-29 23:21:49] main.INFO: Cache file with merged layout: LAYOUT_frontend_STORE1_26f1b068ec7ccf4878f9284dd1137afd1: Please correct the XML data and try again. [] [] [2016-01-29 23:21:54] main.INFO: Cache file with merged layout: LAYOUT_frontend_STORE1_2d41d8cd98f00b204e9800998ecf8427e: Please correct the XML data and try again. [] [] [2016-01-29 23:23:04] main.INFO: Cache file with merged layout: LAYOUT_adminhtml_STORE1_3942059a62c87af8724fe1ef3f757dc31: Please correct the XML data and try again. [] [] [2016-01-29 23:23:04] main.CRITICAL: Broken reference: the 'header' tries to reorder itself towards 'global.notices', but their parents are different: 'page.wrapper' and 'notices.wrapper' respectively. [] [] [2016-01-29 23:23:04] main.CRITICAL: Broken reference: the 'page.breadcrumbs' tries to reorder itself towards 'notifications', but their parents are different: 'page.wrapper' and 'notices.wrapper' respectively. [] [] [2016-01-29 23:23:04] main.CRITICAL: Broken reference: the 'global.search' tries to reorder itself towards 'notification.messages', but their parents are different: 'header.inner.right' and 'header' respectively. [] [] [2016-01-29 23:23:10] main.INFO: Cache file with merged layout: LAYOUT_adminhtml_STORE1_3d377266e3d6552ca5fe63f5fe36483b7: Please correct the XML data and try again. [] [] [2016-01-29 23:23:10] main.INFO: Cache file with merged layout: LAYOUT_adminhtml_STORE1_3793edbdc1c00dd1c3aa9e1b3dc856b39: Please correct the XML data and try again. [] [] [2016-01-29 23:23:11] main.CRITICAL: Broken reference: the 'header' tries to reorder itself towards 'global.notices', but their parents are different: 'page.wrapper' and 'notices.wrapper' respectively. [] [] [2016-01-29 23:23:11] main.CRITICAL: Broken reference: the 'page.breadcrumbs' tries to reorder itself towards 'notifications', but their parents are different: 'page.wrapper' and 'notices.wrapper' respectively. [] [] [2016-01-29 23:23:11] main.CRITICAL: Broken reference: the 'global.search' tries to reorder itself towards 'notification.messages', but their parents are different: 'header.inner.right' and 'header' respectively. [] []

Do you have any ideas about this?

apiuser · ‎01-17-2018

Comment from TommyKolkman, posted on GitHub Mar 03, 2017

@pushonscott I get that. However, I'm stuck with a situation where we've got clothing in all types of sizes. Now, when for example all types of clothing have "L" as a size, "L" is not shown as an option because it wouldn't decrease the number of products on the page. However, to the user, it looks like there are no "L" versions available - therefore decreasing the chance on conversion.

Get my point why I want this anyway?

apiuser · ‎01-17-2018

Comment from maghamed, posted on GitHub Mar 03, 2017

@BureauElephant yes, you described it right. Magento now doesn't show Layered Navigation filter if applying this filter doesn't lead to reducing result set. Because potentially you can get into infinite loop applying this filter to the result set.

potentially this filter could be shown as disabled (not applicable) in UI, but this could look weird for users as well

apiuser · ‎01-17-2018

Comment from Ctucker9233, posted on GitHub Mar 04, 2017

@maghamed What about somehow flagging it as the current selected option? Like '"Large" (style: greyed out) - current option'.

apiuser · ‎01-17-2018

Comment from ngz82, posted on GitHub Apr 19, 2017

Agree with @BureauElephant , the user experience in this situation is not ideal, we have the same thing where customers think we do not have any of those sizes etc as they don't show up. @BureauElephant how did you resolve or work around this?

apiuser · ‎01-17-2018

Comment from s-heinrich-igniti-de, posted on GitHub Apr 21, 2017

Our issue was that the type of filterable attributes was set to "text". We have changed the type to "varchar" and got the filter (with results) working.

apiuser · ‎01-17-2018

Comment from jpcsguru, posted on GitHub Jun 03, 2017

This issue is is still in in 2.1.6 and above solution does not work

apiuser · ‎01-17-2018

Comment from NanoCaiordo, posted on GitHub Jul 18, 2017

~~We are having the same issue using custom Attribute sets, CE 2.1.7. It does not matter if the Attribute is Filtrable with or without results. Price and some Drop Down Select aren't showing.~~

~~Further investigation shows that an entire filtrable attribute is removed when a product returns 0 as count for that specified option.~~

~~For example: color red (1), blue (3) shows up... but red (0), blue (4) kills the entire color attribute. This explains most issues I'm facing, but it doesn't explain why the Price isn't coming up.~~

It does not seem to be a bug.

If the price, or any other Attribute, is not showing up is because all of your products are going to be included in one option only, eg: Red (0), Green(0), Blue (4).

To resolve Price issues try: go to Stores -> Configuration -> Catalog change Scope from Default Config to your Website or Store and under Layered Navigation set Price Navigation Step Calculation to Manual set Default Price Navigation Step and Maximum Number of Price Intervals to something you are comfortable with.

As far as my experience with this issue goes, for other Attributes, if this bother you, this bug report should be turned into a feature request. For me it works as expected.

Cheers

apiuser · ‎01-17-2018

Comment from ajpevers, posted on GitHub Aug 08, 2017

@maghamed I find your approach to be very technical. I rather view this problem from the user's perspective:

If a user is on a list page and wants to buy shoes, the user will want to apply a filter with their size, so that only shoes that are available in their size will show. This has become impossible.

Either the shop owner can configure the size filter to be able to render options with 0 results, resulting in displaying all sizes in the catalog, even for non-shoes, or the shop owner sets the attribute to Filterable (with results) and he loses the options that are present on all products in the category as well as options that have 0 results.

The result: customers will think that their size is not available, while it is available on all products on the page. They will not buy products because they'll think these products are out of stock. This is a conversion killer.

So there is a bug: Filterable (with results) makes no difference between options that have no results and options that have the full product collection as a result. This started here: https://github.com/magento/magento2/commit/3fd3c55b1a46b338ae603e4401bf1150b52e6dc8

It is a functional change that is different from Magento 2.0.x and Magento 1.x.

If there is a possibility for an endless loop, please fix that instead of making functional changes to work around it.

apiuser · ‎01-17-2018

Comment from maghamed, posted on GitHub Aug 09, 2017

@ajpevers @Ctucker9233 @BureauElephant

current behavior not to show Layered Navigation filter if applying this filter doesn't lead to reduce result set is not elegant. And we agreed to fix that. We have an internal ticket devoted for this MAGETWO-54219 That was discussed in the comments to GitHub issue #4639

But that's not exactly how we see our Desired Vision for Layered Navigation. We had a Pre-Imagine Hackathon this year where we were working on the issue #9096 Which supposes to add ability of 'OR' inside the LN Attribute Filterset

As a customer I should be able to create complex filters using the layered navigation so that I can find what I'm looking for quicker. Note:

example use case a customer sets category = "shoe', sets color to be both 'brown' and 'black'; results should be filtered as if category = shoe and color in ('brown','black).

That work has not been finished on Hackathon, and we have a corresponding internal ticket for it - MAGETWO-35969. The main find outs we got during the Hackathon:

Don't apply OR logic for Category and Price (for the price it's possible to specify interval manually)
We have to execute 2 queries instead of one: First: to build LN without filters and cache results for further usage. We need to have this to provide initial counters for each option. And these counters should not be changed after some filters applied.
```
Because following current behavior (executing the only query for LN and Search Results) 
we could come up for really awkward behavior:
Red - 5
Greed - 4
Blue - 3 
Red and Blue do not have intersections. 
So, applying Red filter - it's impossible to apply simultaneously Blue one.
```
Second: to get Search Results with all filters applied That could potentially introduce performance degradation because instead of one search query we have to execute two. But 1st query for LN could be cached (as we no need to re-build LN for any further narrowing down filtering). And for further queries we need to execute just 2nd query which retrieves result set.

This behavior is similar to one implemented on Amazon As you can Layered Navigation not shrinked when some filters applied. Thus, we show all possible attributes and filters in despite of what kind of result set we have. (Currently we build LN filter groups depending on Result Set).

Based on the above if we will implement #9096 story, we will automatically achieve a behaviour requested in the scope of current issue (not to show Layered Navigation filter if applying this filter doesn't lead to reduce result set is not elegant.), because we are not going to shrink LN anymore.

That's why I believe we will invest resources to #9096 story than into current issue, because it doesn't make us closer to the desired state. But if community will deliver in Pull Request, we can apply it while we didn't implement #9096

Added Search Product Owner @choukalos for his insight

apiuser · ‎01-17-2018

Comment from irfanMukhtar, posted on GitHub Aug 15, 2017

@sclubricants solution works for me as well in magento 2.1.4 . My attributes are back now