Imagine a content type containing a term reference field, and a simple vocabulary with a handful of terms. Using VBO you're able to create a term reference of multiple nodes to an existing term, always pointing at the same tid. That's correct so far, and works fine if the reference field is using the "select list" widget (or radio buttons).
If the content type is using the "autocomplete term" widget however, users are able to enter new (non-existant) terms for this operation. This results in the same term name added repeatedly to the vocabulary with different tids!
Example: existing terms are "apple" (tid 1) and "banana" (tid 2). Now let's modify 5 nodes using VBO and the nodes autocomplete term widget, entering "cherry" as new tag.
This results in the term name "cherry" added to the vocabulary 5 times with tids 3, 4, 5, 6, 7! I'd expect a check for existing term names, so "cherry" would be added only once to vocabulary, and added to all nodes with the same tid "3".
As said, this happens only with content types using the autocomplete widget, as it's not possible to add non-existant terms using other widgets.
Regards,
Boris
Comments
Comment #1
bojanz commentedWow, that's just stupid. Not sure if VBO can do anything to stop it, looks like core behavior, but I'll look into it.
Comment #2
bojanz commentedYep, this is core behavior.
The check for whether the term exists happens only on widget validate, which is once for all entities.
A solution would be to write a hook_taxonomy_term_presave() implementation that checks if the tag already exists in the database, if yes, assigns it the id and returns, which prevents an insert.
Comment #3
drubbThat's exactly what I did now. Here's the code:
Perhaps there should be some additional form handlers for the taxonomy administration forms, but I don't need them in my project.
Thx,
Boris
Comment #5
basvredelingReopened to discuss follow up.
First of all: thanks Boris and Bojan for supplying suggestions and code.
Since this is still a minor issue / nuisance I'd like to propose one of the follow 3 things as follow up:
I'd say option 1 is desirable, the other 2 not so much.
above code in comment #3 could be appended as views_bulk_operations_taxonomy_term_presave($term) in VBO itself.
Comment #6
Anonymous (not verified) commentedIs there any chance 7.x-dev would have a fix for this? I'm running into the exact same issue.
Comment #7
kingofsevens commented#3 solves the issue but requires a minor change because the above code gives Strict warning: Only variables should be passed by reference.. It is the $tid line.
Therefore the code should read:
Comment #8
dwhutton commentedThis fix is exactly what I need, but I don't have enough expertise to know how to apply it. Is this code added to an existing file within VBO? How does this function get invoked?
I'd welcome some help.
Comment #9
kingofsevens commenteddwhutton, for now, you can get the above code add paste at the end of the views_bulk_operations.module file. Remember not to include the <? php and ?> tags when pasting. Change the MODULE_NAME part to views_bulk_operations. The first line should read:
function views_bulk_operations_taxonomy_term_presave($term) {You can use this until it is patched in VBO or in taxonomy.
Comment #10
dwhutton commentedThank you jack in the box for the guidance: this worked perfectly to resolve the problem described here.
I have a similar but not identical problem, described in another thread http://drupal.org/node/1812794 in which VBO operations result in nodes having multiple identical taxonomy terms assigned. I've had no replies, although I'd expect users who have encountered the issue in this thread to also encounter the other issue. Just curious. Perhaps I've not described the other issue clearly enough.
Comment #11
zmove commentedSolution #7 corrected the issue.
Can be commited ASAP to avoid to hack module core or create another submodule to correct that bug.
Comment #12
joshuabud commentedThis issue is still present in the latest stable release for Drupal 7.
Comment #13
brennino commentedIf you don't know how to create a new module or don't want to hack core or apply patches, i solved this issue by installing this module:Taxonomy single tagThis module is used for create or select only one taxonomy term item in a similar way to the autocomplete widget but it seems to make the right checks for the term existence.Simply use the new widget the module create instead of the core one. You can change the widget "runtime" also with field already written with data.I need this for drupal commerce and I need to select only one term.If you need to select or create multiple terms with a term reference field, maybe this other module can help you (not tested):
Content taxonomySorry, after tests I see this method doesn't work. It seems that when I edit term references in product variations with drupal commerce using the module "inline entity form", the new terms are not created until I press "save" for the whole content. If the term is new and you put it for different variation of the product it will create multiple equal terms.
Probably you have to create a custom module as stated in previous comments
Marco - Brennino
Comment #14
joelpittetThere is no patch on this issue, setting back to Active until a patch is created. Also, looks like brennino is having issues with it in #13.
Comment #15
abaier commentedI just found this issue while researching the duplicate terms behavior. This really seems to be a core issue while saving the new, non-existent terms that were added in the autocomplete (tagging) field. Also in D8.
Today, with the expanding use of paragraphs or media entities, sometimes using inline entity form or others, the possibility of having more than one instance of a taxonomy field pointing to the same vocabulary is really high. For example if you place a multi-value paragraphs field including a tags field in a node and fill in two times the same, new term, it will be created twice with different term ids.
How could we make the core team aware of this situation? I already posted this to some other issues … Thanks in advance!
Added this somehow related issue:
https://www.drupal.org/node/1343822