Mapper for Node Reference fields

+1 for this - I have a similar need. CCK Reference Fields are commonly used for most sites.

I went ahead and gave this a shot. It currently only handles the $feed_element as a string so nid's won't work in the patch I wrote. The string must match exactly to the referenced node title.

It seems to be working on my test site.

Please test and report.

Forgot to mark as "needs review".

Also, I wanted to mention that even if the field being mapped to is a required field, if no valid nodes are found, then the node is created anyway.

Is this a bug in FeedAPI not using the validate step of nodeapi or is this just something that isn't supported yet?

Waiting for pkejs findings here before I test myself.

Sorry for the confusion!

These are limitations because of other modules:

1. nodereference.module will not create new nodes if the title does not exist
2. FeedAPI Node does not validate fields before creating nodes. (So nodes might be created with invalid data)
3. FeedAPI Node does not allow you to moderate which feed items should be created as nodes. (Nodes with blank required fields can be created and published. Unwanted/Unrelated feed items can be created.)

I've created feature requests for some of these limitations.

Subscribing, somewhat the same feature request asked here:http://drupal.org/node/241226#comment-792378, right?
If not sorry to interrupt.

Greetings,
Martijn

subscribing

Thanks for this node reference mapper!

I am using the Node Reference Mapper in #2 with Feed Element Mapper 5.x.1.x-dev. The first time I run a feed refresh after creating (or after deleting all feed items), the mapper works flawlessly, but on each subsequent refresh (either manual or cron), new node references are not mapped to the feed items. The new feed items (nodes) are created correctly and other Feed Mapper Mapped items, CCK Date, and links, are mapped correctly, but the node reference is not mapped.

The node references that are not being mapped in subsequent refreshes are the same as those that were successfully mapped in the first refresh, so I don't suspect there there is a problem with invalid node reference data.

Any assistance would be greatly appreciated.

Update to #13

Upon closer examination, node reference mapper appears to work sporadically after the first refresh (which works 100% correctly). For instance, in a resent refresh 1 of the 4 new feed item's node reference values were mapped, the other three feed items were not mapped, even though the value to be mapped was mapped correctly in a previous refresh. I have checked the feed and all the data to map correctly is there.

Thanks again for any ideas.

Changing status as a response to #14

Updated patch for 6.x-1.x-dev. I haven't been able to reproduce the problem from #14 in D6 with this patch.

• The main change I made was to _nodereference_potential_references()
  D5: _nodereference_potential_references($field, $return_full_nodes = FALSE, $string = '', $exact_string = false)
  D6: _nodereference_potential_references($field, $string = '', $exact_string = FALSE)
  See http://api.freestylesystems.co.uk/api/function/_nodereference_potential_....
• The only other changes are comments, etc, to match feed_mapper_content.inc.

Any hesitations for including this in 6.x?

I just tested this patch and it didn't work for me. This may be because I'm using 6.x.-1.0-beta4, not 6.x-1.x-dev, but just in case it's helpful, I thought I would post my results.

