Problem/Motivation

The primary_entity_reference field type does not support the entity key format that Drupal's core serialization system uses during recipe and default content import. Standard entity_reference fields work with this format; primary_entity_reference fields do not.

When using Drupal Recipes or Default Content with primary_entity_reference fields, YAML like the following does not populate the field:

emails:
  - entity: '676cfc78-1cac-5a48-b729-fbba59d7c230'

No error is thrown, but the field remains empty after import. The same structure works for standard entity_reference fields (e.g. the contacts field on crm_relationship). This prevents recipes from importing content that uses primary_entity_reference for fields such as emails, telephones, or addresses.

Steps to reproduce

  1. Create a recipe that imports content entities with primary_entity_reference base fields (e.g. a contact entity with emails, telephones, addresses fields).
  2. In the content YAML, reference related entities using the entity: 'uuid' format, with _meta.depends declaring the referenced entity type so import order is correct.
  3. Apply the recipe (e.g. drush recipe:apply path/to/recipe).
  4. Observe: entities using standard entity_reference (e.g. relationships) have their reference fields populated; entities using primary_entity_reference have those fields empty.

Example YAML that fails to populate primary_entity_reference fields:

_meta:
  version: 1.0
  entity_type: crm_contact
  uuid: '00af71f6-cff0-5716-a2b1-323288beab04'
  bundle: person
  depends:
    c5a34440-9a73-5685-881e-f929fe15356f: crm_contact_method
    c753a2f1-3c68-50db-b069-a4c5957c7f10: crm_contact_method
default:
  name: [{ value: Lisa Simpson }]
  emails:
    - entity: 'c5a34440-9a73-5685-881e-f929fe15356f'
  telephones:
    - entity: 'c753a2f1-3c68-50db-b069-a4c5957c7f10'

Expected: emails and telephones are populated with the referenced crm_contact_method entities.

Actual: Fields remain empty; no error is reported.

Proposed resolution

Add a custom normalizer so that primary_entity_reference field items support the entity key during denormalization (YAML → PHP), matching the behavior of core's handling for EntityReferenceItem.

  1. Implement a normalizer class (e.g. PrimaryEntityReferenceItemNormalizer) that extends the appropriate base (e.g. FieldItemNormalizer or the normalizer used for entity reference items).
  2. In denormalize(), detect the entity key with a UUID value; load the entity by UUID (e.g. via entity.repository or entity_type.manager + storage loadByProperties(['uuid' => $uuid])); convert to the target_id format the field expects; then call the parent denormalizer.
  3. Register the normalizer in primary_entity_reference.services.yml with a priority higher than the default field item normalizers so it is used for PrimaryEntityReferenceItem (or the module's field item class).

This is an API addition (new normalizer service) and is backward compatible: it only adds support for a format that currently has no effect.

Remaining tasks

  • Implement the normalizer and register it in services.yml.
  • Add kernel tests for denormalization of the entity key (UUID → target_id).
  • Add an integration test that applies a recipe containing content with primary_entity_reference fields and asserts the fields are populated.

User interface changes

None.

API changes

New normalizer service for PrimaryEntityReferenceItem (or the module's field item class), used during content/recipe import. No breaking changes.

Data model changes

None.

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

bluegeek9 created an issue. See original summary.

bluegeek9’s picture

Assigned: bluegeek9 » Unassigned
Status: Active » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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