I am using Hierarchical Select as a filter in Views and everything works just fine. Views has a built in view "taxonomy_term" for displaying of nodes within children terms. However, I can not make this to work such that Hierarchical Selections are used as arguments and not as a filter.

However, all of this could be greatly simplified, if Hierarchical Selection could be configured to give us parent or child terms. From what I can tell, currently it can only select specific terms - either from anywhere or just from terms that are leaves.

In other words, everything would visually continue the way it is right now. But in the background, when a term is selected, it and it's parents would be put into the list, when parent option is configured. Likewise, a selected term and all of its children would be put into the list, when its configured that way.

On the other hand, Hierarchical Select seems too sophisticated, for it not to be able to do this already. Perhaps, I have missed something.

Comments

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

This is a very, very specific use case that is indeed not yet supported. You're either the first to request this or only one of very few, otherwise, it'd have already been supported.

However:

But in the background, when a term is selected, it and it's parents would be put into the list, when parent option is configured.

This is already supported: it's called "save lineage".

OTOH:

Likewise, a selected term and all of its children would be put into the list, when its configured that way.

This is not yet supported, since it's never been requested before, IIRC.

If you really want the latter, you can definitely contribute the patch that does it :)

tesliana’s picture

tesliana commented

Wim, thanks for responding.
If I was not a noob then I would at least try to contribute a patch :)

I have over a hundred different news feeds (categories) from half dozen different sites. Most have categories and sub categories. So, I created a 3 level taxonomy, with Publisher, Category & Sub-category.

First, there are no feeds for any of the Publisher terms as they exist only to group together all of the feeds from the same publisher. On my site users are selecting publishers and expecting to see everything. The same happens with Categories. They want to see everything that is in all of the sub categories, when they select just the category.

This seems to be "standard" expectation from most of my visitors, so I can not believe that I am the only one asking for it. In fact the Views module tries to wrestle with this same issue by providing a built in view (that needs to be activated) called taxonomy_term. Given "taxonomy/term/%1" in a URL, it will list all of the nodes on all of the children terms that belong to the passed in term.

However, I am not able to make this work. I only managed to get Hierarchical Select to work as a filter and not as an arguments provider. While I most likely can somehow solve my case that way, I am looking at the convoluted SQL that is created and am convinced that Hierarchical Select as a filter is the best and most efficient solution - but only if it could provide a list of all children terms, in addition to the selected terms.

In any case, any hints on how to solve this with hierarchical select and taxonomy_term view or at least what to read up on, in order to be able to figure it out my self ? Specifically, any ideas on how to make hierarchical select pass it's selections into a view as arguments ?

EDIT: I have just realized that I could solve this problem for my news feeds this way. Each news feed is currently set up to place a story into a single taxonomy (leaf) term. I could use Hierarchical Select, multi select feature, to place each story into the leaf and all of its parents - either by selecting multiple terms or by using the "lineage" option. However, being able to include children terms when filtering on views, still seems like a natural solution.

Thanks again.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

1) Why do you want to provide the results of HS to Views as arguments instead of a filter? I don't see the advantage.
2) But then again, I personally barely use Views.
3) You won't be able to figure this out by just configuring settings through the UI, because it requires changes in the HS Taxonomy Views implementation. What you need, is to show all levels of your vocabulary except for the final level. In your case, that'd be "Publisher > Category", i.e. the "Sub-category" level would no longer be displayed. That could be configurable, but it isn't, yet, because it isn't supported yet in the code.

I have no idea what this means:

list of all children terms, in addition to the selected terms.

If I understood your use case well, this is a possible solution:
1) enable the "save lineage" setting for all your nodes. This will result in not only the "Sub-category" being saved, but also the "Publisher" and the "Category".
2) now you can allow users to filter by picking any term

