Taxonomy depth for filters and exposed filters

It would be helpful, but depth really adds obnoxious complexity to the queries, so for the moment, this isn't going to happen.

Our workaround: make your vocabulary be multiple-valued, and have the site administrator explicitly assign all the categories to a node.

For example, if you have the following vocabulary:

Food
--bagels
Services
--cleaning

Then for the node "Bob's Bagels", assign to it both "Food" and "bagels". Of course, this would only be practical if you have a relatively small amount of nodes (a few hundred), and a depth of 1 or 2.

subscribing to the feature request. another workaround is available here: #280731: Depth in taxonomy filter(comment 4) - this involves changing the theme function.

+1 for this.

On the work-around, I suppose that instead of having the node author do it manually, one could intercept the node on submit and add the parent if a child is selected. Or perhaps even better: some AHAH to do it on the fly in the admin form. Hmm....

Better than a workaround, here is the patch that implements this functionality.

Apply against Views 2.1, from the root of the Views module. You'll need to clear your cache for the filter to show.

There is only a 'is one of' operator - other operators would add a lot of complexity. Tested with up to depth 2, multi-select and exposed filters. Didn't have a test case at hand for negative depth ; but the queries that are generated look ok.

If people could test & review this, it would be great !

@merlinofchaos : Code to generate the query is copied from the 'argument with depth' handler ; so you should have a pretty good idea what the queries will look like ! If for some reason you'd rather not have this feature included in Views directly, let me know and I will write a separate module instead.

Anselm! you just made my day! after two hours of searching module descriptions to find something like this (and thinking in the back of my head what i would have to do to make this work, in terms of extra coding)... this patch was the instant fix i was looking for! Seems stable so far. I will post back here if run into any errors, but if you don't hear back, assume that it's working fine. and THANKS again!

cheers
Peter 'Fish' Fisera
GoatVirus Technologies
http://goatvirus.com/resume

note to all: i am not sure which cache needs clearing before this will work (see Anselm's comment #5, "You'll need to clear your cache for the filter to show."), but I have the Rebuild module installed (see http://www.pre-emptive.net/doco/rebuild-module-drupal-6 Note that this isn't on the Drupal site for some reason ) so I just cleared any of the caches that I thought might be applicable (filter cache, menu cache, views cache, etc.) and then tried editing my View again, and this time the new filter field "Taxonomy: Term ID (with depth)" had magically appeared. and magically made my night much better! :-)

subscribing

thanks Anselm!

Tested functionality and reviewed for coding standards. I think this is ready to go on (or if not, then to be it's own module!).

Thanks again Anselm, the patch works really well with a single exposed "Taxonomy Term id: (with depth)" filter.

However, as soon as I create a view with multiple "Taxonomy Term id: (with depth)" filters, and preview it (or test it on my site), I get 20 seconds of loading and an eventual "An error occurred at XXXX" error message.

I have 3 filters for my view.
1) Published = True
2) Exposed Taxonomy Term id: (with depth), Vocabulary A, Dropdown, Depth = 1
3) Exposed Taxonomy Term id: (with depth), Vocabulary B, Dropdown, Depth = 1

Both Taxonomy Term ID: (with depth) filters have the following settings:
Is one of: multiple parent categories selected
Force single
Limit list to selected items

Like I said, the view works with a single Taxonomy Term w/ Depth filter, but when creating a second filtering a second vocabulary, things get hairy.

I can poke around for a log if it'd help, but since I'm new to Drupal 6, you might have to direct me to it.

jazic's comments push this into CNW category.

I encourage you to continue to work on this, though. I support this effort and when the code is ready it has a high probability of getting in.

@jazic - are your vocabs large - how many terms?

Could you try doing a similar query using arguments instead of filters - is that also slow?

Could you also try disabling the "Force singleReduce duplicates" checkbox - this is known to harm performance with both taxonomy arguments and filter queries (and has a note explaining this). Does this improve performance?

