Year facet drills down to the remaining year values

I have same issue (https://www.drupal.org/node/2292903).

• Cannot select multiple years with OR as facets selected subsequent to initially selected year are treated as children of first selected facet.
• Last selected facet becomes active facet and other previously selected facets are ignored.
• Active facets disappear once more than one is selected.

Erm ... Hoping that date facets can behave just like taxonomy term facets.

Thanks for posting.

Can you please provide steps to reproduce on a clean install of Drupal along with the implementing module you are using?

Thanks,
Chris

Will do .. but just about to go away for a few days so early next week at latest.

Hi smilne23.

Not a problem, whenever you can get to it would be appreciated. The issue will remain open, so get to it when you can.

Chris

Hello,

I am having the exact same issue.

I have a document index and facets to display documents of a certain date.

However if I select a year, it works correctly, however grouping all remaining years inside that years, using them as AND clause.

Screenshot attached.

Hi guys,

Do we have any updates on this?

I have the exact same issue (also using Solr) and this is basically preventing the build from going live as its the core functionality of the application (to be able to filter by year).

Is there anything I can do to help?

Cheers,

Duarte

Hi kyuubi.

Yes, please feel free to dive in and help identify root cause and propose a fix. Please post if you need guidance on where to start, but we are in need of someone do dive deep into the code and identify the problem and next steps.

Hi cpliakas,

It's going to be difficult considering I know nothing about the module´s code and it doesn´t seem to be a small module.

However I will certainly try as I really to fix this issue as soon as possible.

If you have any pointers you can share on where to start that would be most helpful.

Thanks for your help.

Hi,

Still no news on this? Any guidance?

I don't understand why is this marked as more info? Didn't we give all info and scenario where this happens?

I dwelled on the code and as I am not maintaining this it's a bit troublesome to find out what is going on.

For some reason This is nesting the dates, and obviously an item can't be created on DateX and DateY.

I have looked into buildListItems and the $build is coming with children already, although I have no idea why..

I have somewhat the same situation you guys have.
If I select multiple dates, then that specific facet filter gets disappeared. I am not using Date facet module for this.

Did any one found any solution?

Any help will be appreciated.

Thanks

I have the same problem, and I'm using Elasticsearch Connector, not Solr.

I have a custom node with a date field. That date field only collects year. When I create a facet using the date, I first get a list of years and then if I click a year, I get the other years appearing beneath in a hierarchy, just as the original submitter.

Elasticsearch Connector 7.x-1.0-alpha9
Facet API 7.x-1.5
Search Facets 7.x-1.20

I checked this issue and saw that this is actually an search api issue. All the code I had to change to fix the mentioned flaws was in search_api/contrib/search_api_facetapi/plugins/facetapi/query_type_date.inc.

First problem: do not hide years
There is an facet setting to handle the display of the year depending on the amount of results (-> "Minimum facet count"). By setting this value to 0 we expect that the filter option is visible all the time. But for real it does not have any impact, as this setting is not used in the build-method of the SearchApiFacetapiDate:

      $values = $results['search_api_facets'][$this->facet['name']];
      foreach ($values as $value) {
        if ($value['count']) {
          $filter = $value['filter'];

If count equals 0, it hides the year. I fixed this by reading the mincount setting of the facet:

      $values = $results['search_api_facets'][$this->facet['name']];
      $mincount = $facet->getSettings()->settings['facet_mincount'];
      foreach ($values as $value) {
        if ($value['count'] >= $mincount) {
          $filter = $value['filter'];

Second problem: allow multiselect
For now the SearchApiFacetapiDate does not support multiselect at all, because it picks one of all available filter items (by using the end-function):

  if ($active = $this->adapter->getActiveItems($this->facet)) {
      $item = end($active);
      $field = $this->facet['field'];

In this case I added a new filter level with one filter for each active item. All filters in this level are connected by the "OR" conjunction:

    if ($activeItems = $this->adapter->getActiveItems($this->facet)) {
      $date_query = new SearchApiQueryFilter('OR');
      foreach($activeItems as $activeItem) {
        $field = $this->facet['field'];
        $filter = $this->createRangeFilter($activeItem['value']);
        if ($filter) {
          $this->addFacetFilter($date_query, $field, $filter);
        }
      }
      $query->filter($date_query);
    }

Third problem: show all the available year without an hierarchie
As SearchApiFacetapiDate does not support multiselect for dates in its original implementation, it assumes that every active item is in an hierarchical relation. When building the filter structure it sets every active item as child of the item before:

    // Gets active facets, starts building hierarchy.
    $parent = $granularity = NULL;
    $active_items = $this->adapter->getActiveItems($this->facet);
    foreach ($active_items as $value => $item) {
      // [...]
      // Stores the last value iterated over.
      $parent = $value;

At this point we need a much more complex logic to decide whether an item is really a subset of another item or whether it is a completely different one. As PoC that this is the right place to avoid the building of an hierarchy I simply commented out the $parent assignment ;-)

Can anyone confirm my thoughts? If I'm right, I think we should move this issue to search api.

I disabled testing my patch, as it patches an search api and not an facet api file.

Thanks for your efforts here, n30r.

I've changed your patch a bit, have avoided hard-coding the conjunction (so the user can choose either AND or OR) and have fixed it so that the result counts display properly by the facets.

I have not dealt with the hierarchy issue.

I agree that this seems to be a Search API problem so I'm moving it to that queue.

Reporting the patch in #17 works well with Search API Solr 7.x contrib Sarnia.

Excellent work, thank you very much!

This worked for me, to get date-based facets to use the OR operator. Moving this to RTBC.

Thanks for bringing this to my attention, mandclu, and sorry, everyone, that I didn’t see this before. Must have slipped past me. (In such cases – when I don’t reply at all in an issue for more than a month – please feel free to ping me in the future, via mail, contact form or Slack.)

While the facet still doesn’t work completely correctly with the OR operator (as you can’t drill down), I guess it’s still better than not offering OR at all. Especially since the AND operator functionality isn’t affected at all.
Regarding the end(): I wanted to leave that in at first, just for the AND operator, but then realized this might also break things for multi-valued date fields. So, I also check for whether the field is single-valued, but then I still apply the optimization, as it’s an easy performance gain. (Even though I now realize this is broken anyways for multi-valued fields until we proprely use BETWEEN conditions.)

Anyways, since I did make functional changes, it would be great if someone could make sure it’s still working for them. Then I’ll commit.
And sorry again for the long delay!

Hi, I can confirm that this OR operator is still working for me - with the latest dev version.
Thanks!

Great to hear, thanks for testing and reporting back!
Committed.
Thanks again, everyone!

I’m not sure if this is the correct place to post this comment, or if it would be better in the date_facets queue, but I’m starting here since I’m using this patch: https://www.drupal.org/files/issues/2019-04-08/2290019-21--date_facets_o...

The displayed counts change and no longer match the actual results once a filter is selected when using OR operator.

I’m using solr to index entityform submissions that have a date field. I want to include a facet with a date range that filters for dates in the past 20 days, past 60 days, etc. I’m using the patch here so that I can use the OR operator. I’m getting the expected results if I use “limit to one active item”, but the count displayed in the parenthesis changes once I make my selection and that count is different from the actual results of the date range. For example, when I select 60 days, I get 19 results, but then the count displayed for 90 Days and 180 Days both change to (19). However, when I change the filter to 90 Days, it returns the expected 20 results, see screenshot.

Should the count displayed behave like other facets? Other facets using the OR operator do not recalculate the number of results.

It’s as though the counts are calculated based on the AND operator.

The following may be separate issues, possibly related to these: https://www.drupal.org/node/2292903 and https://www.drupal.org/node/2580149. If I do *not* limit to one active item…
If I select 20 Days (3) and then 180 Days (22), I only get the 3 results from 20 Days. I would expect to get the 22 results from 180 Days OR 20 Days. If I select 180 Days first and then select 20 Days, I get the expected 22 results.

I’m also using Facetapi Pretty Paths. With “Make paths unique by sorting them” enabled, Pretty Paths sorts smallest to largest. In other words, if I select 90 Days (20) and 20 Days (3), I only get the 3 results from the 20 Days. If I disable the Pretty Paths (or disable “Make paths unique by sorting them”) then the results display according to the order in which they were selected as noted above.

I’m using:
—search_api-7.x-1.26 with this patch: https://www.drupal.org/files/issues/2019-04-08/2290019-21--date_facets_o...
—search_api_solr-7.x-1.14+7-dev so I can get this: https://www.drupal.org/project/search_api_solr/issues/2128537
—facetapi-7.x-1.5
—date_facets-7.x-1.x-dev with this patch: https://www.drupal.org/files/issues/2128517-14-date_facets-properly_dete...

@ capysara: I’m not familiar with the date_facets module, but I guess that is what allows you to specify fixed intervals?
As that functionality is normally not available, my guess would be that the problem is in that module, maybe in the interaction with this new change. Please try reporting it there (or reproducing your problem with the normal date facets).