Remember min/max values after apply facet

It seems it was originally planed to work like the way you want it to, but the code that make the slider "remember" the old position doesn't work.

The culprit in search_api_ranges.module:

// Remove current range field from the filters
  // Otherwise our min/max would always equal user input
  $filters = &$query->getFilter()->getFilters();

  foreach ($filters as $key => $filter) {
    // CHeck for array, old style filters are objects which we can skip
    if (is_array($filter)) {
      if ($filter[0] == $variables['range_field']) {
        unset($filters[$key]);
      }
    }
  }

  // Filter out results with no values for that field.
  $query->condition($variables['range_field'], NULL, '<>');

The foreach loop tries to unset the filter that restricts the slider, but it cannot do so because the object it tries to manipulate (the query object) is protected.

There is currently no way to unset a filter in the query object.

Here are temporary workaround to make it work:

in search_api_ranges.module:

// Remove current range field from the filters
  // Otherwise our min/max would always equal user input
  $filters = &$query->getFilter()->getFilters();

  foreach ($filters as $key => $filter) {
    // CHeck for array, old style filters are objects which we can skip
    if (is_array($filter)) {
      if ($filter[0] == $variables['range_field']) {
        unset($filters[$key]);
      }
    }
  }

  // Filter out results with no values for that field.
  $query->condition($variables['range_field'], NULL, '<>');

  $query->unsetFilter($variables['range_field']);  // this is new...

and in search_api/includes/query.inc

/**
   * {@inheritdoc}
   */
  public function getFilter() {
    return $this->filter;
  }
  /**
   * UNSET A FILTER PATCH!!!
   */
  public function unsetFilter($field) {
	$filters = &$this->filter->getFilters();
	foreach ($filters as $key => $filter) {
		if( isset($filter->tags) && is_array($filter->tags) ){
			if( in_array('facet:'.$field, $filter->tags) ){
				unset($filters[$key]);
			}
		}
	}
  }

paste the new unsetFilter function after the getFilter function.. in the class SearchApiQuery class.

Apparently its possible to unset the Filter by reference.

So everything that needs to be done is replace

foreach ($filters as $key => $filter) {
    // CHeck for array, old style filters are objects which we can skip
    if (is_array($filter)) {
      if ($filter[0] == $variables['range_field']) {
        unset($filters[$key]);
      }
    }
  }

with:

foreach ($filters as $key => $filter) {
    if( isset($filter->tags) && is_array($filter->tags) ){
      if( in_array('facet:'.$variables['range_field'], $filter->tags) ){
        unset($filters[$key]);
      }
    }
  }

How?

What I posted just restores the original functionality.

Without this it is impossible to restore/increase the range, because everytime you make the range smaller you can't go back!

// Remove current range field from the filters
// otherwise our min/max would always equal user input.

The difference is that the filter does not restrict itself to its currently selected range.

It shows the possible min/max values for the current search, had itself not been restricted (not other filters). This way one can only change the range to other possible values!

Its still limited to possible values only.

I send you a link where you can see this behaviour in action.

Cool!

Sorry to open this up, but I think this still needs work. I am too in the need of this feature: being able to go back to a wider range by using the slider instead of using ONLY the breadcrumb trail so I was happy to try dev with this patch, however, I found the following behavior:

Once I set up a filter by range (price in my case) I get the proper filter, now the slider allows me to wider the range again, say back to its original value, however what I end up is:

Breadcrumbs: XXXX » 24 – 40 » 22 – 40

And slider got stuck in 24, never got back to 22, which makes considering the first filter is also applied first.

What I would expect is for it to remove the previous range facet and replace itself by a new one. Is that possible? Makes sense?

Hi hanoii,

are you using other search-api modules with it, for example search-api-ajax?
The range gets replaced correctly on my site, I don't have any ajax running.

No, no ajax, strange though, any particular configuration of the facet that I need to be aware, tried both AND and OR, and a copule of other settings but none changes the behavior I am noticing.

Do you have a link to your site to check?

Any help will be appreciated.

EDIT: Of course the URL also has the range facets appended as well following the breadcrumbs.

I attached a screenshot of my facet configuration.
Please provide more information regarding your setup. Could you post a URL with the duplicated ranges?

The only difference I see in your settings with mine, is that I have an AND/OR operator, see image.

I am using the latest version of search api all of the search_api modules, also using search_api_solr. And of course, dev version of ranges, what about you?

Latest version of facetapi as well, stable though.

And the URL is like:

http://site/views/precio/%255B100%2520TO%2520410%255D/precio/%255B51%252...

I'm using

dev version of Search API Ranges (not from Repository, I use the zipped one attached to the project) 7.x-1.5+5-dev

Facet API 7.x-1.3 (stable)
Search API 7.x-1.11 (stable)
Solr search (search_api_solr) 7.x-1.4 (stable)

What I'm not using:
Search Ajax
Facet API Pretty Paths

Your URL looks like a Facet API Pretty Paths URL, I think this is the cause of your problem.
The Facet API Pretty Paths Module doesn't know how to replace Ranges.

Just a bit before your post I disabled pretty paths and it did work... hmmm,, I really like/need to use that module, will follow it up a bit more.

I suggest you open an issue in the Facet API Pretty Paths project.
I think they already have a ticket with this problem: https://drupal.org/node/2236705

Not sure if it's the same though, I did find #1511148: Please make compatible with Search API Ranges which points to #1511144: Please make compatible with Facet API Pretty Paths on this module but I think those were different issues.

Might re-open that issue and see where it goes, will try to crack it in the code though to see if I can find the route. I'd assume is more a work into pretty paths that something else.

Yes, I think the issue is in this part in search_api_ranges.module

Line: 379

  if (module_exists('facetapi_pretty_paths')) {
    $exists = FALSE;
    $split_path = explode('/', $path);
    foreach ($split_path as $key => $value) {
      if (!($key % 2) && $value == $range_field) {
        $exists = $split_path[$key + 1];
      }
    }

    // Decision: replace existing range or add new
    $new_range = '[' . $values['range-from'] . ' TO ' . $values['range-to'] . ']';
    if ($exists) {
      $path = str_replace($exists, $new_range, $path);
    }
    else {
      $path .= '/' . $range_field . '/' . $new_range;
    }

    // Unset non-pretty query
    unset($params['f']);
  }

Wow, it was indeed, thanks!

Attached patch

Use the latest dev version

I did notice a problem as well. It seems the dev build on d.o did not pick up the last commit to the repository, which was the commit in #24 and #25. If I download the dev release from the project, the last commit is not included. If, however, I clone the repository using git, the commit is there. I've never seen this before and I'm not sure if there is a way to force a rebuild of the dev release. Perhaps contacting the infrastructure team?

Base theme of this issue is: Remember min/max values after apply facet, but latest dev release does not provide a solution.
Patch #10 did't work.

Solution https://www.drupal.org/node/2294807

Thanks, https://www.drupal.org/node/2294807 indeed solved this issue for me

Applying patch in https://www.drupal.org/node/2294807 to latest dev solved this for me too.