Very often we needs to do the two-way referrence, so if one source node is referring to other target node, target node must have field with back referrence.
At now we can get the back referrence via views filter, but via this way we can't edit this field in target node, only in source.


Murz’s picture

As I see, we can solve this via different ways:
1. Create the hook that syncs field data in two nodes, as done in ref_field_sync module.
2. Use one separated storage table for those fields (2 columns - source nid, target nid).
3. Create new field type for target nodes, that will show backreferrences only, and allow user to change them in target node edit form.

Damien Tournoud’s picture

Status: Active » Postponed (maintainer needs more info)

Hi there. I'm not very comfortable with this feature request. It has been suggested a couple of times before (#1267884: Synced field instances (aka cnr), and a lot more and #1280752: Please add two-way relations), so it's obviously a popular feature request, but I'm not sure I completely understand the need, and I'm not sure it actually fit within the Entity Reference model.

I see it this way:

  • If the reference you are trying to implement is perfectly symmetric (like a bunch of related nodes, etc.), you should use Relation. Entity Reference is for directed references only.
  • Else, what you want is actually a view of the backreferences displayed on the target entity. You can attach it there using EVA or similar modules.

This doesn't solve the "editing back-references" feature you mention. How common is this type of requirement?

Let's discuss further.

Murz’s picture

For example, I have products catalog with categories, "products group" and "product" nodes.
"product" can be attached to one "product group", but "products group" can have multiple links to "product" nodes.

So, for catalog managers I must give in "products group" node editing form ability to select products in group (list of all products), and in "products" node edit form I must give ability for select "product group" link.

And for do this, I must have the two-way link, that I can edit in each direction.

Relation module is near, but didn't give needed functional (selectlist in node edit form) and have too much unnecessary functional.

Murz’s picture

You can look how this work in ref_field_sync module, that I use now for those needs. But ref_field will merged with your module, and this feature is miss, so I can't move from ref_field to your Entity Reference module without sync function.

lsolesen’s picture

I also need it to attach teachers to subjects and subjects to teachers.

hgurol’s picture

That album has this song.
This song appears on that album.

#1313766: Reverse Relationships (or is it called two-way relations)...

Yuri’s picture

I also vote for the two-way reference sync model. I already needed it many times. The whole idea behind it, is that it takes work out of the users hands. Without it, the user needs to navigate back and forth between entities to update everything. The drawback of using EVA is that the user can only manage what's showing up on the album, by editing the song entity. So in the future ease of use will always win...why not choose for that right away?
So actually we need a Relations variant with the difference that the synced references are fields (not entities) and that the synced reference is updatable from both sides.
...just like Entity Reference Field has. So please make that part of Entity Reference (or the future merge with Reference).
Thank you.

Zach Harkey’s picture

I've been using the Corresponding Node References module to provide this functionality. The great thing about CNR is that it allows you to maintain separate ordering of referenced nodes (via drag and drop) from both directions. It also has an interface for batch synchronizing older nodes.

I wonder if it could be forked into a Corresponding Entity References module.

wipeout_dude’s picture

This is functionality I am also looking for, I have looked at "relation" and while its functionality might have an audience I just don't have a need for the references to be entities.. Also "relation" is complicated in creating the relationships from what I could see.. attaching references (user, node or entity) is far simpler and that's a good thing..

What I am currently working on is a system to manage a business profile, sites profile (offices) and people profile.. Sites and people are related to the business profile.. A site could be related to multiple businesses and these could change.. People can be referenced to multiple sites and these will certainly change..

So I create the business and then add a site and relate it to the business.. If I now add another business on the same site I have to create and save the business and then go find the site and add the reference to the business.. Not very intuitive.. If I was able to create the second business and then reference the site straight away (automatically adding the reference from the site to the business) then the process is far slicker and more user friendly.. Similarly adding a person to a site requires the site to be added and then I would have to find all the people connected to that site rather than just being able to select them using all and have the reverse reference created/updated automatically..

Damien Tournoud’s picture

Title: Entity Reference: Two-way referrence (syncronize 2 fields or use one storage for two-way link) » Entity Reference: Two-way referrence (synchronize 2 fields or use one storage for two-way link)
greg.1.anderson’s picture

To recap, there are three ways to get this functionality (entity back references) today:

1. Use relation instead of entityreference. Advantage: very robust two-way relationships (each relationship is a node). Downside: the user experience is more complicated than entity reference, as there is an extra object to create and maintain. As explained in #10, this is not desirable for some users.

2. Use references instead of entityreference, and manage back links with cnr. Advantage: provides bidirectional back reference editing without an extra relation object. Downside: references only supports nodes and users.

