Programmatic access to referring entity (during in place rendering)

I am also interested in this fietserwin, I'd love to see your code if you have it working.

Thanks!
Colin

I've used this patch(#4) on 2 projects with no problems so far.
But I needed the referring entity type as well, so I added the following line:
$referred_entity->referring_entity_type = $entity_type;

This has given 3 referring_X properties to the entity, it would make sense to gather them in a single referrer property, like so:

$referred_entity->referrer = array(
  'entity' => $entity,
  'entity_type' => $entity_type,
  'field' => array('name'=> $field['field_name'], 'delta' => $delta),
);

This way we wont pollute the entity object with multiple referred_x, and it would be easy to add additional referrer related data. Just a thought.

We need to pass the entity type as well, here's a patch for #5. Renamed ->referrer to ->entityreference_referrer to prevent any future naming clashes.

To further expand on #6, our use case is this:

We have a content type, faculty. Via an EVA listing, we're listing all nodes of the content type publication, which have a reference to the faculty.

However, when we view the publication, we display the faculty via hook_field_extra_fields and hook_node_view. In that workflow, you load the data you need, add it to $node->content, and the field system determines if it should be shown.

But when rendering the faculty, rendering the publication, and then rendering the faculty again, the unset($entity->content); is affecting the actual node being viewed!

Our only option is to prevent the recursion in hook_node_view, and that can only be done if we know the referring entity.

@tim.plunkett: your issue seems different? Everywhere an entity is rendered, it is supposed to be cloned first, so that any rendering in $entity->content doesn't affect the entity from the static cache.

Could you research why it is not happening for you?

+++ b/entityreference.module
+++ b/entityreference.module
@@ -1263,9 +1263,14 @@ function entityreference_field_formatter_view($entity_type, $entity, $field, $in

@@ -1263,9 +1263,14 @@ function entityreference_field_formatter_view($entity_type, $entity, $field, $in
-        $entity = clone $item['entity'];
...
+        $referred_entity = clone $item['entity'];

I can certainly look into it more, but at first glance I think I'm fixing another bug as a side-effect: We're overriding the $entity passed into the function in the first place.

And regardless of my actual problem, I don't want to run my code in hook_node_view() if the referred entity is of a certain bundle. So I need this info anyway.

I'm not sure, but I think my own problems are compounded by the entityreference being inside a field_collection. (Don't judge me!)

That said, this change stands alone as a feature request.

@tim.plunkett: most likely, somewhere something is not cloning an entity before displaying it. It would be really useful for the community as a whole for you to track this down :)

Yep. Neither node_view() nor node_build_content() clone it.

What would you expect to be the output of this?

function mymodule_node_view($node, $view_mode, $langcode) {
  $node->arbitrary_key = 'some value';
  $node_again = node_load($node->nid);
  debug($node_again->arbitrary_key);
}

I personally would try to not do this. Hence the need for this feature request.

It seems that you would expect this to result in Undefined property: stdClass::$arbitrary_key.
But because the node functions don't clone the object, and because the entity is statically cached by the entity storage, both nodes have the value.

So, accidentally running the same node through node_view will have its ->content unset.

I confirmed this with Berdir and amateescu in IRC.

I created a more general solution where an entity can reference itself, or circular be referenced without problems.
So entity A can reference A or entity A can reference B wich references C which references A. All up to the depth of 20.
In all cases the last reference is not shown.
It is based on the 7x-1.1 version.
Please test if its working in your cases as well.

The invalid patch format is always a problem of windows pc's. As far as I know, this should be a valid patch file.

To #17 fietserwin: you are right. I didn't read carefully enough.
I moved my patch to: https://www.drupal.org/node/2301499

We'll need to look over this before deciding if it should go into entityreference proper. I feel as though just overriding the default handler for your specific cases could suffice.

But like I said, we'll look it over.

@fietserwin could you re-roll the patch against the latest dev?