However, it did work when I replaced the else if ($op == 'map') { section with the matching section from feedapi_mapper_content.inc, replacing $field[0]['value'] with $field[0]['nid'].

The original code from the patch

  else if ($op == 'map') {
      // Here is where the actual mapping happens.
      // When we are called at this point, $field_name contains the name of the field the user has 
      // decided to map to and $field_element is the feed item element the user has decided to map.
      // We just need to put the two things together. The data structure here depends a lot on
      // CCK. We stick the value in $feed_element into $node->$field_name[0]['value'].
      if (!is_array($feed_element)) {
        $cckfield = content_fields($field_name);
        // We are checking for nodes that exactly match the string mapped to $feed_element. We 
        // could have checked to see if it was numeric first and do something else
        $nids = _nodereference_potential_references($cckfield, $feed_element, TRUE);
        $field[0]['nid'] = (!empty($nids)) ? array_shift(array_keys($nids)) : 0;
        $node->$field_name = $field;
        return $node;
      }

The code that worked for me

else if ($op == 'map') {
      // Here is where the actual mapping happens.
      // When we are called at this point, $field_name contains the name of the field the user has
      // decided to map to and $field_element is the feed item element the user has decided to map.
      // We just need to put the two things together. The data structure here depends a lot on
      // CCK. We stick the value in $feed_element into $node->$field_name[0]['nid'].
      if (!is_array($feed_element)) {
        $field = isset($node->$field_name) ? $node->$field_name : array();
        $field[0]['nid'] = $feed_element;
        $node->$field_name = $field;
      }
      return $node;
    }

Needs a patch.

Here you go. This is my very first patch -- please be gentle. :-)

This does not work for me, I tried with node titles as the reference and not the nid's maybe that's the reason.

Using beta 7 patched version from no. 19

Patchak

The patch matches on nids, not titles. Since the title isn't necessarily unique, matching on title could open the door to a lot of potential mis-matches.

@jesss - I only see this now, but you've patched the patch in #19.

Can you roll a new patch that includes the entire mapper? Hint: You will need cvsdo for adding a new file to the module.

Well In my use case I have only use for titles, so I think that would be a choice for a user...

I reverted back to the original mapper for d6 in no.16 and that one works fine. I think we should offer a choice to use either titles or nid's for the mapping, since most clients would have titles and not nid's in their legacy data exports...

Patchak

+1

I can't understand interest to map to node id. How can a feed know your nodeid???

So i have take code from #2 and adapt with standards of 6.x-1.0. Now link is made with node title, if doesn't exist even if you have a autocreate, nothing happens (more sure, i think for miss orthographic problem).

So for me that's work, and for you?

subscribing

Hi there,

I tried the patch in #26, but it didn't work at all! I don't see a difference in the mapping-screen. Actually, this counts for all the patches in this thread.
What I noticed in the #26-patch is that the function it declares is "content_feedapi_mapper", but this function has already been declared in another file, so php throws an error (cannot redeclare function etc).

Are there any updates for this highly anticipated feature?

@26:
I can't understand interest to map to node id. How can a feed know your nodeid???
I'm writing my own eparser which can retrieve the correct related node id's throught the guids.

Say I have a first feed with authors:

<authors>
  <author id="1">name #1</author>
  <author id="2">name #2</author>
</authors>

I've written an eparser to turn those ids into guids for feedapi. Then I have a second feed with books:

<books>
  <book id="1">
    <name>book name</name>
    <authors>
      <author id="1"/>
   </authors>
  </book>
</book>

I've written a second eparser that can take the id from the author and fetch the corresponding nid from the feedapi_node_item table. In this case I need to be able to map the nid.

Had problems with some of the above inc files / patches. I hashed the attached patch together from using other examples in the folder. Works really well for me.

attached to this is original inc file which might be easier to use than the patch

I couldn't get #30 or #31 one to work with Feed Element Mapper 6.x-1.3, so I used them to write a mapper that does work, which I attach to this post.

Hi, would be great to move this also to feeds (www.drupal.org/project/feeds), while feedapi will move completely to feeds.
greetings, Martijn

#30 31 and 32 still don't work for me. Could you help?

I could try with #32, jcbou -- what's the problem?

Updated mapper for D6 syntax -- the previous mapper would match the first partial title match, not an exact match.

I have essentially the same need, importing news stories from RSS and creating a node reference in each story to the node of the journalist that wrote the story. But I'm trying to use Feeds instead of FeedAPI since it's the new hotness, also we have a need to import CSV data which Feeds also provides.

I created a Feeds importer that is attached to the journalist node type, which puts a field in each journalist node for the URL of an RSS feed of stories for that journalist. Perfect. I just want to add a node reference in each imported feed story that links to the journalist node that feed is attached to.

Any advice?

sorry if that question was offtopic, to somewhat answer it... it looks like there are patches to this effect, that are moving toward someday being included in the Feeds module, but for the short term maybe FeedAPI offers more options relevant to this specific task. Need to investigate both options further, patch Feeds or switch to (and possibly patch) FeedAPI...

http://drupal.org/node/724536
http://drupal.org/node/632920

"for the short term maybe FeedAPI offers more options relevant to this specific task."

Precisely why, while Feeds may be the "new hotness", I continue to use the "old and busted" FeedAPI for now :)

How to use this file?

patch 36 worked fine for me - with ~40,000 nodes and two references per node the import took ~2.5 days...