Migrate translated entity reference from D7 to D8

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 🐛 Migrate translated entity reference from D7 to D8 Needs review 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 📌 [Policy] Migrate Drupal and Migrate Drupal UI after Drupal 7 EOL Fixed .

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 📌 [12.x] [Meta] Tasks to remove Migrate Drupal module Postponed and the removal work in 📌 [12.x] [Meta] Tasks to remove Migrate Drupal module Postponed .

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