Problem/Motivation
I'm testing the version on the latest developper branch of this module and have this problem:
I have a content type that is in fact a photobook. You can add photos to it.
When I export such a node, the yaml file has for every photo a full path to the url of the photo. In fact, on my local development system it starts with "http://localhost/...".
When I import this node to my live system, I see a conflict off course between the url's of the images. The import says "http://localhost..." and the live machine has "http://www.example.com/...".
In the yaml file of the node of the version 2.1 of this module there was no reference to url but only to the id of the image.
I can send some examples of both versions if needed.
By the way: the version on the branch is now 2bfa12c22b63b35ff1affcc106ea7e2520842cb0
By the way 2: I want to switch to Drupal 9 because version 8 doesn't receives any updates anymore and version 2.1 of this module is not Drupal 9 compatible. (and version 3.0beta1 does not work)
Steps to reproduce
Export a node with images on a local machine and import it on the live server.
Proposed resolution
If the url is needed, it should start after the specification of the server.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | wrong-parentclass-3251829-7.patch | 490 bytes | ericvl |
Comments
Comment #2
blanca.esqueda commentedThanks for the report @EricVL,
If you can please send me the XML samples of both versions.
Comment #3
ericvlHi Blanca,
Thank tou for your response. Here they are.
The first is the 2.1 version and the last is the 3.0.dev version.
and
Good luck with it.
Greetings
Comment #4
ericvlAs a second tip:
The url tag was introduced in the commitnumber 420998cfeed939976cf667d854a2681e0ed33d99. The previous commit (583d32380f1638fc7e40c2021565e526e48f6f8d) didn't had this url tag.
I don't know if one has to have a reference to the file url here because the reference is in the file.file.... yaml.
Any way, if one need the url then the name of the server shouldn't be in it. Only what is following the webroot should be there.
Cheers
Comment #5
ericvlTip 3:
The files are not added to the entity_dependencies tag in the latest version. Could be a reason to create the (faulty) url.
Tip 4:
If you add a picture to a user then you have the phenomenon.
The url to the picture is a fixed path and the file dependency is not added to the user yaml.
Tip 5:
Create a content_type "article" and add a picture to it.
Same story.
Comment #6
ericvlHello everybody,
I think I found a solution for a lot of bugs that are created here and even so for this one too.
In the file ImageItemNormalizer.php there is a class ImageItemNormalizer that is based on EntityReferenceFieldItemNormalizer. So the parent of the class ImageItemNormalizer is the class EntityReferenceFieldItemNormalizer.
The parent class EntityReferenceFieldItemNormalizer was ment to be the class that is created in the content_sync module and not the class EntityReferenceFieldItemNormalizer from the core.
Never the less, the EntityReferenceFieldItemNormalizer class from core is referenced in line 7 in the use statement.
This is probably wrong. It should use parent EntityReferenceFieldItemNormalizer from the code in the module.
If I comment out line 7 in the ImageItemNormalizer.php then the correct class is used as parent.
With this change, the long paths to the image files and even to media files in the exported yaml files are gone and I could use the yaml files to update the live server from the files created on my localhost.
One remark before you change the file: disable the module before changing and after the change enable the module again because a full new snapshot have to be created.
Can this be tested by the community to check if this could be a solution for a lot of frustrations.
Greetings
Eric
Comment #7
ericvlIf anyone is interrested in the patch. Here it is.
Comment #8
prashant.cIn #7 following is removed
but the class
ImageItemNormalizerextends it.Comment #9
ericvl@Prashant.c
Yes, it extends from EntityReferenceFieldItemNormalizer but not from the one in core. It should extend from the EntityReferenceFieldItemNormalizer in the same folder (src/Normalizer) of the module. And if you delete the "use" line in the file, it will extends the one in the same folder.
I think, this was copied from another module, created a new EntityReferenceFieldItemNormalizer in the module and forgotten to delete the original line.
If you use the patch, it will work.
Comment #10
ericvlComment #11
blanca.esqueda commentedComment #12
ericvl