Not sure if i'm being an idiot or if this is just not possible. Here's the scenario:

I have 2 node types: RESTAURANTS and OFFERS. I'm using this module to reference the OFFER from the RESTAURANT node. So when we create an offer, we select a restaurant to which it applies.

I have a view which lists OFFERS and via relationships in views I am able to access the info from the RESTAURANT which is referenced from the OFFER. So for example, the offer list can show the address of the restaurant to which it applies.

Now I want to do the reverse: create a view listing RESTAURANTS along with any and all OFFERS that are available there. Is this possible? Thanks.

#53 backreference-view.txt6.06 KBjnettik
#43 interdiff.txt2.51 KByched
#43 1083902-backreference-43.patch3.92 KByched
#34 1083902-backreference-34.patch3.29 KBderhasi
PASSED: [[SimpleTest]]: [MySQL] 14 pass(es).
[ View ]
#33 1083902-backreference-33.patch3.23 KBderhasi
PASSED: [[SimpleTest]]: [MySQL] 14 pass(es).
[ View ]
#17 1083902-backreference.patch3.18 KBdawehner
PASSED: [[SimpleTest]]: [MySQL] 12 pass(es).
[ View ]



This feature is not integrated with References but you can try a backrefrencing module, i.e.

Thanks man - that should do it.

It's surprisingly easy to get a list of referenced nodes in Drupal 7, compared to D6 CCK.

Say your field name is $field the resulting SQL string would be

'SELECT DISTINCT ' . $field . '_nid AS reference FROM {field_data_' . $field . '} WHERE ' . $field . '_nid IS NOT NULL'

If you only want references from a particular node then append:

' AND entity_id = :nid';

and pass through arguments: array(':nid' => $nid)

And with D7 Database API dynamic queries this query can be rewritten for easier maintenance.

Might be nice to have a function available in node_reference like node_reference_get_referenced($filters = NULL), where $filters is an optional array of filters. Check the database to see what filters you might be able to apply dynamically, such as entity id (nid), revision ids (node vid), bundle (node type), language, deleted, etc.... You could pass all that through with an array param.

Same goes for user reference.

Hope someone finds this useful.

There are different approaches that can be taken:

  • Automatically create a corresponding node reference, which is what both CNR and BackReference do but would work well as field options vs separate modules.
  • Provide Views integration and/or an API to list them, which is what NodeRelationships (and some others) do.

Would anyone not want to have these in the core module?


  • Add option to each reference field allowing field(s) on the opposite side to automatically create a corresponding back reference.
    • Add an option to control whether the back references are removed when one reference is created.
    • Add an option to control whether the back reference is created on a per node basis, thus covering for use cases where back references are not always necessary.
  • Entity edit forms (e.g. node edit) should identify at run-time what the current back reference status is and display it, rather than store additional logic & data to remember the above.
    • If the option is enabled to allow per-node control and the back reference does not exist, provide an option to create it.
    • If the option is enabled to allow per-node control and the back reference does exist, provide an option to remove it.

Wanted to get some quick input - do you think the "back referencing" capability will be added to References, or would be the way to go to achieve that? It's basically making sure that any users that are referenced on a certain page (school department in my case) show up on the user's profile. I really appreciate any input. Thanks!

To add - it almost seems like with CNR that you need to do double the work (reference both at first) it just automates the updating.

If #1043260: Reverse relationship gets committed you may find it relevant to your use case.

Cool - thanks for the link to that!


Would anyone not want to have these in the core module?

I definitely think this should be in the core module, if at all possible. I've always scratched my head when wondering why a second module is necessary to create return references. They should somehow be two-way by default (even if it's just some function I can call to get references for a given nid...).

The best solution would really be #1043260: Reverse relationship

Seriously, campaign for that if you want this.

I'm new to Drupal and I've tried many things to get this feature on D7. None worked for me.
Eventually I wrote my own block to display the list of links to referencing nodes. It's probably not the fanciest module ever, but it is good enough for me, so I give you the code as is:

name = Reverse Node Reference
description = Defines a block for displaying nodes referencing the node that display the block.
package = Fields
core = 7.x
dependencies[] = field
dependencies[] = references
dependencies[] = options
files[] = reverse_node_reference.module


