Maintain Hierarchy & Default Order of Exposed Filter Field [#1986198]

Hello!

This request has been posted for the D6 version here: http://drupal.org/node/856736, but I thought it was an important feature request for D7 as well.

I would like the option to retain hierarchy and the default order of the chosen exposed filter field. In my case I'm using a taxonomy field (not sure if keeping the order would be more difficult there compared to a standard field option list). It's been mentioned that the parent needs to be visible even if not selected if it's child is selected. That would be wonderful, if it's not too difficult, but I would be fine with requiring the parent item to be selected so that it shows up in the exposed filter anyway (there may be good arguments against that, but I'd prefer any option to make this work rather than no option as it stands now).

Once this option is working, I think it would be great to allow the Better Exposed Filters module to use Nested Checkboxes/Radio Buttons. I think that's dependent on the main request being implemented, but included the idea here in case it could/should be built at the same time.

Thanks! And thanks for the great module and hard work!

Comment	File	Size	Author
#1	views_hacks-views_filters_selective_maintain_hierarchy-1986198-1.patch	10.41 KB	jamesdixon

Comments

Comment #1

jamesdixon commented 27 September 2013 at 05:40

Status:

Active

» Patch (to be ported)

Status	File	Size
new	views_hacks-views_filters_selective_maintain_hierarchy-1986198-1.patch	10.41 KB

I had similar requirements.

I needed one of the views_filters_select filters to grab it's options from the entire view result set. In my case, this was car make (Honda, Suzuki, etc).

Then my other views_filters_select filter needed to grab it's options from the filtered view result set. For me this was model (Civic, Pilot, etc).

The problem was second filter (model), was showing all models in the view, and not models from the filtered results set.

I created a patch which will give you some options when you expose your views_filter_select filter:

Options come from view results (unfiltered)
Options come from filtered view results
Get options directly from field values in database (useful on views with a large number of results
Options come from filtered view results, or direct from field values in database if no filter is set

By selecting "Options come from view results (unfiltered)" for my make, and "Options come from filtered view results" for model I received the result I wanted.

Changing make to something like "Honda", would ensure only cars that Honda built showed up in the model filter options (like Civic, Pilot, etc).

The last two options were necessary for me, because I had a view with 20,000 results. The default views_filters_select module gave me an out of memory error. The last 2 options are tools to deal with large views result sets.

"Get options directly from field values in database (useful on views with a large number of results", actually ignores the views results, and looks at what unique values the field you're filtering on exist in the database. This works well when you only have 100-1000 unique values for a field.

"Options come from filtered view results, or direct from field values in database if no filter is set", ignores the views results if no filters are set. If a filter is set, it will get the filter options from the views result set that have been filtered. The idea here is if you have a view that has 20,000 results, grab the initial set of results from the database, so your view doesn't die. Then after you filter it down to something more managable, (maybe 1000 records or so in your views result), grab the values from the filtered views results.

I should also note in this patch is included #34 from https://drupal.org/node/1574478 by Hiller. I needed that patch to get my entity references working. Thanks Hiller!

This patch worked in my case but may not for all use cases (ie I didn't test it on taxonomy terms). It gives you a bit more control over what shows up in your result sets, and lets you build some cool hierarchical filters. It also helps manage large views result sets in some cases.

I'm open to feedback, and helping with any issues people run across when using this patch. It is a hack on top of a hack, so I can't guarantee it will work for everyone :)

Comment #2

jamesdixon commented 27 September 2013 at 05:45

I realize now this may not belong here, as this issue was opened specifically for taxonomy terms, and my use case did not involve taxonomy terms. It may work to solve the taxonomy term issue, although not through the default taxonomy term options like "Further limit list to active filters:true"