It would be great if the terms selection would reflect their hierarchy, for example let's say that I got a parent term (it's parent value = 0) named "US" and I got 3 other terms which are it's sons "Texas", "California" and "New York", I would like to see their display as something like:

US
- Texas
- California
- New York

Instead of the current display:
US
Texas
California
New York

Thanks!

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

attheshow’s picture

Status: Active » Closed (won't fix)

I'm not personally concerned with this, but please feel free to post a patch if you get it working yourself.

jdleonard’s picture

Version: 6.x-1.3 » 6.x-1.x-dev
Status: Closed (won't fix) » Active

I'd really like this functionality as well. I'll try to work on a patch in the next 2 weeks, but I don't have a lot of time. If I don't come up with anything by June 15, 2009, feel free to change the status. Also, if anyone else can come up with a patch, I'd be happy to test/debug it.

attheshow’s picture

Status: Active » Closed (won't fix)
Francewhoa’s picture

+1 for this feature

benone’s picture

If hierarchical option cant be added, is it possble to order terms alphabetically ?

It could be faster to find term if hierachy would be enabled, but if not, alphabetic order is the 2 not bad possibility.

What do you think ?

B.

xjm’s picture

Assigned: Unassigned » xjm
Status: Closed (won't fix) » Active

I assume folks mean with the Content Taxonomy module. I need this feature as well. I will try to come up with a patch based on the option that the normal Content Taxonomy widget provides.

xjm’s picture

Here's the bit that does this in the Content Taxonomy module:

  if (is_array($tree)) {
    foreach ($tree as $term) {
      _content_taxonomy_localize_term($term);
      if ($field['widget']['show_depth']) {
        $value = str_repeat(' - ', $term->depth) . $term->name;
      }
      else {
	$value = $term->name;
      }
      //do a check_plain except for selects because form api does that          
      $options[$term->tid] = ($field['widget']['type'] == 'content_taxonomy_select') ? $value : check_plain($value);
    }
  }
xjm’s picture

Actually, it looks like all that needs to be done is to implement hook_widget_settings() and content taxonomy module takes care of this by itself! The problem so far is detecting whether the field is actually a content taxonomy field or not, as this information doesn't seem to be passed to the hook.

xjm’s picture

I'm beginning to think this might be best patched in Content Taxonomy, not in Multiselect. Discussion open on g.d.o:
http://groups.drupal.org/node/57033

If you don't care about a meaningless settings fieldset showing up on your multiselect fields that aren't content taxonomy fields, you can patch multiselect.module to add the following function and the indentation will work just as it does for the normal Content Taxonomy select field:

/**                                                                                                                                                  
 * Implementation of hook_widget_settings().
 */
function multiselect_widget_settings($op, $widget) {
  switch ($op) {
    case 'form':
      $form['settings'] = array(
        '#type' => 'fieldset',
        '#title' => t('Settings for Options'),
        '#collapsible' => TRUE,
        '#weight' => 10,
      );
      $form['settings']['show_depth'] = array(
        '#type' => 'checkbox',
        '#title' => t('Indent child terms with \' - \' signs'),
        '#default_value' => is_numeric($widget['show_depth']) ? $widget['show_depth'] : 1,
        '#description' => t('If this option is checked, a hierarchy gets visualized by indenting child terms, otherwise it\'s a flat list'),
      );
      return $form;

    case 'save':
      return array('show_depth');
  }
}

The terms will be out of order after moving them to or from the selected list, and so the hierarchy is only valid when the page first loads (see #417328: Sorting, #421938: Preserve selection order), but it seems to work.

attheshow’s picture

Status: Active » Closed (won't fix)

Please don't reopen this issue unless posting a patch that needs review.

AaronBauman’s picture

Status: Closed (won't fix) » Needs review
FileSize
1.25 KB

comment #9 works for me.
here's the patch

xjm’s picture

Assigned: xjm » Unassigned
davidseth’s picture

Status: Needs review » Reviewed & tested by the community

Patch at #11 works great. Please commit, thanks.

alexweber’s picture

Status: Reviewed & tested by the community » Fixed

Thanks guys! Committed in e280324.

Status: Fixed » Closed (fixed)

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