- Issue created by @svendecabooter
- π§πͺBelgium svendecabooter Gent
Did some more digging, and it seems the datatype used in custom_field module is "CustomFieldEntityReference", which does not inherit from core "EntityReference" data type, so guess this will never work :'(
- π§πͺBelgium svendecabooter Gent
OK it should be possible after all I think.
Say we can integrate with the contrib Default Content module, to produce output as follows:
field_logos: - logo: entity_type: 'media' entity: eab657e0-3320-41d2-ab4e-53a09b397758 link: 'https://google.com' link__title: '' link__options: { }
(if not possible, worst case we need to document the exported YAML files have to be manually edited).
Then in CustomFieldEntityReference::setValue(). we can do something like:
/** * {@inheritdoc} */ public function setValue($value, $notify = TRUE): void { $entity = $value['entity'] ?? NULL; // START ADDED LOGIC. if (is_array($value)) { if ($value['entity_type'] && Uuid::isValid($value['entity'])) { $entity = \Drupal::entityTypeManager()->getStorage($value['entity_type'])->loadByProperties(['uuid' => $value['entity']]); $entity = !empty($entity) ? current($entity) : NULL; } } // END ADDED LOGIC. if ($entity instanceof EntityInterface) { ... }
I can spend some time to look further into this, but am currently time restrained, so just doing some braindump here.
Will try to elaborate on it next week.
Let me know if it would be a workable solution to extend the setValue() logic, for the use case of default content exports / imports. - πΊπΈUnited States apmsooner
I'm open to any improvements. If you can do the legwork to figure out what needs to happen to get this to work, I'd be happy to implement. Thanks!
- Merge request !132Resolve #3528586 "Core default content support" β (Open) created by svendecabooter
- π§πͺBelgium svendecabooter Gent
svendecabooter β changed the visibility of the branch 3528586-support-drupal-core to hidden.
- π§πͺBelgium svendecabooter Gent
A patch has been added to default_content module, to make sure the Default Content exported YML files use the UUID identifiers of referenced entities within a custom_field field, rather than their (numeric) entity ID.
The patch can be found at β¨ Add support for custom_field module Active - π§πͺBelgium svendecabooter Gent
Together with the patch to default_content mentioned above, this MR allows custom_field data to be exported by default_content, and imported by default_content import OR core's DefaultContent API, used by recipes.
- πΊπΈUnited States apmsooner
This looks pretty straight forward enough to merge however in getting back into these data types, I think its probably worth moving this new helper function to CustomFieldDataTypeBase and also the getEntity() function. I would assume for default content api, the other data types: CustomFieldImage & CustomFieldViewfield would also need the same changes and therefore can take advantage of the same methods and changes you're doing for CustomFieldEntityReference?
@svendcabooter - poised above question in #custom-field slack channel. Just confirm if this is the case and whether you have time to make the changes or else I can today and get this merged.