Nodereferrer for D7

IMHO the best is join forces with the Relation module to avoid duplicated efforts. To help the transition documentation on the migration path for both for existing data and developers/site builders who know NodeReferrer in D6 and want to some features in D7 will be needed. It may even be a good idea to start with this documentation to identify the missing features in Relation.

On the other hand, one of the best thing about NodeReferrer is that it can be used to provides backward reference for an existing node reference field (than may be defined by another module). That feature itself may be a justification for a D7 version of NodeReferrer.

I agree, joining forces is the best idea. The relation module is a complete rethink of relating two entities together with Drupal 7 in mind, which would be great. I'd be all for efforts being combined to make that a reality. Plus as of now only two people are working on the module, so they could use the help.

andypost,
Just wondering if you decided to join forces or port? Joining forces would be great as long as the relation project can put out a final product that can offer similar features to the node references and this project.

Relation kinda looks different and complicated. I would recommended porting.

For me, the key feature of 'NodeReferrer' is definitely the backlink functionality (as CCK fields, and in Views), so I'm mostly interested in preserving that functionality plus getting a migration path.

Technically, the Reverse Node Reference, Corresponding node references and BackReference modules are discussing the same issues, it might make sense to keep an eye on these issues as well: #788966: Drupal7 Port (BackReference); #989848: Module integrated to References D7 (Reverse Node Reference); CNR already has a 7.x-4.1 release, so obviously they decided to port.

A couple thoughts :
1. It is not yet fully clear that Relation can act as a drop-in replacement of noderef / userref. A D7 version of the functionality based on References (as opposed to Relation) would be still useful to many.
I don't think that a direct port would be too difficult (hum, famous last words...)

2. The alternative modules are not equivalent :
- "Reverse Node Reference" only provides reversed views relationships, which are now included in References D7
- "Backreference" project deprecates itself in favor of "Corresponding Node References", which has a D7 port.
- "Corresponding Node References" just keeps 2 noderef fields in sync (duplicating data). Unlike Nodeferrer, it doesn't allow a field to track references coming from several noderef fields. Nodereferrer, also provides a couple powerful views handlers (as I wrote above, the 'reverse relationship' is now included in References, though).
[edited: my initial post was phrased in a way that presented the "couple powerful views handlers" as provided by "Corresponding Node References" rather than "Nodereferrer"]

3. Now that References is its own project rather than "lost" in the whole CCK package, a D7 version of Nodereferrer would IMO be a very valid inclusion to the References pack.
- "IMO" only, because as the past couple months showed, the current maintainers of References (@fgm and myself) don't have the bandwidth to do a decent maintenance job. We'll probably be looking for other maintainers very soon, and including more features would be their call.
- including Nodereferrer in References possibly means extending the features to user_reference as well for consistency, which might be easy or not...

Slightly edited my #7, it had a typo which reversed the meaning of a sentence.

@andypost :
- "extending the features to user_reference". What I mean is :
Nodereferrers currently provide a feature around noderef fields - i.e, on node load, populate the node with a field containing a list of nodes that reference it.
References provides a noderef field and a userref field. If Nodereferrers was merged in Refeferences, it would be good to provide the functionnality on both, for consistency.

- regarding queries and Field D7 storage : I don't think things will be much different. In D7, you run an EntityFieldQuery to find all entities that reference the node in a given noderef field. That means one query per noderef field.

The main D7 difference a D7 port of Nodereferrer will face is the fact that referrers can be any entity type, not just nodes. So, the same way Nodereferrer D6 lets you track referrers of specific node types and/or referrers through specific noderef fields, a D7 version should be able to restrict by entity types & bundles.

Thks @andypost !

0) for consideration : do as References (nodereference, userreference -> node_reference, user_reference) and Field_group (fieldgroup -> field_group) did for D7 and adopt core convention of not smushing names together by renaming to node_referrer. I know :-/
6) when the code is settled (notably the structure and names of field and instances settings), implement content_migrate hooks to support D6->D7 migration :-)

subscribe

subscribe.

It looks like the References module has a reverse relation in Views now by itself, see http://drupal.org/node/1083902. That would actually make this module obsolete for D7.

@Cyberwolf: Is this reverse Referneces only provided to views or is it usable via an API?

@mongolito404: good point. I believe it's just for Views. I never used the field Nodereferrer provides and therefore forgot that it existed.

@mongolito404: You can query the Nodereferrer-Fields of the Node-Object. For instance, the Graphviz Noderef module (http://drupal.org/project/graphviz_noderef) does it.

Replaced the implementation of hook_nodeapi (which doesn't work anymore in D7) with the corresponding D7-hooks and got them working. (I urgently needed the cache-management). Here's the patch.

@andypost: I tried this. But with Field API you can only delete the whole field cache or nothing. But you can't delete selected cache entries.

The D7 module is really great and especially lightweight, so it would be great, if we could keep it. What do you think?

As little improvement I would suggest to add the following if-clause to line 500 in nodereferrer module so that the field is not being put out if it has no content:

if(!empty($rendered_nodes)){ // This line is news!
$result[$delta] = array(
'#theme' => 'item_list',
'#items' => $rendered_nodes,
);
}

I've already testes this, if you agree, we might create a patch?

+1 on #22 - we just found it today.

Patch would be this one attached, and yes it works.

HOWEVER - when looking at the devel dump of a node with no incoming referrers, I see some data that should not be there.

When the $node has no incoming links, the object still gets the following added to it

field_service_nextsteps (Array, 1 element)
  und (Array, 1 element)
    0 (Array, 4 elements)
      items (Array, 0 elements)
      limit (String, 1 characters ) 0
      element (String, 1 characters ) 0
      pager (String, 0 characters )

And so this fails the normal field empty() sort of checks. Even though the nodereferrer renderer filters it out before display, it would be better if when loading, the array was left completely null. If that was done, I think the normal "hide if empty" behavior of fields would have worked, and we wouldn't have to do this cleanup at the end here.

So the problem is at the node_load ( nodereferrer_field_load() ) phase?

More like this:

Yeah, a dev branch would be appreciated. I've got a job on where this has been used for the prototype, but as I'm doing module review, having it in this not-even-dev state was hard for me to sign off on.

Please remember to administer releases to show the 7.x-dev available on the proj page. (I always forget to do that myself and just do the git branch and walk away..)

Thanks @andypost ! - I'll re-download and start tracking that branch now.