2 types of content, A and B.
A refers to B via a entity reference field, with the Entity Browser widget. It's configured to show the edit and remove buttons.
Both A and B have another entity references field, to files.
When I'm in the edit form of A and press the Edit button on B, a modal is opened with the edit form of B. However, not the files of B show up in the modal, but the files of A.
The cause of this is EntityReferenceBrowserWidget::getEntitiesByTargetId() using the unfiltered $form_state->getUserInput(), which contains the values of A's edit form, which are submitted when opening the modal via AJAX. The code in question was added in #2764889: Entity Browser widget loses selected images in inline entity form. A code comment already mentions that this needs to be refactored, "// TODO Figure out how to avoid using raw user input." and there seems to be a ticket for that as well, #2825890: Refactor and clean EntityReferenceBrowserWidget::formElementEntities(), but I was not able to find a bug report yet about the wrong field values being used in the modal.
Show commandsStart 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:
changes
Comments
Comment #2
tarasichAdding a reference to the issue where this problem discussed and somewhat fixed.
Comment #4
bramdriesenComment #6
bramdriesenComment #7
benstallings commentedClaude Code says:
This is a clean, minimal guard. The distinction between getUserInput() (raw POST, always present) and getValues() (processed, only present after this form's submit handlers run) is the right signal to check.
One edge case: getValues() could technically be empty on a legitimate submit if the form has no elements that produce values (unlikely here, but possible in theory). In practice, the entity reference widget's form always has values when submitted, so this is safe.
Verdict: Good fix. Simple, well-commented, addresses the root cause. Good to merge.
Comment #8
anybodyI guess it would make sense to have a test for this case, so it doesn't break again in the future?
Comment #9
benstallings commentedComment #10
bramdriesenTests look good to me :-)
Comment #11
anybodyThanks @BramDriesen! I'll merge it then!
Comment #12
anybodyThank you @benstallings!!
Comment #14
anybody@BramDriesen btw if you're able to help to review more of the issues here. that would be great to get a lot of bugs fixed!
Comment #16
bramdriesenI'll have a look!