Actually, scratch that - I can reproduce this on a site with small vocabs, also with "Reduce duplicates" disabled...

subscribing, this would be an immensely useful feature.

I experienced a similar issue to that reported at #11.

Two exposed filters - one a standard filter as provided by views,
one a filer with depth as provided by the patch.

The site just timed out when trying to perform the search.

+1 to the feature. Immensely useful.

Regards
Alan

If the filter is not exposed and the views-creator does not select a term, this error is given; warning: array_merge() [function.array-merge]: Argument #2 is not an array in [redacted]/modules/views/includes/handlers.inc on line 576. It looks like some validate checks are required to ensure a valid filter has been input.

I couldn't reproduce the time-out error mentioned in #11 or #16. #11 states that the error occurs with two exposed depth filters. #16 says that the error occurred with one regular (depth-less) exposed taxonomy term filter and one exposed deepened taxonomy filter.

I could not reproduce the error in either circumstance. My test case only has one hierarchical vocabulary, so my tests with two deepened taxonomy filters involved;

• two filters on the same hierarchical vocabulary, and
• one filter on one flat vocabulary and one filter on one hierarchical vocabulary.

I used varying depths of 1, 2 and 3, did not select "Reduce duplicates" for any of the views, but did select "Distinct" in the View's 'Basic Settings'.

I hope someone has time to complete this and get it in!

Is there anyway to replicate / backport this functionality to 5.x-1.6?

Views 1 for Drupal 5 already has this. Use one of the options inputs for the depth

I did, but I saw the whole tree in my exposed filters (Both with Hierarchical Select, and without it, despite explicitly setting depth to 1). Is this a bug or by design?

