Posted by taite11 on June 1, 2009 at 10:16pm
Jump to:
| Project: | Taxonomy Filter |
| Version: | 6.x-1.x-dev |
| Component: | Miscellaneous |
| Category: | feature request |
| Priority: | normal |
| Assigned: | solotandem |
| Status: | closed (fixed) |
Issue Summary
There will be some cases in which a term is useful to have in the system, but should not be shown in the menu(s) generatred by Taxonomy Filter.
Example Scenarios
A - There are many many terms and it would be useful to remove some from the list to keep the list size down.
B - There are terms that are useful for creating search landing pages but not useful for navigation. These terms are likely quite similar so using them for navigational reasons is redundant.
C - Parent terms should not be on the list.
Comments
#1
This is similar to #451742: Allow for only showing tags that have a minimum number of nodes in the sense of limiting terms displayed in the filter menu.
What settings would you suggest for implementing this? A comma-separated list by vocabulary of terms to not display?
The display of parent terms should depend on the menu template involved. For example, I would not expect parent terms with the base or cloud menus. Do you agree?
#2
Yes, it's a similar usage as that issue for some cases. Rather than being automatic, it's manual - more flexible but more to manage.
For settings, a comma-separated list would work, yes.
I wouldn't expect parent terms for the cloud menu. For the base menu, I could see how some people would want no parent terms and how others might want it organized like:
parent1
- child
- child
parent2
- child
- child
#3
Terms can currently be excluded via a module via section alter
Here is an example, that as far as I can tell is working, and removes the term that equals arg(2).
<?phpfunction modulename_tf_section_alter(&$section, $info) {
$tid = arg(2);
foreach($section['items'] as $key => $item) {
if ($tid == $item['info']['item_tid']) {
unset($section['items'][$key]);
}
}
if (empty($section['items'])) $section = array();
}
?>
#4
Reassigning issue to 6.x branch -- see http://drupal.org/node/1203140.
The suggestion in #3 seems a reasonable approach.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.