3. Use EVA or views_content (from ctools) with entityreference to create the back-links. (I added an explanation about this to #1313766: Reverse Relationships (or is it called two-way relations)....) Advantage: simple. Downside: no bidirectional editing of references. [Okay, #3 isn't really in-scope for this issue, but I think it's a perfectly reasonable substitute for some use cases.]

The missing functionality is simple bidirectional entity reference editing without the extra UX weight of relation objects. I think that the best solution was suggested in #9: extend cnr to work with entityreference. I think I'd be inclined to not fork, but instead have cnr work with both references and entityreferences. See #1201596: Corresponding Entity References. I would be disinclined to recommend supporting two-way entities in this module.

For now, I'm happy with the behavior I get with panels and views_content.

murrayw’s picture

This cnr feature request fits nicely with owl:inverseOf:

Properties have a direction, from domain to range. In practice, people often find it useful to define relations in both directions: persons own cars, cars are owned by persons. The owl:inverseOf construct can be used to define such an inverse relation between properties.

Defining such a mapping in the way cnr does will keep the simple model favoured by entityreference but also allow for back references which are editable from the target.

Mathijs Koenraadt’s picture

Status: Postponed (maintainer needs more info) » Active

2. Use references instead of entityreference, and manage back links with cnr. Advantage: provides bidirectional back reference editing without an extra relation object. Downside: references only supports nodes and users.

Yes this seems the way to do it. But since References will be abandoned(?) in favor of this entity_reference, we should consider the functionality.

So what's the status? Close this thread and focus on CNR to integrate with entityreference?

TimelessDomain’s picture

yea - we should focus upon entity references instead of just references.

#1308490: Migration from references module - There is a module under development to convert the fields over. We need to ensure a migration path from CNRs to the Corresponding Entity References setup. Therefore, we should focus upon converting to work with both Entity References & Node References simultaneously, then an upgrade path should be easier.

According to #1240234: Use EntityReference as a generic reference field - KarenS supports deprecating References in favor of Entity References, but webchick likes References for now & said that Entity References was an "up and comer."
Logically everything will go to Entity References eventually, but the only thing that would stop this is if References solved this #1240234: Use EntityReference as a generic reference field, which it doesn't look like there has been much progress on.

So for now we need:

  1. Corresponding Entity References (CER) via CNR #1201596: Corresponding Entity References
  2. References to Entity Reference Field Migration: #1308490: Migration from references module
  3. CNR to Corresponding Entity References (CER) Migration: There has already been progress with CER though the scope should be more limited initially #1267884: Synced field instances (aka cnr), and a lot more
lunk_rat’s picture

That album has this song.
This song appears on that album.

I am planning a site with this need. I am deciding on which modules to use.


adam_b’s picture

If you don't think entity references are ready, (based on Node References) is one option.

chx’s picture

Assigned: Unassigned » chx

#12 1. each reference is an entity. They are not nodes. 3. I tried to go with eva for a client just to make sure I am not favoriting my own module but when doing a track-album-track relationship chain and providing track 1 as an argument you will get track 1 in the result list and so it's not well fit when you are looking for other siblings but not the original. Especially relevant when you know there are only two of them.

chx’s picture

Assigned: chx » Unassigned

Hey! how did this got assigned to me?

rafaqz’s picture

jsacksicks sandbox entityreference backlinks module works fine for this, providing back-references for any application you cant just use a view for.

sachbearbeiter’s picture

but via this way we can't edit this field in target node, only in source.

is this possible with the sandbox module mentioned in #20?


rafaqz’s picture

Ah no, it dosn't solve the editing... just supplies the backlink. Didn't read the issue closely enough sorry...

jorisx’s picture

That artist has made a painting,
This painting was made by that artist.

Yes would love to see this functionality and be able to create views with filters based on the relationships

Subscribing :)

HnLn’s picture

@jorisx and others entity reference already supplies views for backreferences, so on the display side you can create views both ways. This issue is about being able to set the references in the node forms (either side) so the end user doesn't have to go through multiple forms to set up references.

jm.federico’s picture

(Entity)Reference Field Synchronization since version 2.x provides two way synch for Entity reference fields.

It deprecated its field (version 1.x) in favor of this module.

chx’s picture

Note that now there are various widgets for creating relations with relation module, study the modules linked from the project page.

chertzog’s picture

I just finished porting CNR to work with entities, before I thought to look here for this functionality.
Anyway for any future people here is a link to Corresponding Entity References.

lsolesen’s picture

Status: Active » Fixed

Marking as fixed as Corresponding entity references solves this.

Status: Fixed » Closed (fixed)

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