Problem/Motivation

This is a bit tricky to reproduce, not sure if there are easier ways:

Preconditions:
A. A translatable node type that is configured to hide untranslatable fields when editing a translation.
B. Have a node type with an untranslatable field_media, a paragraph field, a paragraph type that also has a field_media field but this is translatable.
C. An entity browser to create/select medias, configure both field_media to use EB.

1. Create a node with a media in the node field_media field, add a paragraph with a media in field_media.
2. Add a translation, switch out the translatable media in the paragraph field_media field, save.

Now you get a validation error that untranslatable fields must not be changed.

Took me a long time to debug, but what's happen is that \Drupal\entity_browser\Plugin\Field\FieldWidget\EntityReferenceBrowserWidget::formElementEntities() incorrectly identifies the triggering element as its own for the node field_media field because...

a) The field name matches
b) getEntitiesByTargetId() doesn't return anything, because the field is not accessible
c) $element['#field_parents'] is an empty array, so it results in basically this check: array_slice($trigger['#parents'], 0, 0) == [], which is of course true.

The reason it *only* happens in this translation scenario is b), a visible field already returns early at that point and does not continue further down. I'm honestly not quite sure when the logic below is still called, aybe delete operations? Possibly that could be cleaned a bit, see also #2825890: Refactor and clean EntityReferenceBrowserWidget::formElementEntities().

Proposed resolution

We already check a specific index of the parents for the field name, so I think we need to additionally also check everything above against the field parents. I think we need both checks, as only this new check could have the same flaw in the reversed situation, with a translatable field without parents and an untranslatable one further below.

Remaining tasks

Tests.

User interface changes

API changes

Data model changes

Comments

Berdir created an issue. See original summary.

berdir’s picture

Status: Active » Needs review
StatusFileSize
new1.02 KB

Here's a patch for the proposed change.

berdir’s picture

Issue tags: +Needs tests
johnchque’s picture

Assigned: Unassigned » johnchque

Working on tests. :)

johnchque’s picture

Haven't tested manually yet, I believe this happens with other entity types as well, right?

p-neyens’s picture

Thanks the patch fixed it for us

berdir’s picture

Status: Needs review » Fixed

Decided to go ahead and commit this. We've been using it in production for years and from what I can see, there's half a dozen related or similar issues about such problems, and I'm wondering if this will fix them too.

  • Berdir committed ba5aa1b on 8.x-2.x
    Issue #3048530 by Berdir: EntityReferenceBrowserWidget::...

Status: Fixed » Closed (fixed)

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