I am pretty sure the molasses is somewhere in $this->ensure_my_table(); - before it even starts building/running the query. I can comment out everything else, but still get very very slow execution with just this line (and it's fast if I comment that out too, but wrong of course!).

OK - I worked through this one with a debugger, and the infinite loop is around this chunk of code:

    // Cycle through the joins. This isn't as error-safe as the normal
    // ensure_path logic. Perhaps it should be.
    $r_join = drupal_clone($join);
    while ($r_join->left_table != $base_table) {
      $r_join = views_get_table_join($r_join->left_table, $base_table);
    }

(perhaps there is some truth to that comment!)

OK - after going into this section a little more carefully, the issue appears to be that both $join (and hence $r_join) do not have a ->left_table. Missing this causes an error, which appears to cascade into an infinite loop (obviously because a non-existent $r_join->left_table will never be == $base_table, so the while never exits).

Hence, the question is (and I would be grateful if Earl could chime in here!) - is the issue (a) that we need to figure out the taxonomy join structure such that a $join->left_table exists, or (b) if we should fix this while so it fails gracefully or (c) both!

If we were to fix the structure - what would this look like: why is not inheriting the correct join structure as occurs in the depth argument?

Oh - I should add that this issue only occurs on the *second* pass through ensure_my_table() - the first passes cleanly. Perhaps one solution is to only it ensure_my_table() once (although the semantics of the function name suggest that it is harmless to run a second time).

It would also be interesting to test 2 separate depth arguments (with values passed in to both) - it seems quite possible that the same issue could occur there.

From Earl via IRC
"There is no clone after this: $r_join = views_get_table_join($r_join->left_table, $base_table);
So it is probably modifying the original join, borking the next call of it."

It would also be interesting to test 2 separate depth arguments (with values passed in to both) - it seems quite possible that the same issue could occur there.

I've pretty much cut&pasted the code, so I wouldn't be surprised if that was the case.

Sorry I've not been helping out fixing the bug - I've been really busy ; I'll have some time in January to help out if needed though :)

Subscribing

There is Taxonomy Router. It creates a node for each depth, listing the corresponding terms. The author says views integration is possible. I have not looked at the code in depth, it seems to do the job so far, but I have very little terms still. It seems to work similarly to Taxonomy menu.

Subscribing.

I asked about it and was redirected here from there : http://drupal.org/node/359366

Subscribing. I could really use this!

subscribing

watching

Subscribing as well

Attached is a new patch against HEAD that removes the endless loop by bypassing ensure_my_table().

This works by avoiding the normal Views JOIN syntax, which was throwing errors, and attaching the subselect directly to the query, using the base table as the alias. It also checks for relationships and works.

I only tested with 1-3 exposed filters, using the select dropdown, and without filtering any of the options, but that should not matter.

Tested view is also attached.

Thanks for the patch!

Sorry for a lame question, but what is the HEAD?

Subscribing.

+1 for this feature!

...by the way, HEAD is the latest development version

Been using the patch in #35 for a few days. Works great, no issues as yet. I'd say this is ready to go.

suscribing... is this feature ready to go? It would be really helpful

Subscribing
I ve tried to patch manually the regular view module for D6 but the filter with depth won t show up
Simone

EDIT: neither i can see the filter with depth patching the latest dev

@simone - It's most likely that you just simply need to clear your views cache so the new filter can be found by views. If I remember right, you can do this by going to admin -> build -> views -> tools and then hit "Clear views cache".

That should probably do the trick for you.

Hi
no, i ve cleared all caches, i wonder if i did something wrong patching manually, but i ve been really careful and wrong patching usually leads to a not working system.
Also, in the dev version the file views_handler_argument_term_node_tid_depth.inc is already present, while looking at the patch it should be created from scratch.This file is not present in the release version.
Simone

OK i see where i did wrong... views_handler_!ARGUMENT!_term_node_tid_depth.inc

BUT still no joy although everything seems to be in place this time.
Simone

Ugh! I think I have to apologies here for bothering everybody with an unreal issue, with fresh eyes and a good coffee i see now i was a bit lost.
What i need is to get term depth in the fields not in the filters!
ie: whenever i set a term as field i need the first parent to show up.
Looks like a similar patch is needed for fields?
Simone

I've made a module from agentrickard's patch which does not patch anything rather than just works by itself. Tested with Views 2.2 and 2.3 and it works as expected.

Enable just like a regular module. In Views under Filters > Taxonomy you will find a filter "Term ID (with depth)". Use at your own risk, though!

Thanks agentrickard, it was useful!

Happiness! I ll go and try it. At the moment i had to reduce the taxonomy to a single parent-child relationship and i was planning to use relationship to group all parents in 3 main groups
Thanks
Simone

Subscribing, greetings, Martijn

So which patch do I use (I see at least two separate ones here)? and is "with depth" what is added by this patch? Because that's what is missing at the moment. But we're on views 6.x-2.1.

Is "with depth" part of 2.2 or 2.3? I do not see it mentioned in the release notes for any release. Which version will which patch (above) work on?

I'm pretty sure this should be done with Arguments but I couldn't get it to work. Instead I installed agentrickard/majis module with Views 6.2.3 and it works a treat, thanks very much.

BTW I have two exposed filters:

Category 1
- Item 1
- Item 2
- Item 3

Catgeory 2
- Item 1
- Item 2
- Item 3

Selecting Cat 1 now shows all children items, before I had to select Item 1 to show it. Great job :o)

Is this patch going to be rolled into the next release?

Subscribing.

Just downloaded the module at #46. Completely awesome and so pleased I found this post. The functionality is pretty essential to filtering, otherwise nodes have to be multiple tagged - which is a really unworkable, long-term solution.
Seems to working just fine in D6.11 so hope that this module is incorporate into Views pretty swiftly. If that's not possible, this should be added as an official module in it's own right.

Sorry didn't read #52... now in DEV!!

subscribing

#55 I checked the dev release but it doesn't show the depth option yet. So it seems not available.

This is not yet committed - in #52 I was just putting the version correctly because the patch is for the dev branch, not a stable release.

