Right now you must have your vocabulary set to free-tag to have the taxonomy mapper to save new terms. I think this is a limitation because you can arrange terms in an hierarchy when using vocabularies of the free-tag type. So to solve this, the taxonomy mapper needs to be able to save new terms for non-free-tag vocabularies too! I think this is the behavior one expects from an import process like this.
The attached patch fixes this.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | 714424-7-save_new.patch | 5.28 KB | guillaumev |
| #3 | 714424-3-save_new.patch | 1.92 KB | alex_b |
| taxonomy_mapper_save_new.patch | 1.93 KB | dixon_ |
Comments
Comment #1
Monkey Master commentedThe problem: First item with new term has no terms at all after import. Solved by removing this:
$new_term['tid'] = db_last_insert_id('term_data', 'tid');taxonomy_save_term() already fills $new_term['tid'] with correct value. then db_last_insert_id() overwrites it with something strange in my case...
Comment #2
alex_b commenteddixon_ : you're right, import suggests that new items are being created if they're not present. If this collides with another use case we should add an option in the UI *if* someone complains, so your approach is fine.
#1 needs to be addressed.
Comment #3
alex_b commentedThis patch applies fix described in #1. dixon_ could you give me a review?
Comment #4
janusman commentedIs there some chance that this could be an option in the UI instead of hardcoding it one way or the other?
In my use case I actually prefer not to add terms to non-tag vocs (which is, BTW, the way Drupal behaves out of the box... if anything, that could be a design rule to follow: "when in doubt, follow core").
Comment #5
alex_b commented#4 Point taken. We could make this an option on the taxonomy form. Options on the mapping form will require some serious extension to the mapping UI. A shortcut could be to add a checkbox to the taxonomy vocabulary edit form. Not ideal.
Comment #6
alex_b commentedRe #4: NW
Comment #7
guillaumev commentedHi,
I created a patch which adds the option at the processor options form level (see FeedsNodeProcessor). It's still not as ideal as an option that would appear at the mapping level, but it will probably fit janusman and dixon's use cases.
Note that this issue can be seen along with issue 963534 (http://drupal.org/node/963534)
Comment #8
twistor commented