Migrate translated entity reference from D7 to D8

I don't see how comment #2 is related to the original problem where you say entity references should accept other kinds of values.

I needed to do that because if I specify that I want to migrate translations, the original node(n.nid = n.tnid) isn't migrated. Is there a better way to do this?

Yes, so d7_node_translation does not specify the node migration as a dependency (for some reason), but if you look at how its tested (MigrateNodeTest), the node migration is ran before the translation migration. The node migration will migrate the original language.

I think this may be too much in the weeds of migrate for me to practically help :/ Know multilingual much better than migrate. But if the langcode is dropped, how is the correct translation identified?

Yeah I would generally say removing meta information that distinguishes an element is not a good idea. Making systems work with that meta information is better :)

I am having the exact issue of not being able to import EntityReference fields (with multiple values) that have translations. The default language migration works fine, but running the translation migration either fails OR it produces these new bizarre referenced items with really long titles for every entity it encounters but can't find (I suppose).

Applying the patch outlined in comment #2 does fix the import of translated content items.

I am curious if someone can point out what is the intended migration config that should work without the patch? I do see that the target ID from the sub-migration has both the ID and a language code. So are we supposed to split it with another plugin and then use it to point to the right destination?

One note, though: It seems that the patch works if its run on *only* the migration scripts that deal with the translation.

The first run of the migration (that goes through the default language migration) is to be run with the existing code untouched (I'm on 8.3.2). Then the patch is to be applied and the upgrade_d7_node_translation_NODE_TYPE.yml is run with that. This way I was able to complete the migration for the migrated content.

However, if I apply the patch and run the first migration as well with it (upgrade_d7_node_NODE_TYPE.yml) then it seems to me that the system generates these weird nodes that it would generate only in the 2nd step when running the _translate_NODE_TYPE.yml (basically the errors I was experiencing when trying to complete the migration for the translated content would happen right away with the first run of the migration script)

This patch breaks the path migration's node translation lookup process plugin.

It needs the langcode for a translation migration (destid2) to set the correct language for the path alias.

As a follow-up on my previous comment, I've retested my own bugfix patch and decided to share it with you guys.

I've been using the various plugins and the only one returning a "faulty" value for an EntityReference is the MigrationLookup plugin.

However, the current patch breaks the UrlAlias translation lookup process plugin, because there isn't a langcode column anymore to depend on, to create the D8 Url alias entity.

In my opinion the patch is as easy as changing 1 character, and to "reset" the destination_ids array, even if there are more then 1 items in the array. This returns a single ID everytime, and thus not removes the metadata (langcode) from the DB scheme, but only inside the method that uses the Id lookup.

Feel free to comment on my fix.

tagging

@jmoreira, thanks for filing this issue and creating a patch.

A migration for entity references for translated nodes was created in #2912348: Handle entity_references related to Drupal 6 and 7 node translations with different IDs and committed on Apr 19 2018. That will will have fixed this problem. There hasn't been any activity on this since before that commit which also leads me to believe this has been fixed.

I'm going to close this as outdated. If I am wrong, reopen this issue by setting the status to Active and explain what is not working, what error message you are getting and anything you think is relevant.

Thanks!

I realize this is an old issue, so I'm not going to reopen it, but for the benefit of others, I want to comment that I had the same issue as described by the O.P, and the patch #13 resolved it. So I would say the comment in #19 that this issue was fixed with that commit is incorrect. I'm fine with the patch. I just want to let anyone that finds this issue know.

If I am wrong, reopen this issue by setting the status to Active and explain what is not working, what error message you are getting and anything you think is relevant.

Ack, I hate to reopen this issue, but I think it is warranted. If I should not, let me know! I'm having the same experience as OP, as well as @Shiraz Dindar above.

I'm running Drupal 10.2.5 and I'm migrating from another site on 10.2.5. Though I'm using the migrate_drupal_d8 contrib module, it still calls the core Migration Lookup plugin. In my case, I have an image field migrating to an identical image field. Both sites have Content Translation enabled for the content type. It does not seem to matter, but I have the image field configured not to be translatable.

#2912348: Handle entity_references related to Drupal 6 and 7 node translations with different IDs has some similarities, but I think it is actually a different issue.

I understand that issue to solve a problem where entity reference migrations aren't looking up the correct original target_ids. The issue here is that entity references end up with 2 destination ids: the target_id and the langcode. The target_id is correct. However, EntityReference->setValue() only accepts a single scalar value.

Thus, I'm still getting
"Value is not a valid entity." line 106 on core/lib/Drupal/Core/Entity/Plugin/DataType/EntityReference.php

The patch in #13 solves the issue for me, too. The solution in the patch seems a bit heavy-handed, but I don't know other use cases well enough to say whether or not the patch would break other migrations. It seems a bit dangerous, but I can't say for sure:

     if ($destination_ids) {
-      if (count($destination_ids) == 1) {
+      if (count($destination_ids) >= 1) {
         return reset($destination_ids);
       }
       else {

The Needs Review Queue Bot tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request. Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

This needs to be fixed on 11.x (our main development branch) first, and are then back ported as needed according to our policies. Also, 10.2 is in security mode now.

Thanks for the extra information in #21. That seems useful. We do need a test here to demonstrate the problem.

The Migrate Drupal Module was approved for removal in #3371229: [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3522602: [meta] Tasks to remove Migrate Drupal module and the removal work in #3522602: [meta] Tasks to remove Migrate Drupal module.

Migrate Drupal will not be moved to a contributed project. It will be removed from core after the Drupal 12.x branch is open.

The Migrate Drupal Module and Migrate Drupal UI are deprecated and they are not in Drupal 12.0.0.

Issues for these modules should now be on the 11.x branch. And the changes are limited to critical and major bug fixes. Other changes are allowed at the discretion of the core Release Managers in consultation with the Migrate subsystem maintainers.