Taxonomy mapper options: term name +tid, term name, tid, guid (avoids mapping error for Numeric taxonomy term, too)

as temporary solution comment out code in mappers/taxonomy.inc: 92:

    elseif (is_numeric($term)) {
      $tid = $term;
    }

I confirm the above works. My question would be is it possible to dynamically do this with all the fields of a given taxonomy so that all fields for the term are exposed to be mapped to (image etc) ?

Subscribe

Thanks for the suggestion johnv but no, not really what im after. I know that its possible to import to taxonomy and then import to nodes referencing those terms (with d7 this means that you can then have a wealth of fields in the term etc). But what I was after is skipping the importing to the taxonomy part first and doing straight off the node import. At present the taxonomy field of the node is exposed to be imported into (and this patch allows for term name or term id) but not the other associated fields.

subscribing

Subscribing,
I was wondering what went wrong, trying for hours then found this issue.
#1 worked for me!
Would be great if solution would be committed please.
greetings, Martijn

Hi all,

Stumbled upon this thread when faced with a similar problem today. Some of the term names in one of my vocabularies are numeric ie. 004 - which during import, are being assumed related to term id rather than term name care of this condition ---- elseif (is_numeric($term)) { $tid = $term; }

I'm aware I could use the term id in my csv, but what if my client is using this csv for updates and only knows the term names..? (would rather not confuse them as well) Do I have any other options apart from kitten killing..?

Apologies if you think this tangent isn't related, seemed to be a scenario that I thought more than just myself would face..?

Thanks for your time.

**Edit**

Seems my trail of rookiness left on the threads of Drupal has now grown larger...

Applied patch #2 and my import of numeric taxonomy terms worked flawlessly. (with no need of knowing the term id obviously).

Note to self - read each comment more thoroughly. Thanks johnv, much appreciated.

subscribe, #2 work for me
Thank You

I export the #2 in patch.
Please review

I'm assuming this will not work for 6.x versions? If not, would it be too much work to port over?

Thanks for the tip, I looked at it and it seems easy but after I figured out my original problem so I don't need to use the ID # anymore.

had same issue. Glad I saw this post

I comment out code in mappers/taxonomy.inc: 92:

<?php
    elseif (is_numeric($term)) {
      $tid = $term;
    }
?>

but if the number is zero (0) it didn't get imported

This patch is working great and together with the term_hierarchy extension to feeds tamper I can now import hierarchy straight into nodes. Nice!

Scrap my last comment, there are still some issues with importing hierarchy if having to use this patch.

there was a littel error in the #2 code (second callback function should be:'callback' => 'taxonomy_feeds_set_target_tid') and the patch #14 didn't apply for me.
So I found my fixes.
The final taxonomy.inc that works for me is here attached. I guess should be implemented in the module core ... as it's yet.

Basing on #23 I've made a patch to add term mapping by it's GUID. This requires taxonomy terms to be imported by Feeds with GUID assigned to them.

@johnv you're right. Here's the patch combined from #23 and #24.

Patch from #26 works for me!

Patch #26 worked for me as well. Thanks!

#26 works! thanks!

#26 patch is applied on dev version perfectly!

I have last dev version and it failed too. Anyway, it can be applied manually.

#26 : $target = str_replace(':guid', '', $target); should be at the beginning of the function, no? So that field_info_field() works.

When this fix gets committed?

#32 This might be true :) and checking for ":tid" in the $target should be added as well.

cool work, but needs work so...

This should use the new configuration api for mappers, rather than declare a bunch of targets.
Also, the current mapping behavior should be left alone and deprecated.

For references see:
#1588938: Allow selection of filter for each text field imported
#1697150: Add separator to floats and decimals.

As a temporary fix against the latest dev:
In mappers/taxonomy.inc Line 91

elseif (is_numeric($term)) {
      /* Temporary fix. Prevents numeric term names from being made a tid.
       * $tid = $term;
       */
      $tid = taxonomy_term_check_term($term, $vocabulary->vid);
}

#36 twistor can you please explain a bit more? I checked refereced issues/patches but unfortunately this doesn't tell me much.

Here is my variant. It adds some options using new configuration api for mappers:
-Term name or ID (old behaviour with is_numeric($term))
-Term name (call taxonomy_term_check_term(), may create terms)
-Term ID (just use $term as tid without additional checks or term creation)
-GUID (use taxonomy_term_lookup_term_by_guid() by philipz, just search, do not create terms)

