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

solotandem’s picture

solotandem commented
Assigned: Unassigned » solotandem

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?

OneTwoTait’s picture

OneTwoTait commented

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

hefox’s picture

hefox commented

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). 

function 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();
}
solotandem’s picture

solotandem commented
Version: 7.x-1.x-dev » 6.x-1.x-dev
Status: Active » Fixed

Reassigning issue to 6.x branch -- see http://drupal.org/node/1203140.

The suggestion in #3 seems a reasonable approach.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.