Prior Art
In D7 we had needed https://www.drupal.org/project/entityreference_backreference for exposing backreferences in the entity API. Some other modules and discussions

Use Case
Content type A has an entity reference field to Content type B. Getting to Content type A from B would be impossible without entityreference backreference module in other modules that build on the entity api, such as Search API or Rules...

Comments

giorgio79’s picture

giorgio79 CreditAttribution: giorgio79 commented
Issue summary: View changes
giorgio79’s picture

giorgio79 CreditAttribution: giorgio79 commented
Issue summary: View changes
giorgio79’s picture

giorgio79 CreditAttribution: giorgio79 commented
Issue summary: View changes
Xano’s picture

Xano
he/they
Primary language English
Location Southampton
CreditAttribution: Xano at Druid commented
Version: 8.0.x-dev » 8.1.x-dev

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dadangnh’s picture

dadangnh CreditAttribution: dadangnh commented

Nice to have this

patoshi’s picture

patoshi CreditAttribution: patoshi commented

How would one access this in 8.3.x?

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

Well, not impossible. If you use a preprocess function to input the entity_id of your current entity (Type B) into a look up function that find what Entities of type A have references of type B with the entity_id you have.

Or in code like this:

/**
* If your entity is a node, and for the sake of this code sample, let's say A = article and B = page (or the Basic Page content type).
* So on the article content type, their is a field named field_reference that refers to the page content type.
* the node_id argument to this function is the nid of a page content type.
* Note that I'm returning the render arrays to the templating system by using core Drupal services.
*/
function _attach_back_reference($node_id){
  $query = \Drupal::entityQuery('node')
    ->condition('status', 1)
    ->condition('type', 'article')
    ->condition('field_reference', $node_id)
  ;
  $result = $query->execute();
  $release = Node::loadMultiple($result);

  $view_builder = \Drupal::entityTypeManager()->getViewBuilder('page');
  return $view_builder->viewMultiple($release);
}

So, without a field I'm able to control things like this. Sometimes that's all I need. But what you're asking for is some way to have this control + control over the data like being able to modify what is being referenced + control field order / placement ?

deminy’s picture

deminy
Location Canada
CreditAttribution: deminy commented

@cosmicdreams I'm wondering how the code piece in #9 could work in Drupal 8 cause there is no field called field_reference anywhere in Drupal core (version 8.2.5).

cosmicdreams’s picture

cosmicdreams CreditAttribution: cosmicdreams commented

@deminy: This code was written with Drupal 8 in mind. And yes, there isn't one by default. I guess I should have said in my code comment that it assumes that you would create an entity reference field named field_reference.

Other things to notice:

  1. This isn't an actual hook, it's intended to be a local private function.
  2. What I'm suggesting here isn't a patch to Drupal core but a strategy for a developer to deal with implementing back references through a little bit of code. It is a proof of concept to illustrate that handling back references in D8 is possible where previously it was asserted to be impossible.

Now if we wanted to have Drupal core provide back references by default there's probably a better way to do this than handling it in preprocess.

GeraldNDA’s picture

GeraldNDA CreditAttribution: GeraldNDA commented

I recently posted a sandbox and a project application for a reverse entity reference module. Any advice,code reviews and/or help getting this official would be appreciated.
Module: https://www.drupal.org/sandbox/geraldnda/2847085
Project Application: https://www.drupal.org/node/2847102

Grayside’s picture

Grayside CreditAttribution: Grayside at Phase2 commented

In case it's useful, here's some backreference code I've been using. https://gist.github.com/grayside/a7b8aba74ccf36ff984b0b9499b3a188

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

geek-merlin’s picture

geek-merlin
they/omg
Primary language German
Location Freiburg, Germany
CreditAttribution: geek-merlin at MachbarMacher commented
Category: Support request » Task

We really should have that in core.
The sandbox referenced above is now a full project.
Let's review the code and pull it in!

https://www.drupal.org/project/reverse_entity_reference

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner at Chapter Three commented

If we do that it should be certainly a custom field you opt into , rather than what the module is doing, which is defining these back references automatically. There are back references, like terms, where you easily can destroy your site, due to the sheer amount of issues.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.