Problem/Motivation
When a link field is exported that has a link to another entity, it is exported like this:
field_link:
-
uri: 'entity:node/4'
title: Contact
options: { }
obviously the node is not necessarily the same after an import.
Proposed resolution
Add the target_type and target_uuid fields when the link is to an entity
target_type: node
target_uuid: 03e716d5-8cee-4e17-a321-337cc14af6b7
and then rewrite the url with the proper id after it has been imported/found
entity:node/23
Remaining tasks
- Write Tests
- Write Patch
User interface changes
None
API changes
Adding a pointer to the entity by UUID rather than by id.
Data model changes
Adding key to the value of a Link field
Release notes snippet
TBD
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | Content-Sync_Link-fields-hard-reference_3049963-14.patch | 47.4 KB | blanca.esqueda |
Comments
Comment #2
davidwbarratt commentedComment #3
blanca.esqueda commentedComment #4
ericvlThis could be a duplicate of this solved issue:
https://www.drupal.org/project/content_sync/issues/3179516
References should be an uuid and not a nodenumber.
To be checked.
Comment #5
blanca.esqueda commentedIt is not a duplicate, I tested the link field, and because it is not considered an entity reference the change to target_uuid is not happening.
I already worked on the normalization for this case for the import, but I still need to finish the denormalization for the export.
Comment #6
blanca.esqueda commentedComment #7
blanca.esqueda commentedComment #8
blanca.esqueda commentedDid some refactoring of the code - moved some pieces to the plugins and created a LinkItem and PathAlias normalized/denormalized.
The LinkItem change handles the menu link references too - as at the end it is a link.
To test:
Comment #9
blanca.esqueda commentedComment #10
ericvlHello everybody,
In testing this new patch I came to the conclusion that there is still a problem with the path_alias entity.
I tested it with the current development version with the extra patch in #7 but the fault is also in the 2.1 release version.
How to simulate?
1. Make a new node and call it e.g. Testpage. Add a URL-alias on the bottom of the editpage and call it /testpage. Save the node. You can
see the page under .../node/1
2. Check under .../admin/config/search/path that the alias "/testpage" is made and that it points to /node/1.
3. Go to .../admin/config/development/content and check that you have 2 new items: the node and the alias.
4. Go to .../admin/config/development/content/export/full and export the full contents and save it on your disk.
5. Go to .../node/1/edit and remove the alias on the bottom of the editpage by clearing the editbox and save the node.
6. Check under .../admin/config/search/path that the alias "/testpage" is removed. Upto here everything is normal.
7. Goto .../admin/config/development/content/import/full and import the file you just created with the export.
8. Go to .../node/1/edit and check the alias. (it is there but it doesn't have the correct id, see later)
9. Check under .../admin/config/search/path and you will see 2 aliasses!! ( one is newly created by importing the node and the original is
created too)
10. I think the reason for this is that in the yaml file the reference to the alias is not by its id but by its linkname (/testpage)
As said before, this bug is in all the versions even the previous release.
Could someone take a look at this?
Greetings
Eric
Comment #11
blanca.esqueda commentedThanks for testing @EricVL,
Could you post one of the yml sample that has the path alias?
Comment #12
blanca.esqueda commented@EricVL
I just tested following your steps and I can't replicate the issue.
Alias are now entities so they have their own YML file where the correspondent entity UUID and entity type of the entity using the alias is set.
for example:
Did the node was duplicated?
Could you check in the content sync folder the files generated on /entities/path_alias? every file should have an entity dependency that one is the entity that will be using the path alias.
Could you re-try with version 3.0.x-dev and the patch #7 on both source and target site, and let me know if you seeing the same issue?
Comment #13
blanca.esqueda commented@EricVL
I was able to replicate after a few imports/exports.
I think on import doesn't check if the path alias has been already added, and re-add it again.
Comment #14
blanca.esqueda commentedPath Alias now are entities, and they are handle with their own yml file.
So the 'path' variable doesn't need to be on entities that have canonical link templates (the entities that have the path alias).
@EricVL Could you help to test the following patch?
Please try the patch with 3.0.x-dev (clean cache after applying the patch), and let me know if it resolves the issue.
Comment #15
ericvl@Blanca.Esqueda
This is yaml of the path_alias
And this is the yaml of the node
After the alias is deleted in step 5 and re-imported in step 7, I think it has to do with the order of importing. If the alias is imported first and the node last then the alias already exists when the node is beeing imported. This way the alias with the old id can be used in the yaml of the node.
On the other hand, if the node is imported first and in the yaml of the node there is no reference to the correct id of the alias then the importer creates a new id for the alias (different from the first created). After importing the node the impoter imports the alias yaml and creates this wich results in 2 aliasses with the same node reference (../node/1), same name (/testpage) but different id.
Comment #16
ericvlOur comments did cross eachother :-)
Comment #17
blanca.esqueda commented@EricVL
Were you able to test patch #14?
Comment #18
ericvl@Blanca.Esqueda
This patch #14 works great. Congrats.
Now I can delete the alias in the page-editor or in the alias-editor (.../admin/config/search/path) and import it again with the previously created content.jar file.
Thank you very much for your help.
Sorry that you didn't get a response from me yesterdag, I wasn't at home. Now you are getting this comment while you're asleep :-)
Greetings
Eric
Comment #20
blanca.esqueda commentedThank you for testing @EricVL!
Marking this issue as fixed, and including it to 3.0.x-dev