I'm not a spambot but... you know, i want a make love with all of you :D

In particular merlin and maijs => module works perfectly !

You saved my life !!

module in #46 works wonderfully and is VERY helpful. Thanks!!!

My mistake about #55. Nothing new in Views DEV yet. I'm now using the taxonomy depth filter on all my exposed filters - not a single problem yet. #46 really works well

Would be great if this would be committed, greetings, Martijn

Still not in DEV :-(

Translation of Exposed Terms (and also exposed labels) with this plugin/patch can be done. Look at #337348: Localise views exposed forms and #360024: Write views localization plugin for patches.

I'm using the 6 2.5 and it seems to be working the same as the filter without the depth...

sorry about previous post i just reconfigured the filter again and now its working... i'm using the module from #46... thanks great job...

I have committed this to the 3.x branch (but not 2.x) as I am a little concerned with stability. Let's see how this plays out.

Hi, Still confused..is this in 6.2.6 because I see a filter "Taxonomie: Term ID (with depth)" in this version without using the module in #46?

EDIT: I think I am not confused anymore. This patch is in views 2.6 I think.

Greetings, Martijn

Yes this went into 2.6

I need to display a list of child terms from a parent given in argument, I can't do that.
It seems that this feature was implemented for Node Views only.

Would it be possible to extend it to the other types of Views (specifically Termsn which is the most relevant candidate!)

Hi, I want to build a taxonomy view that lists all root terms (not a node view). Am I missing something? The depth filter by term id is not available in 2.6 for this issue.

I think Earl meant version 3.x.
I use the module in #46.
One thing I note is that it turns the whole vocabulary tree into a flat list.
Still useable for me, as I am using a custom block with Hierachical Select API to build my exposed filter block, and I needed to be able to select the parent term.

delete

+1 to make te "Taxonomy: Term ID (with depth)" filter available for views based on taxonomy!

Hello,

I would also request a feature for the 6.x-3.x version of the views
to make the "Taxonomy: Term ID (with depth)" filter available for views based on cck-taxonomy fields in content types.

By the way,

the Taxonomy: Term ID (with depth) filter in Views 2.6 works well but
I have a problem with duplicates in the view if a node is tagged by more than one taxonomy terms.

For example:

Vocabulary:
Category 1
- Item 1
- Item 2
- Item 3

Node is tagged with:
Item 1; Item2

leads to a double listing in my view (only view filter: Taxonomy: Term ID (with depth) exposed).

The view shows the node as often as I have tag the node in this case two times.

View Basic settings "distinct" or/and Filter setting "Reduce duplicates" doesn`t solve my problem.
I need a view which showes only once a tagged node in the result list.

Thanks very much for any help.

Remark:
Problem solved, it was my mistake with the test-view. My problem was, I select as field to display:
Taxonomy: Term

I over read the explanation:
Taxonomy terms. Note that using this can cause duplicate nodes to appear in views; you must add filters to reduce the result set.
This was my error.

A other problem with the settings of the Filter: Taxonomy: Term ID (with depth) exposed

When I try to set the option "Limit list to selected items" to show only a subset of taxonomy-terms
to the user e.g. Item 1; Subitem A; Subitem B

from:
Category 1
- Item 1
-- Subitem A
-- Subitem B
- Item 2
- Item 3

I get a view-error "An illegal choice has been detected. Please contact the site administrator."
The select field of the view reduce the taxonomy terms to the selected amount, but the error
occur in preview and in the saved view by the first visit. But after selecting some terms in the view
it works fine but still with the error message and shows the tagged nodes.

Is it a bug or my incompetence to setup a propper view?

Thanks for any help.

Ok, I solve the problem. No Idea how, but it works.
Maybe I forget to empty the cash after setup the view or something was still in my browser cash.

Hi, Peter hijacked this thread.

This is still open:
+1 to make te "Taxonomy: Term ID (with depth)" filter available for views based on taxonomy!

Greetings, Martijn

This has already been committed and marked fixed. Anything beyond that needs a new issue. Further discussion here is pointless.

I'm very very sorry to join another post here, excuse me for that, but after a long research I haven't find what Summit and other people ask here: is the feature "Taxonomy: Term ID (with depth)" filter available for views based on taxonomy (and not only for views based on NODE) in working status somewhere?

I'm making some test with Drupal 7 using Views 7.x-3.x-dev and I can't see this feature available yet.

Thank you very much for any updated news someone can give me.

MXT

subscribe

+1 to make #85 available.

+1 for #85

wesley_2mpact, Summit, MXT, zeemp, suthy; Please open a new issue for your feature request. It will get not attention from maintainers in a closed issue, and it is a new feature request related to this one, but different. Thanks.

Looking also for either a workaround or a "Taxonomy: Term ID (with depth)" filter for views based on taxonomy; I believe the follow-up issue to this request by MXT (#85) is #955464: Missing join: 'taxonomy_term_data' creating a Glossary view based on taxonomy.

subscribing in the hopes of finding a solution to filter by depth in taxonomy views.

+1

This comment may help someone. Instead of trying to get the taxonomy depth going, I did a workaround where I added a second argument after the first one that handled things on a greater level. I made up a taxonomy called "region" which has [nations-states]->[regions]->[metro areas]->[cities].

Ergo:

Argument 1: is optional and pulls together any of a number of cities and regions. LA might be pulled together from four or five regions that might also be used elsewhere in various combos.

Argument 2: is optional and places in a "country-state" combo (this is how one selects the address, by "Nation" except for the US and Canada where it is by "Nation and State" - "Great Britain" vs "United States - Texas" or "Canada - Ontario".

The decision on my part to place the multi select regions as argument %1 and country-state as %2 was purely based on the fact that use of ONLY argument %1 will be much more common that use by argument %2.

Thus a URL might go like this:

"blah.com/regions/123" to limit it to a city, ("Austin", for instance.)

"blah.com/regions/123+234+345" to limit it to a pulled together region of several subregions ("Southern Cal" might include "San Diego", "Los Angeles", "San Fernando Valley", "Orange County", "Inland Empire", and some predefined subset of rural counties, for instance.)

"blah.com/regions/all/789" to limit it to a country-state, (all of "Texas" for instance.)

Works like a charm, considering I had to pump a View with arguments AND a pile of exposed filters through Panels, (oy, don't ask... the usual lack of documentation)

Rob

Hi @rfiertek, would love to see your view please?
Thanks a lot in advance for your reply.
Greetings, Martijn

what part of the view specifically? I am more than open to posting, but need to know what info you seek.

Rob

For those attempting to show only root level taxonomy terms, you can use a taxonomy view with a custom PHP filter that looks like this:

$parent = db_query("SELECT parent FROM {taxonomy_term_hierarchy} WHERE tid = :tid", array(':tid' => $data->tid))->fetchField();
if($parent == 0) {
return TRUE;
}
return FALSE;

This can be modified as shown on this page http://drupal.org/node/886526 to determine depth and return only terms of a particular depth. It's a bit of a hack, but it seems to work.

FYI, that is equivalent of

return !db_query("SELECT parent FROM {taxonomy_term_hierarchy} WHERE tid = :tid", array(':tid' => $data->tid))->fetchField();

.

@pinkonomy
i think i have done the same, but without a php filter.

1. use relationships to load the parent term "Taxonomy term: Parent term"
2. add a filter for term "Taxonomy term: Term" with selection type "autocomplete". then choose the parent loaded before as relationship. as operator select "Is empty (NULL)".
3. optional you could add a filter for a specific vocabulary

Thanks @kitikoni, that work-around worked for me.

Slight improvement on #99, no need for any relationship. Just add a normal filter on Taxonomy term: Parent term, and set the operator to "Is equal to", and in the Value field put "NULL".