This is a solution I did recommend in the past and of which I know quite a few users are doing. This is probably why this hasn't been requested before. Also, this is far more efficient from a DB performance POV, because it allows to filter on a single term instead of a list of terms.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Heh, your edit is exactly what I'm suggesting. Including child terms is absolutely pointless in that case, since it would only increase the burden on the database, with no additional results being displayed.

tesliana’s picture

tesliana commented

Well, let me give you an example.

A story comes out and it is tagged as being about Canada.
Another one comes out and it's tagged about being from Ontario.

What I did with the Ontario story is that I tagged both with Ontario and Canada.

While this satisfies the majority expectation of seeing Ontario stories when selecting Canada, it also corrupts the data from bibliographic sense because now we have no way of selecting just the national level stories.

So, what I was requesting is that when HS selects Canada, to optionally build a list of Canada and Ontario tid's.

The impact on Views and MySQL would be next to nothing because the main part of the query is NODE driven and those TID's are just inclusion/exclusion filters.

There may be a database impact at the point of selecting Canada, because it would have to go through all of its provinces and perhaps all of it's cities and even neighborhoods, if such taxonomy went that deep.

In any case, I have a taxonomy structure with 6 top levels, one of which goes into 2 more sub levels and the other 5 all have just 1 sub level. In total there are ONLY 104 taxonomy terms. However, Firebug is consistently showing around a full second being used just to show me sub categories with record counts, while the whole view of of all of the stories itself is taking only dozens of milliseconds of DB work and always below a full second for construction of some 50 pages with 25 items on each page.

In any case if HS passed on 10 times as many tid's, it would only increase the IN list and would not add all that much to overall filtering ad the DB level, while preserving the structure of data and not having the parent categories' tainted by all of its offspring entries.

In cases where we are talking only about a few hundred records, why is the database being hit each and every time when sub categories are being selected. Why is the there not an option to read in the whole taxonomy tree and have it available to the client in memory?

Thanks again.

tesliana’s picture

tesliana commented

What additional info is needed ? ... contributed code to review ;?)

tesliana’s picture

tesliana commented
Status: Postponed (maintainer needs more info) » Active

So, with my above explanation, what other info is required ?

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Component: Code - Taxonomy Views » Code
Status: Active » Needs work

The impact on Views and MySQL would be next to nothing because the main part of the query is NODE driven and those TID's are just inclusion/exclusion filters.

Wrong, when the number of TIDs gets large, it will result in severe performance issues. Also, you simplify the case: it's not just a matter of inclusion/exclusion; it's also necessary to build the term hierarchy first so that you know the TIDs of child terms and of those child terms' child terms, and so on.

There may be a database impact at the point of selecting Canada, because it would have to go through all of its provinces and perhaps all of it's cities and even neighborhoods, if such taxonomy went that deep.

Ok, so apparently you understood that already :P I should've read the entire comment first :|

In any case, I have a taxonomy structure with 6 top levels, one of which goes into 2 more sub levels and the other 5 all have just 1 sub level. In total there are ONLY 104 taxonomy terms. However, Firebug is consistently showing around a full second being used just to show me sub categories with record counts, while the whole view of of all of the stories itself is taking only dozens of milliseconds of DB work and always below a full second for construction of some 50 pages with 25 items on each page.

In any case if HS passed on 10 times as many tid's, it would only increase the IN list and would not add all that much to overall filtering ad the DB level, while preserving the structure of data and not having the parent categories' tainted by all of its offspring entries.

In cases where we are talking only about a few hundred records, why is the database being hit each and every time when sub categories are being selected. Why is the there not an option to read in the whole taxonomy tree and have it available to the client in memory?

This sounds very odd … HS is normally much faster than "a full second". However, HS is definitely far from as optimized as it could be. Feel free to contribute patches that improve performance :)

What additional info is needed ? ... contributed code to review ;?)

Yes. I don't have the time to implement this myself. Sorry!

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Status: Needs work » Closed (fixed)

The silence makes me think this is solved!