I had originally posted this in the issue queue for the content_sync project, but after doing some more logic tracing I now think it may actually have more to do with this one, so I'm replicating my comment here. Also, this appears somewhat related to other issues posted here, but I'm not sure it's precisely the same, and I apologize if I'm being unnecessarily redundant.
We have nodes with paragraphs, which themselves have fields configured to use the media_library_media_modify plugin widgets, which in turn are enabling "contextual cropping" via crop and media_contextual_crop.
When all this exported, we get a snippet of yaml which, unlike more conventional media reference fields, look like this:
field_photo_crop:
-
target_id: '3288'
overwritten_property_map: '{"path":[{"alias":"","pid":null}],"field_media_image":[{"image_crop":{"crop_wrapper":{"crop_1040_x_427":{"crop_container":{"values":{"crop_applied":"1","x":"0","y":"976","width":"3262","height":"1339"},"reset":"Reset crop"}}},"file-uri":"public:\/\/2024-10\/some-file.jpg","file-id":"111111"}}]}'
Since this contains only the target_id, rather than all the nice URI stuff and the related asset, it's not going to migrate. Presumably (though I haven't tested this yet), it might import "as is", but of course we can't know that we won't be overwriting an existing target_id in the destination environment.
Obviously, this has much more to do with those other plugins, but I'm wondering if there are any quick thoughts here on how to account for this. Even though the other plugins are causing the issue, I think the solution is going to wind up being hooking/extending this one, and I'd appreciate any guidance in that area.
Addendum: An alternative question might be: is it possible to adjust the import method to account for and correct possible target ID overwrites?
Current followup: My current thought is to extend your ImageItemNormalizer class to alter the way the data is collected and exported (and of course imported).
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | single_content_sync_entity_reference_entity_modify.patch | 2.08 KB | datawench |
Issue fork single_content_sync-3522692
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
Comment #2
datawench commentedComment #3
nginex commentedHello, thanks for posting a detail issue here, I think a new field type that the module provides "entity_reference_entity_modify" is not fully supported by the single_content_sync module, as all the referenced fields need to go through a custom plugin "entity_reference". Try adding "entity_reference_entity_modify" here https://git.drupalcode.org/project/single_content_sync/-/blob/1.4.x/src/...
Then the custom plugin that exports references will pick that up https://git.drupalcode.org/project/single_content_sync/-/blob/1.4.x/src/...
But probably it will need to be extended and adjusted. When I have some time I can try to make a patch unless you do it faster ;)
Comment #4
datawench commentedAh, I see... thank you very much for the pointer. I'll take a close look at that.
And to correct my own comment, I misidentified
ImageItemNormalizeras a class in your own plugin. And in fact it is not invoked when an export of this kind is executed.Comment #5
datawench commentedThank you again. Your suggestion prompted a very straightforward patch. I offer it here as a file rather than a merge request, because it's pretty raw, too specific, and can probably be done better with a higher level configuration setting.
If you have suggestions in that regard, let me know and I'd be happy to act on them, toward providing an useful merge request.
Comment #7
nginex commented@datawench
your patch is totaly fine, I'm glad it works as expected now.
I just created a MR based on your patch but adjusted the condition a bit, so it better suits the existing code.
I will include this issue to the next release, it will not harm for sure ;)
Comment #9
nginex commentedThis is now available in new release 1.4.14