Missing Migration Destination in 8.*

An explicit destination for paragraph entities probably isn't needed in Drupal 8 - there is a general entity destination that should work for most entity types without their having to extend it:

destination:
  plugin: entity:paragraph

That being said, I see no sign of an upgrade path from Drupal 7...

Sure, support for migrate should be our goal.

Note that we first want to finalise the storage, see #2641824: Maintain composite relationship
And yeah sure, we love to see a migrate path contributed!

I am in the process of migrating a site from D7 to D8. The site uses paragraphs extensively and since paragraphs is currently missing a migration path I thought I would treat it as an opportunity to become familiar with the Migrate API in D8.

I have put together a patch which introduces an upgrade path from D7 to D8. The patch makes it possible to migrate the paragraph types, the fields configured on a paragraph type and the field configuration of paragraph fields on other entities from a D7 site. It is not perfect and I am bound to have missed some corner cases but it is a start at least.

I am currently working on adding the functionality to migrate the actual paragraph data and hope to contribute back a further patch very soon when that is complete.

@wackamole: Have you tried simply using

destination:
  plugin: entity:paragraph

to migrate paragraph data? It should work like most other entity types without needing to implement anything specifically for paragraphs.

@mikeryan: Firstly I would like to say what a great job you and the migrate team have done in bringing migrate into Drupal core and with providing core upgrade paths from D6/D7 to D8.

I have created migration templates for paragraphs and paragraph revisions using a migration builder based off of the migration templates provided in core by the d7_node and d7_node_revision templates in the core node module.

Just as you have suggested I was able to use a migration destination of entity:paragraph to migrate the paragraph data. As far as I can see the migration seems to have worked. I am currently tidying up the code that I have locally and checking the migrated data for correctness. I will produce another patch in the next couple of days.

OK, I have another patch.

This patch introduces:

- migrations for paragraph bundle field data and field revisions
- a migration for paragraph field instances attached to nodes

Sounds like its ready for a review!

I tried the patch on version 8.1, But didn't work from the migrate interface in D8.

With this patch applied, I get tons of "title cannot be null" errors. When the patch isn't applied I don't get any.

Here's a destination migration plugin. It is necessary, because when you deal with paragraphs with it's required sibling, ERR, you must provide the aggregate values. The default entity destination provided in core doesn't provide both values to you, only the 'id' value.

If you deal with the migration plugin to grab back a reference id, it only provides a single value without this patch.

No interdiff, as this doesn't try to provide any of the other parts of migrating into D8 from D7. Which, honestly should go into a follow-up, maybe? If we stay with what is outlined in the issue summary, which is creating a destination.

And some yaml examples on how to grab back both values in subsequent migrations that need to retrieve both aggregate values. This is from the process section. Obviously you need to define the source keys somewhere above. You have to do both things in the iterator, otherwise you get a nested array and things don't work.

  field_paragraphs:
    plugin: iterator
    source: foo_sources
    process:
      target_id:
        -
          plugin: migration
          source: source_key
          migration: migrate_foo_paragraphs
          no_stub: true
        -
          plugin: extract
          index:
            - 0
      target_revision_id:
        -
          plugin: migration
          source: source_key
          migration: migrate_foo_paragraphs
          no_stub: true
        -
          plugin: extract
          index:
            - 1

1. +++ b/src/Plugin/migrate/destination/Paragraph.php
   @@ -0,0 +1,38 @@
   +    return [
   

   Add a comment why returning both values is necessary.

2. +++ b/src/Plugin/migrate/destination/Paragraph.php
   @@ -0,0 +1,38 @@
   +    $ids[$this->getKey('revision')]['type'] = 'string';
   

   Should be integer.

IMO this patch solves the general migration case for Entity Reference Revisions, so it belongs in that module. The followup, Paragraphs-specific stuff (eg D7 stuff) should extend the class provided by ERR.

The entity named in the

+++ b/src/Plugin/migrate/destination/Paragraph.php
@@ -0,0 +1,38 @@
+ * @MigrateDestination(
+ *   id = "entity:paragraph"
+ * )

This is a kinda important part. You cannot migrate to a destination of a field. It has to be an entity. And since nothing for paragraphs should go into ERR, in my opinion this really needs to go into paragraphs.

You can build the ID from a deriver plugin, just like the entity: destinations do. Now I'm wishing I had saved the almost-working destination plugin I wrote for this already. :(

@see Drupal\migrate\Plugin\migrate\destination\entity
@see Drupal\migrate\Plugin\Derivative\MigrateEntity

When I wrote it, I just pruned the list of available types to revisionable content entities - that equates to valid targets for ERR fields AFAIK.

I gave it a try with a generic destination plugin, but so far I failed. See my comment at #2667748-24: Allow single scalar value in EntityReferenceRevisions data type plugin for my current approach and hopefully a discussion that may solve this issue.

@heddn I cant make this work, the processRow from migration doestn return any value, could you please share an example about how the source needs to be formatted?

Thanks :)

re #17: I'm working on a more generic solution in https://www.drupal.org/node/2809793. But until then, my comment in #11 should help. Hopefully.

Hi @heddn,

#2809793: EntityReference migrate destination works pretty ok for me :)

Thanks.

Hi all
Who can explain how to use this migration ?

Thanks,

Since the more generic solution at Entity Reference Revisions is committed, i guess this issue is obsoleted?
#2809793: EntityReference migrate destination

I'm going to close this as duplicate. Use the solution in #2809793: EntityReference migrate destination