Problem/Motivation

In #3549329: Enable Simple Taxonomy Import we worked on simple taxonomy import, in this one we want to work on media import.

We need to be able to:

Import content with an image

Start by adding this to the existing simple_content_migration we already have. If it is necessary, later spin it off into a new migration.

Issue fork ai_migration-3561775

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

  • 1.0.x Comparecompare
  • 3561775-enable-simple-media Comparecompare
About issue forks

Comments

dmundra created an issue. See original summary.

majorrobot made their first commit to this issue’s fork.

dmundra’s picture

dmundra
he/him
Primary language English
commented
Priority: Normal » Major
majorrobot’s picture

majorrobot commented

Right now, I'm of the mind that https://www.drupal.org/project/ai_migration/issues/3565342 should come first, blocking this issue for now.

dmundra’s picture

dmundra
he/him
Primary language English
commented
Status: Active » Postponed
Related issues: +#3565342: Enable File Import
majorrobot’s picture

majorrobot commented

Adding some information from a discussion between dmundra, andyhawks, muriqui, and me:

For migrations with references, it's best to do a "bottom-up" approach. For example, for a node with a media field, we'd import the file first, then the media item, and then the node. This is in contrast from doing a "top-down," stub approach.

One reason for this is that we don't believe you can create a file entity without the actual uri. Assuming that's true, you can't use stubs with files.

The concept is actually less complex and more intuitive (at least for us).

Starting some work on https://www.drupal.org/project/ai_migration/issues/3565342, though, I see a potential issue. If we start with a file migration with our current set-up, the Schemata module will create a schema only for the file entity, instead of a node with embedded media and file schemas. The file and media migrations won't have a concept of the node migration. (FWIW, a top-down approach would not have this issue.)

So, to continue along this path, we need a way for our module to know that the ultimate goal is to migrate a node with media and file embedded. A couple of ideas:
* We add the top-parent entity type and bundle to the migration yml config. This would require an addition to our yml scheme, which isn't ideal, but also would potentially be a quick-ish fix.
* Our module could look up the top-parent entity automatically... by using the migration_dependencies section of the yml (assuming it's available to us). We could either enforce an order on these where the array is top-down or bottom-up, or try to write logic that can figure out the hierarchy, whatever the order of the dependencies. It would be nice to be able to use config that is already in the file ... but what happens if a dependency is included that has nothing to do with the hierarchy we care about. This seems potentially problematic and messy.

Will need to think on this some more.

majorrobot’s picture

majorrobot commented

An update on questions in the last comment -- I was able to add a parent_type field to the migration config yml. This allows us to generate a schema for a node + entity references even when migrating references first.