* @file
* Implements a block listing nodes with a reference to the node displaying this block
* Implements hook_block_info()
function reverse_node_reference_block_info()
$blocks['reverse_reference_node'] = array (
'info' => t('Reverse reference Nodes'),
'status' => TRUE,
'region' => 'sidebar_first',
'weight' => 0,
'visibility' => 1,
* Implements hook_block_configure()
function reverse_node_reference_block_configure($delta) {
$form = array();
$delta) {
$form['reverse_reference_node_name'] = array(
'#type' => 'textfield',
'#title' => t('name of the referencing field'),
'#size' => 30,
'#description' =>t('Enter the name of the field referencing nodes'),
'#default_value' => variable_get('reverse_reference_node_name', ''),
* Implements hook_block_save()
function reverse_node_reference_block_save($delta = '', $edit = array()) {
$delta) {
variable_set('reverse_reference_node_name', $edit['reverse_reference_node_name']);
* Implements hook_block_view()
function reverse_node_reference_block_view ($delta = '') {
$delta) {
$node = menu_get_object(); // get the current node
if (isset($node))
$referencing_name = variable_get('reverse_reference_node_name');
                if (!empty(
$items = array();
$result = db_query("SELECT DISTINCT n.title, n.nid FROM {node} n, {field_data_" . $referencing_name . "} r WHERE r.entity_id = n.nid AND r." . $referencing_name . "_nid = " . $node->nid);
$result as $row)
$items[] = array('data' => l($row->title, 'node/' . $row->nid));
                    if (empty(
$items)) { //No content
$block['content'] = t('None.');
                    else {
//Pass data through theme function.
$block['content'] = theme('item_list', array('items' => $items));
$block['subject'] = t('Related nodes');
            if (isset (
$block)) {

It would be nice if such a code could be included with this module.

This patch to Views should make it easy to get the reverse relationship. It provides a new handler that can do the job. references.module just needs to implement the hook and add the reverse references to the proper tables ('node' and 'users').



I put it here because It s related :

It s a Computed Reverse Node Reference field (but without views 'cause I don't like views ;p)

Status:Active» Needs review
new3.18 KB
PASSED: [[SimpleTest]]: [MySQL] 12 pass(es).
[ View ]

Here is a patch for it.

This allows to backreference node and users.

Status:Needs review» Reviewed & tested by the community

This patch works brilliantly! Just a few notes, though, from the twenty minutes it took me to get it all going...

  1. You need to have at least Views 7.x-3.0-rc1 installed (or any -dev release past Jun-16), as #1188500-2: Provide a reverse taxonomy field relationship was committed to that branch.
  2. Be careful running update.php. I ran updatedb from drush, and it seemed to update Views appropriately. Additionally, you'll need to clear all caches twice before trying to use this new feature...
  3. If you were using something like #1043260: Reverse relationship in the past, you'll need to rework your view a bit. Get rid of the original reference, and add in a reference like "Content: Content using [reference type]." This will allow you to show all the nodes that reference a given node... (user reverse relationships are similar).

Great, awesome, and quick work, dereine! This is 1000x better than the other solution I was using. Please commit asap.

I applied #17 and followed the steps from #18 and can confirm that this works for Node references. I have not tested User references.

I did find it a little confusing that the default identifier is the name of the field from the node that refers to the other node. I have an artwork node that references an exhibition and an artist. I want to get all exhibitions an artist is involved with, and so I create a relationship to get "Content using Exhibition" (of type Artwork) where that Artwork has a particular Artist. The "Content using Exhibition" relationship is identified by "field_exhibition", which ordinarily would give me exhibitions, but since this is reversed it gives me artworks. I think the default identifier should make it clear that its a reference, some nice way of saying "Node that field_exhibition is referenced from".

Default identifiers probably should be shorter than that (they're going into a pretty small space) but something to indicate it's a reverse is probably a good idea.

I tried it with the latest patch and it works perfectly, thanks! + on committing it!

Are the following texts a better description?

@entity referencing @entity_name (using @field)
Relate each @entity that uses @field to relate to the node/user/term

Thinking of a clear, unobtrusive, way to present the two different relations is difficult. Maybe place a <- and -> before the relationship? Or just [reversed] before the reversed ones? A name that would push these reversed relationships to the bottom of the list would be nice I think. Now, at least in my drupal installation, the reversed references are the first relationships in the list.

Fantastic! Looking forward to testing this on my site. Subscribing.


subscribe. i tried the solution from #17 and it seems it works.

please commit to dev. version

subscribe: note to self reverse node reference.

After uploading patched files, I've got:

Fatal error: Cannot redeclare node_reference_field_views_data_views_data_alter() (previously declared in Z:\home\\www\emploi\sites\all\modules\references\node_reference\node_reference.module:1047) in Z:\home\\www\emploi\sites\all\modules\references\node_reference\node_reference.module on line 1126

any ideas?

Actually, seems I didn't do from #18:

If you were using something like #1043260: Reverse relationship in the past, you'll need to rework your view a bit. Get rid of the original reference, and add in a reference like "Content: Content using [reference type]." This will allow you to show all the nodes that reference a given node... (user reverse relationships are similar).

I will try to redo my views.

I've deleted all my custom views, but get:

Fatal error: Cannot redeclare user_reference_field_views_data_views_data_alter() (previously declared in Z:\home\\www\emploi\sites\all\modules\references\node_reference\node_reference.module:1075) in Z:\home\\www\emploi\sites\all\modules\references\user_reference\user_reference.module on line 908

That means one of the two modules has the same function name in it. Try completely deleting the references directory, downloading -dev again, and then repatching.

geerlingguy, thank you for quick reply, you were right, I had problems with patching, as I used NetBeans IDE and it applied patch not correctly, all the patch to every file: node_reference and user_reference.

Bumpity bump - could we get this into the next release? Been using it for TONS of views now (I have some complex relationship set up on my site), and it's worked perfectly. :-)

new3.23 KB
PASSED: [[SimpleTest]]: [MySQL] 14 pass(es).
[ View ]

Great patch, works for me!

The only thing I'd fix, are the title and help texts, so they show more information. I updated the patch for that, see below.

new3.29 KB
PASSED: [[SimpleTest]]: [MySQL] 14 pass(es).
[ View ]

Ähm, sorry, forgot the user_reference part ...

Patch from #17 working beautifully - thanks for sharing!

It does work for me..sort of...but I've got a problem with duplication of rows in my View table. Let me explain.

I have a content type 'Event' with a node reference field to add 'People' speaking at this event. Some people are speaking at more than one Event. What I am now trying to do is use the backreference patch above to create a People view table (name, photo etc) AND include the Events they are speaking at. In my preview View I get a duplicate row which repeats the person again but with each event. So someone speaking at 3 events has 3 rows of repeating info (apart from the vent column). I suppose I want the Event backreference to appear in the same column with a separator when there is more than one Event.

Incidentally when creating another relationship I notice the ability to set a 'Delta' value of 'All, 0,1' etc. The help text says "The delta allows you to select which item in a multiple value field to key the relationship off of. Select "1" to use the first item, "2" for the second item, and so on. If you select "All", each item in the field will create a new row, which may appear to cause duplicates".

The patch above does not include this 'Delta' option? Could this be why i have this duplicate problem.

@bib_boy - there are two things you could try doing. One is using the grouping field feature under the display type's settings. This would allow you to group records by a certain field (like "person"), and the you could hide the person field from display in its field settings.

The other way would be to try altering the query or changing some of the query settings in the advanced section of the views interface...

@geerlingguy thanks for ideas, i've now tried your suggestions but it's not really doing it for me. I think the relationship field needs to have a multiple field setting? OR the 'Delta' option in the relationship?

Is this ready to be committed? What does it need?


I Just recognized that we should provide the 'real field' for both "pseudo fields", so other modules, fields and relationships could use that information to extend the query.


Status:Reviewed & tested by the community» Fixed
new3.92 KB
new2.51 KB

Yay, many thanks @merlinofchaos & @dereine for the patch and the supporting feature in views.

Committed attached patch, after tweaking the relationship title and help text myself a bit - see interdiff with the original patch in #17.

@views folks : I realize this makes the title different from the pattern used in the similar back-relationships implemented in Views for image file, taxo. I do think it helps to keep the 'forward' and 'backward' relationships next to each other in the "add new". What do you think ? Would you consider a Views patch that does the same for the back-relationships in Views ?

Looks great, and makes the need for things like back referencing much less urgent! I think your new text clarifies what's going on very well.

@views folks : I realize this makes the title different from the pattern used in the similar back-relationships implemented in Views for image file, taxo. I do think it helps to keep the 'forward' and 'backward' relationships next to each other in the "add new". What do you think ? Would you consider a Views patch that does the same for the back-relationships in Views ?

It's seems to make somehow sense from the user point of view, because you know both sites of your relationship but most likely you aren't sure which is on the left and which is on the right.

Perhaps this would be not that easy to support because
a) They have not the same kind of title
b) They are grouped perhaps in different groups. For example if you have a node reference on users

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

really, really useful + simple to use -> thanks to everybody involved from views and reference ...

It seems this functionnality is not yet implemented in 2.0-beta3, or am i wrong?


No, its in the dev version - so it will be in the next release.

I cannot for the life of me get this to work. I've got the relationship added, but I still don't see the field I want. I've got a view of books and I want to add a field to each book of the excerpts that reference them. Where is that field? This is really screwing with my head! :-/

Here's the views code since d.o eats the whole post when I paste it here:

Status:Closed (fixed)» Active

Worse, adding the backreference to the relationship just gets me duplicates of my books. This is killing me - it's the whole reason I need this module.

new6.06 KB

I'm also having some trouble getting this set up. Basically I have a bunch of seminar nodes, each referencing a speaker node. When I go to the speaker's node, I want to see a list of seminars that reference that speaker. Right now I get all seminar nodes showing on every speaker's page.

I've attached the view, any pointers on what I'm missing would be greatly appreciated.

Status:Active» Closed (works as designed)

So I finally got it going. I needed a Contextual Filter for the node title. I was trying to go with NID and for some reason that wasn't working.

Status:Closed (works as designed)» Fixed

changing status back

Status:Fixed» Closed (fixed)

er, I mean back to this.

This is an old thread, but I am stuck...

We have NODE TYPE A and NODE TYPE B. A user creates a reference via a a field from NODE TYPE B to NODE TYPE A. We would like a block that attaches to NODE TYPE A that lists all of the NODE TYPE B references.

When we create contextual filters and relationships, nothing seems to take the cake. Any ideas?

Thanks in advance!