I tested only GUID variant for importing commerce taxonomy and products from XML via feeds_xpathparser. The patch from #1825682: Notice error correction was used too.

This string from philipz's patch was a mystery for me:
$target = str_replace(':guid', '', $target);
But somehow it works :)

Twistor, please be more specific about "current mapping behavior should be left alone and deprecated", the GUID taxonomy matching feature is absolutely needed for some of our current projects and I might work more on this.

I guess we need new title :)

We might also need to add a key to guid column of feeds_item table.

Ok, #39 gets most of the way there. There are some copy/replace errors. This also needs tests.

I'm going to wrap this up tonight.

Alright, here's a go at this.

Thanks to everyone for getting this started.

Arg, here's the code.

Consistent function naming.

Update:

This changes the existing behavior. I am contradicting myself from above, but after some consideration I don't think many people were using map by tid, and this is still technically an alpha project, so better to just cut loose. This will still be compatible with the vast majority of existing installations.

Tagging

It would work for me. Autocreate option is good!

Found a typo in taxonomy_feeds_set_target() -- $cace vs $cache.

Fixed typo, tested with GUID option -- works for me, thanks!

Subscribe

Related patch to Commerce Feeds #1840198: Add mapping by product GUID.
It has some code from here: select by feeds_item.guid too.

Subscribe

Hi there,

I'm having the same issue and I didn't find the issue until I wrote a patch for it. My patch is way less complex and only changes a few lines instead of changing all the functionality of the mapper. What I did is changing the mapper. Before checkinf if it's numeric or a string, I check if the term exists. If so, I import it, if not, I check if it's a number or a string to do the current mapping.

The patch should work and the people will not need to select if they are importing term Data or term ID. But they will have a problem importing Term IDs if they also have taxonomy terms with numeric data.

I will leave my patch here just in case someone thinks it's useful.

Regards,
David.

Patch in #51 works beautifully. Marking RTBC to indicate it's been reviewed. :-)

Can I make a suggestion from the UI / UX perspective. I think like how some items have a "target configuration", terms should have options for:

• Match Term ID's
• Match Term names
• Try Match Both

EDIT: ignore didnt look at latest patches

@Johnv, no ofense taken. I don't like my solution either, I leave it here because it's a quickly solution that can work for some people. At the end, my solution was to use a list field with all the options.

Added tests. Committed to 7.x-2.x. Thanks everybody.

Here's a minimal / hackish patch to 6.x-1.x that just does a lookup on tid if the passed value is numeric.

I actually wanted to implement the patch as in #56, but then stumbled: Is it possible to implement configuration per mapping target in 6.x? There seems to be no form callback.

I think I am having a related, but slightly different, issue importing taxonomy terms.

I am using feeds tamper to concatenate two fields (street name and street suffix, ie: 'Main' and 'St') and then save them as taxonomy terms (adding new terms if they do not exist)

The reason I think my issue is related is that when the street name is all letters, ie: Main St, it works perfectly. Hoewever, when the street name contains numbers, ie: 30th St, it adds a new term even if it already exists. So after importing about 15,000 content items, I had several thousand duplicate taxonomy terms, all with 'number' street names.

When I attempted to apply the patch above in #56 it appears the patch has already been applied. I am using Feeds 7.x-2.0-alpha8 and Feeds Tamper 7.x-1.0-beta4.

I have decided to not create taxonomy terms from imported street names, which makes things like making menus from taxonomy terms more difficult, but at least it is working. I wanted to submit this as a FYI as I think there is still an issue regarding importing taxonomy terms with numbers, with the patch above applied. Or perhaps this is a Feeds Tamper issue...

Now I am having a similar issue without the use of taxonomy terms.

I am simply trying to use a contextual filter to query my views blocks via the url. When the filter value starts with a letter, it works. But when it starts with a number, it returns no content.

ie: Main St --- good!
7th St --- bad!

Any ideas why this would be? The data was originally imported with feeds into a text field.

I am really stumped so any help is greatly appreciated. Thanks.

Scratch the previous post. My problem is that for some reason the streets that start with a number have three spaces in front of it. When I add the spaces to the url, it works. Still not sure where spaces came from....

Please everrrrybody do NOT hijack this issue, but post a new one.
Status of this:
* Committed to 7.x in #59
* 6.x patch for review in #60

EDIT: erroneous comment.

Sorry for the noise.

Crosslinking #2139229: Taxonomy mapper creates empty and untrimmed terms which might be of interest for folks here.