Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
When a taxonomy reference field allows to select terms from more than one vocabulary, they are all merged into the same tree which can be really confusing.
Proposed resolution
Allow site builders to define how to handle multiple vocabularies:
- By merging terms in the same tree (current behavior and default one to preserve BC)
- By having all terms in the same tree but under a different root per vocabulary
- By having one different tree per vocabulary
Remaining tasks
Create a patch
Review
Commit
Enjoy :)
User interface changes
The widget has a different behavior given its settings.
A new field is exposed on the widget configuration form.
API changes
None.
Data model changes
A new setting appears on the widget.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | term_reference_tree-multiple_vocabularies-2960456-7.patch | 11.06 KB | mjmorley |
| #6 | term_reference_tree-multiple_vocabularies-2960456-6.patch | 11.01 KB | DuaelFr |
| #3 | trt_mult3.png | 9.54 KB | DuaelFr |
| #3 | trt_mult2.png | 8.43 KB | DuaelFr |
| #3 | trt_mult1.png | 5.87 KB | DuaelFr |
Issue fork term_reference_tree-2960456
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
DuaelFrI did a bunch of tests on my own but I'll definitely need more eyes on this one.
FYI, it's applying properly with #2837672-22: Allow to configure widget settings via composer.
Comment #3
DuaelFrHere are some screenshots!
Default behavior / "Merged" mode
"Tree root" mode
"Cloned" mode
Comment #4
texas-bronius CreditAttribution: texas-bronius commented@DuaelFr Your work is not falling on a deaf crowd! :D I confirm this works as described and in conjunction with #2837672-22: Allow to configure widget settings.
However, is this same issue the right place to also bring up Tree widget display config representing several Vocabularies?
Right now what I see looks something like:
Field Label
But what I am looking for is the option to see something like:
Field Label
I won't set out in this direction if it exists and I just don't see it or if it's buried in the issue queue somewhere else that I'm not seeing it. In either case, I believe it should be an option rather than a forced output. Unless it somehow automatically corresponds to the Form Config.. that might be intuitive and interesting..
Comment #5
nesstheheroThe patch in #2 works for me as well! However, it can't be applied automatically anymore, due to some minor code changes since it was created. I had to apply it manually.
This is a substantial improvement to taxonomy overall in Drupal, in my opinion. Currently I build content types that need multiple vocabularies with a reference field for each vocabulary, and with this change I would only need one field per content type, with the freedom to add or remove taxonomies easily in the future without code adjustments to any preprocessing. A client could conceivably create new Vocabularies in the future when needs arise and add them to existing taxonomy fields without ANY developer support!
I would love if this was rolled into this module officially. This is a gem of a change.
Comment #6
DuaelFrI've tried to reroll this on the latest dev.
I have no project to try it on right now so be careful :)
Comment #7
mjmorley CreditAttribution: mjmorley at Zoocha commentedI've updated the patch from #6 and it is now compatible with Drupal ^9.3.
This is a great addition to the module.
Thankfully not much code change was needed. The patch applied cleanly for me using composer, and from my testing seems to work well.
Info about the patch:
Built and tested with
Sadly the only automatic tests I see are for the 7.x-dev branch, so I won't run any on this patch.
Comment #8
tgauges CreditAttribution: tgauges commentedComment #10
tgauges CreditAttribution: tgauges commentedI applied this issue's patch to version 2.0.x of the project. Only one location needed a small adjustment.