Problem/Motivation

EntityReferenceFormatterBase::getEntitiesToView() sets $entity->_referringItem but if the same entity is referred multiple times then the value gets overridden.

Steps to reproduce

Refer the same file twice, add something to $item->_attributes in hook_entity_prepare_view to both of the referring items, observe how GenericFileFormatter makes a total hash of it: the first file link will get the attributes of the second and the second will get nothing.

Proposed resolution

          // Add the referring item, in case the formatter needs it.
          if ($entity->_referringItem) {
            $entity = clone $entity;
          }
          $entity->_referringItem = $items[$delta];
          $entity->_entityReferenceViewLangcode = $langcode;
          $entities[$delta] = $entity;

The conditional cloning is new.

Remaining tasks

Make a PR, add a test.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3489179

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

ghost of drupal past created an issue. See original summary.

ghost of drupal past’s picture

Issue summary: View changes
andypost’s picture

godotislate’s picture

I don't think #2940605: Can only intentionally re-render an entity with references 20 times is a duplicate, but the two issues are closely related. I did notice that _referringItem would get overwritten while working on #2940605: Can only intentionally re-render an entity with references 20 times, and cloning the entity so that _referringItem is correct might actually help address recursion detection. Though I think in the (edge?) case where you are previewing new entities, cloning might make recursion detection more difficult, but I don't think that's a blocker here.

quietone’s picture

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

Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.

ghost of drupal past’s picture

Thanks for the quick patch!

I suggested checking whether $entity->_referringItem exists first before cloning because I was afraid of the performance hit here.

godotislate’s picture

Status: Active » Needs review

MR is up with tests.

godotislate’s picture

TY to @ghost of drupal past for the review. Replied to comments on the MR. I resolved the open threads, but please feel free to unresolve if they were not addressed satisfactorily.

ghost of drupal past’s picture

Status: Needs review » Reviewed & tested by the community

Yes, sorry, I confused which entity is which. This looks good to me, thanks so much for the through tests and the quick resolution of all.

  • catch committed 40c1ab52 on 11.x
    Issue #3489179 by godotislate, ghost of drupal past: Referring the same...

  • catch committed 80f2ff71 on 11.1.x
    Issue #3489179 by godotislate, ghost of drupal past: Referring the same...

  • catch committed 5128a905 on 10.5.x
    Issue #3489179 by godotislate, ghost of drupal past: Referring the same...
catch’s picture

Version: 11.x-dev » 10.5.x-dev
Status: Reviewed & tested by the community » Fixed

This is a tricky one, but tidy fix that makes sense and nice test coverage.

Committed/pushed to 11.x, cherry-picked to 11.1.x and 10.5.x, thanks!

Status: Fixed » Closed (fixed)

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