The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.That is a surprising bug.
We have two different hs_taxonomy fields, attached to different entity types:
1) field_cat1 - attached to node of type "product"
2) field_cat2 - attached to profile2 of type "basic_profile"
both of these fields are working with the same vocabulary: vocab1.
Now, when I change "Enable the dropbox" on field_cat1 hs configuration, the dropbox is enabled on field_cat2, too!
That's a very weird behavior.
Also, on hs config listing page ( admin/config/content/hierarchical_select/configs )
I see only one "Configuration" instance:
http://pix.am/Eg7v/
if I go to hs_taxonomy.module, on line 693 I see:
$config_id = "taxonomy-$vocabulary->vid";
$config_info[$config_id] = array(...)
so, one instance of hs field will overwrite all other instances since $config_id will always be the same if you use the same vocab for these fields.
Is it working as designed? Am I misunderstanding something? We definitely need to disable dropbox in one field, and enable dropbox in the second field, even though it's the same vocabulary!
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | hs_taxonomy_settings-1442684-3.patch | 3.37 KB | leksat |
| #2 | hs_taxonomy_settings-1442684-2.patch | 1.55 KB | leksat |
Comments
Comment #1
xibun commented+1
Comment #2
leksat commentedIMO settings should be stored per fields instead of per taxonomy.
Attached patch changes the HS behavior and solves the problem. Please review it.
Comment #3
leksat commentedAttached improved patch.
Comment #4
ohthehugemanatee commentedConfirming the patch from #3 works perfectly for me on latest 7.x-3.x-dev branch. This is the functionality that is strongly implied by the Configurations tab in HS settings. Thank you guys, I thought I was going crazy!
Comment #5
seanbfuller commentedConfirming that #3 worked for me also. Existing settings will disappear, however, so it probably requires a hook_update to turn existing saved settings to the new value.
Comment #6
Caseledde commentedWorks for me on 7.x-3.0-alpha5. To avoid settings disappear an update hook would be nice.
Comment #7
RobKoberg commentedAlso confirming #3 works with the dev build.
Comment #8
goldAdd another confirmation for #3
Comment #9
wim leersThis is definitely not a major bug. It's possible we might want to change this, but this was definitely be design.
You say it doesn't make sense that different fields that use the same vocabulary all share the same settings. But, really, when you think about it purely logically, it doesn't make sense to apply different Hierarchical Select settings to the same vocabulary. The same vocabulary will typically always be used in the same way.
Only in edge cases does it make sense to implement what you ask for.
The fact that only a handful of people are replying to this issue, indicates already that this is an edge case. Hence I changed this to a minor feature request. I think it might make more sense for a separate module to offer the ability to have per-field HS settings for fields that use the same vocabulary.
Finally, I'm afraid this patch is not even remotely RTBC. For instance, there is no upgrade path.
Comment #10
wim leersBetter title.
Comment #11
websolutely commented#3 works for me with the dev build. I think, this is an important improvement to this great module.
Comment #12
skyredwangI disagree with this assumption
. It it not necessary.
An upgrade path would be needed for this patch.
Comment #13
daniele belitrandi commented#3 work fine on 7.x-3.0-alpha5.
I think it is very useful to have the ability to have different configuration for each field also if using the same vocabulary.
One example:
In a node type I create a Hierarchical Select wignet field and associate it to a vocabulary. In the configuration I set "Save Term lineage" because on views I need to filter with contextual filter the root term and the child term.
In another node type I create another Hierarchical Select wignet field and associate it with the same vocabulary. In the configuration I set "Save only the deepest term" because I want to call this field from view and get ONLY the deepest term.
In fact in views, when I call a field and select as Formatter "Hierarchical Term > just the selected term" I always get the root term AND the child term. I didn't find any way within views to get ONLY the deepest term of the Hierarchical field.
The only way I found to get the deepest term ONLY, is by setting "Save only the deepest term" in the Hierarchical Select wignet configuration.
Comment #14
richsky commentedMy two cents.
Typical example, Hierarchical Taxonomy for Geography. Say HS like Continent>Country>Location/Port/Whatever. The same taxo is used once to select a single country (and not anything else), the other time to select multiple locations, etc...
Because you don't want to create a taxonomy for continent, one for countries, one for port, location, natural reserves, hotels, bike shops, whatever.
Because same fields can behave in multiple content types (reducing the number of tables in the db).
For me these settings should be per content type, because same field uses same taxonomy and fields can be used in multiple content types.
Even more, the table summarizing the configuration displays the bundle is appearing in!
@Wim, creating a Facebook group for supporting this feature ; ) cause this is already a duplicate (3 years soon): https://drupal.org/node/1280994
Comment #15
richsky commentedhttps://drupal.org/node/1280994
Comment #17
garamani commentedThis patch solves the problem!