Preserve existing terms

I completely agree. The way it is, you are forced to create the node first which cuts the usefulness of the module down by an order of magnitude. The perfect solution would be to have an option for the the vocabulary that said something like:

If term name already exists in this vocabulary:
[ ] Use existing term
[ ] Replace existing term with new term
[ ] Create a new duplicate term with same name (i.e., new term will have different term id)

Subscribing.

Totally agree.

We are rebuilding an old site using drupal about retrogaming. Every game has a term in the 'developer' vocabulary. So, we first needed to have all the developer companies as terms. We imported them from a csv file.

Now we are using NAT to write information about new companies. Every time we want to create information for a company we've already as a term, the term name gets duplicated. And if we delete de old one... we lost the information in all the games that had that term.

The options Zach Harkey give at #2 will be perfect.

Kind regards and thanks/congratulations for this great module.

It will certainly be a handy optional feature and patches are welcome. There are, however, a few impediments such as case sensitivity, deletions etc. that will need to be cleanly handled.

I would also prefer to see just a single toggle to handle this - something along the lines of "Reuse existing terms".

-K

To #2, Zach Harkey:

I can't imagine why someone would like to have two different terms with the same name. Anyway, since it's the way the module is working right now, maybe it'll be handy for compatibility purposes.

To #4, Zen:

A single selection list could be enough:

• ...always create new term
• ...reuse existing terms (case sensitive)
• ...reuse existing terms (case insensitive)
• ...fuzzy mode

I'd introduce "fuzzy mode" because it'll be helpful for my site about retrogaming. We would use NAT videogame developer companies, sometimes people write "Capcom" and others "Capcom co." (for example). It would be great if you get some kind of advise just after you send your node telling you it exists a very similar term in the database. I've seen a similar feature with CCK node relationship where you start writing the name of the node and a box showing matching nodes appears.

Kind regards.

Apparently my patch is a duplicate of this thread: http://drupal.org/node/375395

Wouldn't take much to add a variable_get to make it optional.

Just ran into this problem. This feature request will be very useful.
Regarding "fuzzy mode" in #5, maybe http://drupal.org/project/unitag would suit your needs.

Not sure if I did something wrong or not, but the patch in http://drupal.org/node/375395#comment-1262925 doesn't seem to work for me in D6.

Adding patch from #6 to this queue where it really belongs.

I tested the patch. It does not work for me.

Edit: Actually I tested with 2 different terms:
Orange vs orange.

It would be nice to be able to turn case sensitivity off.

You're right, the patch does not work at all.
(I don't know how it has ever worked. The patch should not create a new term, but should create a 'node-term association' from the node to the existing link. But the line "return array();" in the patch implies that no association is created at all.)

Here's a new patch.

I renamed the property "Reuse existing terms" because I wanted a property that is 'off' by default, for backward compatibility purposes. Now you can apply the patch and the behavior of the module will not change, unless you explicitly set the option.

I did not add an option for case sensitivity. Matching is always done case insensitive, because taxonomy_get_term_by_name() itself is case insensitive.
I also don't know how "replace existing term with new term" (in #2) would be different from 'reuse existing term'.
And the 'fuzzy matching' (in #5) is really a new functionality request, which is better handled separately from this issue.

So it's just an on-off option.

There was way too much 'noise' in that patch #12.

I redid it. It now resembles #9 again (except it actually works :p)

(Some of the 'noise' has been split out into #982660: Extra info for 'point to associated node' setting in admin screen

Patch from #13 works well for me. Many thanks.

I exported my terms with a csv file created with the views_bonus module, then imported with node_import, using this patch.

Perfect. Works like a charm.

This is exactly the case I'm trying to work through.
The patch in #13 works great for me and is a great improvement to NAT. Thank you roderik and psynaptic for your work!

Additional thoughts...

1. The existing term's hierarchy is destroyed during this create process.
2. The same outcome might be better served by "converting an existing term" into a NAT node relationship. That would remove matching concerns.
3. This approach still leaves the problem when the taxonomy term is selected for the node type.
   But maybe that's another issue? #155411: Can the associated node be assigned the taxonomy term?

When using this patch and creating a new node AND selecting the existing term to tag the new node (with the vocab enabled and required on the node type) I get a timeout WOD. The node is created, but it's in some weird corrupt state that doesn't let it me viewed or edited, luckily it can be deleted :) Makes the CPU run away crazy with like 80% usage on my laptop.

Darn. Looks like this patch also make it so you can't even tag nodes with the terms at all during an edit action.
So when that it needed this patch breaks NAT.

Believe this may be because: the default action for NAT (when tagging a new node with the vocab it's going into) is to place the term hierarchically below the term chosen. BUT then when this patch tries to link the new node to an existing term, which can't be below itself... which turns into a processer black hole.