Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Problem/Motivation
While using default_content, it seems that information on certain entity reference fields is not being normalized and denormalized. The example in question is a file reference field which is missing the "display" and "description" keys. On reimporting of the content, a SQL error is thrown at the DB level due to the missing information.
Proposed resolution
Fix EntityReferenceItemNormalizer to include additional data about reference fields, not just the link to the entity itself.
Remaining tasks
Write a patch.
User interface changes
None.
API changes
REST output would change. It would be the addition of keys from what I can gather, not changing anything else.
Comment | File | Size | Author |
---|---|---|---|
#11 | 2394063-hal-issue-11.patch | 2.47 KB | Wim Leers |
#6 | 2394063-hal-issue-5.patch | 2.2 KB | Sam152 |
#4 | 2394063-hal-issue-4.patch | 2.18 KB | Sam152 |
#2 | 2394063-hal-issue.patch | 2.74 KB | Sam152 |
Comments
Comment #1
BerdirI think we're making exactly this change in #1927648: Allow creation of file entities from binary data via REST requests.
Comment #2
Sam152 CreditAttribution: Sam152 commentedAttached is a proof of concept patch to fix the issue for file entities specifically. I'll post the known issues next comment.
Comment #3
Sam152 CreditAttribution: Sam152 commentedOh, did not manage to pick that issue up in the search. Won't bother going into what is broken with the patch.
Thanks :)
Comment #4
Sam152 CreditAttribution: Sam152 commentedAfter looking into that issue, this issue aims to do a lot less. I have attached a different approach, which still seems pretty smelly, but it ensures that required keys are present on fields such as images or files during import/export.
This is not about encoding the actual file in the serialized output, but just making sure the keys required for a valid reference are present.
Comment #6
Sam152 CreditAttribution: Sam152 commentedComment #7
Sam152 CreditAttribution: Sam152 commentedComment #8
Sam152 CreditAttribution: Sam152 commentedComment #11
Wim LeersFree reroll.
Comment #15
Grayside CreditAttribution: Grayside at Phase2 commentedI have found this problem to also obfuscate the title, alt, width, and height attributes on the ImageItem field type. This creates a blocker for management of image accessibility for headless use cases.
Comment #16
Grayside CreditAttribution: Grayside at Phase2 commentedLet's retry those tests.
Comment #18
Grayside CreditAttribution: Grayside at Phase2 commentedConsistent typo. => constructed
Comment #19
Grayside CreditAttribution: Grayside at Phase2 commentedNote that this solution sidesteps Typed Data, so any modules dynamically generating API payload descriptions (Schemata) will not be aware of these properties.
Furthermore, the current implementation is adding the alt text and so on as properties, rather than fields, which makes for a "top-level" inconsistency in the JSON, since every other element is an array.
Comment #21
Wim LeersThat makes this approach a dead end IMO.
The solution in that case is to provide a
FileItemNormalizer
, becauseclass FileItem extends EntityReferenceItem
.This patch/issue is proposing to modify
EntityReferenceItemNormalizer
, which is the wrong place to do this. We have #2825487: Fix normalization of File entities: file entities should expose the file URL as a computed property on the 'uri' base field for this.