file_link in migrate

Try

$this->addFieldMapping('field_migrate_example_image:file_replace')
     ->defaultValue(MigrateFile::FILE_EXISTS_REUSE);

I'm having difficulty figuring this out too.

Would like to just link to existing picture in a directory (or even external URL for that matter) for displaying an image rather than copying the image. Purpose is to save time on migrate and file space due to massive amounts of images.

Do you have any examples of this for 2.4?

Edit:
I found the following in http://drupal.org/node/1540106

preserve_files - Normally, importing and rolling back a migration involving file imports will delete the files on rollback. Sometimes this is not desirable - for example, one approach to file migration may be to simply copy all the files into their desired location in the Drupal installation and use FILE_EXISTS_REUSE to just link to them, or you may have a symbolic link to a readonly mounted filesystem containing the files.

@farse: 'public://rightmove/rm_images' is a symlink? Have you tried setting preserve_files to true? Not sure if that would help.

Also, did you have your 'image_path' relative to the 'source_dir'?

Also from http://drupal.org/node/1540106

destination_file - This is the filename relative to destination_dir at which to store the file. If omitted, the filename portion of the primary value will be used. If you have a hierarchical structure you wish to preserve, pass the same value here as you do for the primary value. For example, suppose you implement a migration given physical files at:

Maybe try removing the mapping for the file value:

$this->addFieldMapping('field_prop_images:destination_file', 'image_path');

and see if it will use the primary value from 'image_path'

Let me know if any of this works

Sorry for the silence so far - it's tough to see why it's not working without a good test bed - a real-life file migration to work with. As it happens, I'm just starting a new Drupal-to-Drupal migration migration project, and now that I have my source file dump which I'll be symlinking from the destination files directory, I'll be ready to implement my file migration - I should have an answer (whether it's a better set of parameters, or a code fix) within a few days.

Thanks.

@mikeryan: Thanks for looking into this for us!

@farse: In the mean time, could you maybe try hard coding in the directory structure you want to keep?

 $this->addFieldMapping('field_prop_images:destination_dir')
        ->defaultValue('public://rightmove/rm_images/'.$this->unique_dir.'/');

function prepareRow(){
  $this->unique_dir = $uid;
}

OK, here's my scenario and how I configured the migration to make it work:

• My legacy files are at /data/dumps/files (copy of sites/default/files from a source Drupal site).
• I linked them into my target site, while in sites/mysite/files I did: ln -s /data/dumps/files/ legacy

My migration (D7-to-D7, so source fields are from the file_managed table) looks more-or-less like:

    $this->destination = new MigrateDestinationFile();
    // Edited: should be stream wrapped parent directory
    $this->addFieldMapping('destination_dir')
         ->defaultValue('public://legacy');
    // ...while this is relative to Drupal root (should fetch file_public_path)
    // Edit: But, doesn't matter - see later comment
    $this->addFieldMapping('source_dir')
         ->defaultValue('sites/mysite/files/legacy');
    $this->addFieldMapping('timestamp', 'timestamp');
    $this->addFieldMapping('file_replace')
         ->defaultValue(MigrateFile::FILE_EXISTS_REUSE);
    $this->addFieldmapping('preserve_files')
          ->defaultValue(TRUE);
    $this->addFieldMapping('value', 'uri')
         ->callbacks(array($this, 'fixUri'));
    $this->addFieldMapping('destination_file', 'uri')
         ->callbacks(array($this, 'fixUri'));
...
  // Because we're coming from D7, which has public:// prepended to the path within the files dir
  protected function fixUri($uri) {
    return str_replace('public://', '', $uri);
  }

Is this helpful? If so I'll add an example to the documentation.

I should point out that source_dir only matters if the file is actually copied, in this scenario it's irrelevant - the incoming uri to appended to the destination_dir, and since destination_dir/uri exists, all that's done is the creation of the file entity, no copy is attempted.

No, wait a minute, it's not working right, got a bogus uri in the destination file_managed table (I was looking at the wrong db), continuing to investigate...

OK, I thought there was something wrong with setting destination_dir to legacy instead of public://legacy... The latter is right, the problem is file_exists() on the filespec with the stream wrapper (public://) fails when the files are symbolically linked - when I made a parallel legacy2 directory with a copy of my physical target file, that worked. Trying various solutions involving is_file(), drupal_realpath(), etc., but still can't verify the existence of the linked file.

See #1008402: Allow the use of symlinks within the files directory. - I find I'm already following that issue, so I guess I've run into this before;).

What I need to do here to support symbolic links is to reproduce the logic of DrupalLocalStreamWrapper::getLocalPath(), without the bit that bails on symlinks... Then the resulting path should pass file_exists with flying colors.

No luck on that - or rather, I solved the immediate (file_exists) problem, but ran into more trouble deep within the File API (i.e., getting filesize on the linked files from file_save()).

For now, I've confirmed that the patch at http://drupal.org/node/1008402#comment-6118996 works. But, not wanting to kill any kittens, I'm replacing the symlink with a mount:

rm legacy
mkdir legacy
sudo mount --rbind /data/dumps/files/ legacy

Yes, the field version should treat destination_file the same - if your uri has a full path, that should be preserved.

The issue is for Drupal 8, but the patch I pointed to is for Drupal 7. An alternative to the patch, as I pointed out, is using mount --rlink instead of symlinks to tie the files into your files directory.

You mean your files are physically under the files folder, not linked in? OK, most of what I've been talking about is irrelevant to you, but the basic setup in comment #10 should work, something like:

    $this->addFieldMapping('field_prop_images', 'image_path');
    $this->addFieldMapping('field_prop_images:destination_file', 'image_path');
    $this->addFieldMapping('field_prop_images:destination_dir')
         ->defaultValue('public://rightmove/rm_images');
    // Doesn't really matter if we're not copying, but let's provide the "correct" value
    $this->addFieldMapping('field_prop_images:source_dir')
         ->defaultValue('sites/mysite/files/rightmove/rm_images');
    $this->addFieldMapping('field_prop_images:file_replace')
         ->defaultValue(MigrateFile::FILE_EXISTS_REUSE);
    $this->addFieldmapping('field_prop_images:preserve_files')
          ->defaultValue(TRUE);

If you can't tweak that to work, all I can suggest doing is what I did - debug MigrateFileUri::processFile() and MigrateFile::processFile(), printing out the key paths as they're constructed and deconstructed...

With the new array angle here, cross-referencing #1673956: Migrating multiple files.

A note on your observation that I'm using MigrateDestinationFile while you're using MigrateDestinationNode: you can migrate image fields in two ways - directly into the field as you are doing, or you can migrate the files separately (MigrateDestinationFile) then map the results of that migration to your image field using MigrateFileFid. I prefer the latter - I find it cleaner to have the file migration separate from the node migration. And, it probably works better in the array case...

OK, your scenario is definitely not going to work - the loop in MigrateFileFieldBaseHandler that iterates over the image values does not iterate over destinationFile in parallel, and there isn't a way to pass distinct destinationFile values to processFile(). Trying to think of a non-hacky way to deal with this...

Reviewing this, the "bug" remaining is that the linking behavior doesn't work when files are symbolically linked into the Drupal files directory - this is due to core issue #1008402: Allow the use of symlinks within the files directory., and I'm not going to pursue working around it in Migrate.

forgot to include intro text