Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I've created a patch that will not bombard users that have more than 100 terms in a given vocabulary. It'll change the form field on the right hand side to be an auto complete field instead of a potentially very, very large list of term data.
The only tricky part was the auto complete. I had to change it so that it would grep the string coming in from the form state. If it's an empty array then use the default string otherwise use the pregmatched item. There is a better way which would be to store whether or not it's an autocomplete field in the form and use that in the IF check but this works just as fine.
Screenshot and patch is included.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | widget-for-term-trunk-1509898-1.patch | 17.97 KB | bucefal91 |
| #2 | 7.x-2.0-beta2-term_merge.patch | 6.22 KB | avillanueva-npr |
| screenshot.png | 106.4 KB | avillanueva-npr | |
| term_merge-autocomplete.patch | 5.12 KB | avillanueva-npr |
Comments
Comment #1
avillanueva-npr commentedIn testing this and other things on my local I've noticed that it doesn't work because the $tid isn't saved in the form_state with all the rest of the data to go into the confirmation form. So that needs to be settled. I'll take care of that later today and repost the patch.
Comment #2
avillanueva-npr commentedStill sort of afraid to do the patch commits so I'm just going to put the patch up here.
Comment #3
bucefal91 commentedGuys, sorry, I have rewritten the module from scratch. Before I saw this issue. I like your idea, especially that if the amount of terms is less than 100 you keep select, otherwise you throw in autocomplete.
One suggestion to make it even more user friendly: you hard core either select or autocomplete, leaving out the user without options. Select widget has one good advantage -- it lets you see the hierarchy inside of your vocabulary, and sometimes it may over weight the advantages of autocomplete. So, I suggest to put a checkbox/radio buttons letting the user choose between select/autocomplete widgets, while the default for the widget will be defined as it is in your patch (if it's over 100 by default render form with autocomplete, otherwise with select). I think this way the interface will still be flexible and good out-of-the-box, but we will let the person make final decision whether he/she wants select or autocomplete.
Because of the code rewrite this patch is not going to apply cleanly. But don't worry, hopefully this or next week I will implement this feature on my own (if anyone hasn't provided a new patch yet).
By the way, you are welcome to check out the newest version of this module, which can be found at 7.x-1.x-dev. I tend to believe that it's bugfree (or quite close to no bugs).
Comment #4
bucefal91 commentedChanging the branch to be against the latest code.
Comment #5
bucefal91 commentedLet's see, guys. Here I provide a patch, that enhances even further your idea. At the beginning I didn't see so much improvement in this feature, but now it seems indeed to contribute enough to the module. I know the issue is half dead. If no one replies in a week, I will commit this patch into dev.
By the way, since introducing widgets to the module's UI, maybe I should make either select or autocomplete for term branches too?
Comment #6
bucefal91 commentedI have merged this patch into the dev branch.