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

[redicer]

Preconditions

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

Steps to reproduce

1. Create test category. Is Anchor - Yes.
2. Create test product.
3. I look my test category on the storefront. Layered navigation filter with 'Price' is not displayed.
4. Returns to the Admin page, and add to the my product test attribute 'Color'. (Filterable (with results)).
5. Attribute 'Color' is also not displayed in the filter.
6. 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?

[kandy]

@redicer Thanks for reporting, definitely sounds like a bug. We have created ticket MAGETWO-48639 to investigate.

[davidnguyen2205]

Is it fixed?
I got the same problem...

[blizam]

Is your test category a sub-category of another non-root category? Does your test category have any of its own sub-categories?

https://github.com/magento/magento2/issues/5009

[bartoszkubicki]

Same here, attribute shows when attribute is set Filterable (no results) but not when with results.
The problem apperas both in non-root categories and their subcategories.

[blizam]

seems better/fixed in 2.1.0 -- I haven't tested thoroughly but Layered Navigation seems much better in 2.1.0

[bartoszkubicki]

No it is not - as I pointed out higher. Attribute assigned Filterable (with results) shows randomly or don't appear at all. It doesn't happen when Filterable (no results) is set, but it doesn't work when I set it programatically, only works set from adminhtml.

[alphatwenty]

I'm having the same issue using the color attribute on 2.1.0.

[pyyick]

@alphatwenty Same on 2.0.10

[Juigeli]

Same here on Magento 2.1.0 CE. Attributes set to Filterable (with results) or Filterable (no results) shows randomly in different categories or don't appear at all. I already tried flush cache, delete and re-compile static files and re-import products. I can give access to our development server if that helps to solve this problem.

[Juigeli]

Anything new about this?

[sclubricants]

I'm not sure what the answer is but I managed to get my options to show by changing from "<" to "<=" in vendor/magento/module-catalog/Model/Layer/Filter/AbstractFilter.php
at the bottom:

Version: 2.1.2

/**
 * Checks whether the option reduces the number of results
 *
 * @param int $optionCount Count of search results with this option
 * @param int $totalSize Current search results count
 * @return bool
 */
protected function isOptionReducesResults($optionCount, $totalSize)
{
    return $optionCount <= $totalSize;
}

I've been fussing with it for hours and not sure this is the answer..

[Juigeli]

@sclubricants Thank you so much, this seems to fix the problem and my missing attributes are back!

[ctadlock]

@kandy Any update on this bug?

[pushonscott]

We have found this issue on multiple builds, any news @kandy?

[kandy]

Looks like we can not reproduce this issue internally.

Maybe I need to clarify something about filters in LN.
1) The filter is not shown if it contains no options.
2) The option is not shown if it will not decrease numbers of product on page

For example, if we have 5 configurable product and all have all variations of color attribute the filter will not be shown. Or if a category has only one product, filters will not shown too.

[pushonscott]

@kandy This works for me, thanks!

[macgus62]

Thanks sclubricants! This works for me.

[TommyKolkman]

@sclubricants This works for me, BUT is a core fix of course. We can't however, fix this in a problem because this is a protected function and you can't overwrite that with a plugin. Any idea on how we can do this?

[pushonscott]

@TommyKolkman take another look at @kandy's last reply and try to digest it a little more.

In my case, point 2 hit the nail on the head for us:

"The option is not shown if it will not decrease numbers of product on page"

[TommyKolkman]

@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?

[maghamed]

@TommyKolkman 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

[Ctucker9233]

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

[ngz82]

Agree with @TommyKolkman , 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. @TommyKolkman how did you resolve or work around this?

[s-heinrich-igniti-de]

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.

[jpcsguru]

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

[NanoCaiordo]

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

[AntonEvers]

@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.

[maghamed]

@ajpevers @Ctucker9233 @TommyKolkman

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

[irfanMukhtar]

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

[magento-engcom-team]

@redicer, thank you for your report.
We've created internal ticket(s) MAGETWO-84386 to track progress on the issue.

[piotrekkaminski]

Thank you for your submission.

We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues.

Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

We are closing this GitHub ticket and have moved your request to the new forum.