The simplest and most efficient way to get your files imported is to use the distinct file migration class, rather than try to map them directly in the referencing classes. These classes basically map the source files (or file_managed) table to the destination file_managed table, copying referenced files as necessary. The supported arguments:
- user_migration: The machine name of your user migration, used to properly assign ownership of the files.
- default_uid: A default destination uid to use as the default owner of files where a legacy owner isn't identified (for example, files owned by the account with uid 1 in the legacy system, since that account is not migrated).
- source_dir: The source destination from which to copy migrated files. See here for more info.
- destination_dir: The destination to which to copy migrated files. This defaults to public://.
- file_class: An override for the default MigrateFileUri class - you would use this if you had extended that class with application-specific behavior.
$file_arguments = $common_arguments + array(
'machine_name' => 'ExampleFile',
'description' => t('Import Drupal 6 files'),
'user_migration' => 'ExampleUser',
'default_uid' => 1,
'source_dir' => '/path/to/files',
'destination_dir' => 'public://legacy_files',
Using this strategy, files are migrated before being used in a subsequent migration, such as for a node containing a referenced image field. In the (custom) node migration, the referenced file should be migrated with a field mapping specifying a file_class of MigrateFileFid. This migrates only the reference to the file, not the file itself. Additionally, preserve_files should be set to TRUE to avoid deleting the actual file, should the node migration be rolled back (requires Migrate 7.x-2.6 or later). The mapping in the constructor for the node migration might contain:
->defaultValue(t('(c) 2012 My Site'));