Mapper for Node Reference fields
pkej - March 2, 2008 - 13:25
| Project: | Feed Element Mapper |
| Version: | 6.x-1.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
It would be fantastic if it was possible to map incomming data to Node Reference fields. It is my only hurdle for importing a lot of data which I have customized into feeds from an export script I have.
The nodes are related, all the imported books are related to authors. First I import the author feeds, then I import the book feeds. The books should then use Node Reference to reference authors.
Using taxonmy for this might be possible by letting the Author nodes be sticky, but I would get a listing of all the books on the same page as the author, and not in the way I would like them; since I have views for the book listings already.

#1
+1 for this - I have a similar need. CCK Reference Fields are commonly used for most sites.
#2
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.
#3
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?
#4
I think that is the way it usually works. I'll give your patch a run around asap.
#5
I tried this yesterday, and I had problems getting it to work. I will try on a clean install tonight (I hope) and detail what I do on the website after registering the first account on the site.
I have high hopes for this functionality.
#6
Waiting for pkejs findings here before I test myself.
#7
These steps were performed on a Drupal 5.7 fresh installation.
That started up the initial modules; had to bump up the memory_limit of PHP to 16 MB at this point before continuing.
This should give me two content types where one should be able to reference the other. Now I needed to add an "Author" and a "Feed Story" just to see that I can reference an "Author" from the "Feed Story".
Now it is time to create the Feed
Next step is to create the mapping.
So, there it is. I am able to select the mapping for the feed, but the mapping never happens in reality.
To verify that it is the autonodereference at fault, I created a required text field called "Original Author" in the "Feed Story" node type. That field showed up after I deleted the old entries and refreshed the feed.
I also tried turning on Clean URLs, for some modules in the past it has been an issue wether it has been on or off.
Best regards,
Paul
#8
OK
I have misunderstood how it works.
I added an Author named "drupal.org - Community plumbing", and now it automatically appeared. I was under the impression from Comment #3 in this thread that the referred node would be created if it didn't exist.
Upon rereading with the knowledge of how it works I now understand that wmclark meant that the feed node was created regardless.
So, no problems, it works here.
Best regards,
Paul
#9
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.
#10
Subscribing, somewhat the same feature request asked here:http://drupal.org/node/241226#comment-792378, right?
If not sorry to interrupt.
Greetings,
Martijn
#11
Works here.
#12
subscribing
#13
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.
#14
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.
#15
Changing status as a response to #14
#16
Updated patch for 6.x-1.x-dev. I haven't been able to reproduce the problem from #14 in D6 with this patch.
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_....
Any hesitations for including this in 6.x?
#17
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
<?phpelse 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
<?phpelse 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;
}
?>
#18
Needs a patch.
#19
Here you go. This is my very first patch -- please be gentle. :-)
#20
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
#21
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.
#22
@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.
#23
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
#24
#25
+1
#26
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?
#27
subscribing
#28
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?
#29
@26:
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.