A brief explanation of this bug is in post #4
I'm trying to migrate files from myoldsite.com/gallery which has a 'data' folder and category numbered subfolders like:
/home/myoldsite/public_html/gallery/data/501/house.jpg
/home/myoldsite/public_html/gallery/data/501/plane.jpg
/home/myoldsite/public_html/gallery/data/504/house.jpg
/home/myoldsite/public_html/gallery/data/506/tree.png
The corresponding MySQL db 'photos' source table looks like:
| id | user id | cat | bigimage |
---------------------------------------------------------
| 1 | 32 | 501 | house.jpg |
| 2 | 68 | 501 | plane.jpg |
| 3 | 12 | 504 | house.jpg |
| 4 | 25 | 506 | tree.png |
I want to keep the images in their original folders, so I've FTP'd the 'data' folder to D7's sites/default/files, which now looks like:
sites/default/files/data/501/house.jpg
sites/default/files/data/501/plane.jpg
sites/default/files/data/504/house.jpg
sites/default/files/data/506/tree.png
Using MigrateFileFieldHandler I've set up a migration as
$image_arguments = MigrateFileFieldHandler::arguments(null, 'file_link', FILE_EXISTS_ERROR);
$this->addFieldMapping('field_image', 'bigimage')
->arguments($image_arguments);
with prepareRow
public function prepareRow($current_row) {
$current_row->bigimage = 'sites/default/files/data' . '/' . $current_row->cat . '/' . $current_row->bigimage;
}
file_link shows the original images OK, but it doesn't enable imagecache versions for 'preview/thumbnail etc' to be created. I take it file_link files aren't entities in Drupal, even if the files are in the sites/default/files folder?
Comments
Comment #0.0
StuartDH commented.
Comment #0.1
StuartDH commented.
Comment #0.2
StuartDH commented.
Comment #0.3
StuartDH commented.
Comment #0.4
StuartDH commented.
Comment #0.5
StuartDH commented.
Comment #0.6
StuartDH commented.
Comment #0.7
StuartDH commented.
Comment #0.8
StuartDH commented.
Comment #0.9
StuartDH commented.
Comment #0.10
StuartDH commented.
Comment #0.11
StuartDH commented.
Comment #0.12
StuartDH commented.
Comment #0.13
StuartDH commented.
Comment #0.14
StuartDH commented.
Comment #0.15
StuartDH commented.
Comment #0.16
StuartDH commented.
Comment #0.17
StuartDH commented.
Comment #0.18
StuartDH commented.
Comment #0.19
StuartDH commented.
Comment #0.20
StuartDH commented.
Comment #1
StuartDH commentedDoes only file_copy create entities, or can file_move be used?
Comment #2
StuartDH commentedAll file_copy files are ending up in /sites/default/files/data/ without the 'cat' numbered subfolders, i.e.:
/sites/default/files/data/house.jpg
/sites/default/files/data/plane.jpg
I've tried using public function prepare, but it doesn't seem to help in setting the destination path
Is this a bug? It looks like file_copy isn't copying the complete source path to the destination path
Comment #3
StuartDH commentedMigrationFileFieldHandler doesn't seem to work as desired, so I've created a class just to get the files in Drupal as entities:
The above sources the files correctly, the destinations now include the 'cat' subfolders, and I can see the images in Media's view library etc, but the resulting uris are
sites/default/files/pictures/sites/default/files/data/501/house.jpg
sites/default/files/pictures/sites/default/files/data/501/plane.jpg
and I'd like to shorten them to just
sites/default/files/pictures/data/501/house.jpg
sites/default/files/pictures/data/501/plane.jpg
More importantly, I can't get the above files to map in a subsequent MigrateDestinationNode when using something like:
with prepareRow
The files map to field_image (a field in my 'photo' content type), but the file destination changes to just sites/default/files/
any ideas?
Comment #4
StuartDH commentedI think I might have found the issue...
Using MigrateFileFieldHandler or mapping in MigrateDestinationNode, if you migrate a file into a content type's field_image field, the file is saved to the directory that's set in the field's destination settings - admin/structure/types/manage/photo/fields/field_image
All mapped files seem to flatten and adopt the above setting. If nothing has been set in the file destination's box the folder structure of the files is still overridden and all files flattened into the default /files folder.
Is it possible to change the field mapping in migrate to ignore the above settings when setting the destination for files?
Comment #4.0
StuartDH commented.
Comment #5
StuartDH commentedI'm changing this to a bug as it doesn't look as though file field mappings are being created as expected
I've just done a quick check and it looks as though file_move creates the same result, i.e.
using the same prepareRow as above
Comment #6
aendra commented+1 Subscribing
(Thanks StuartDH for pointing me towards this issue).
Comment #6.0
StuartDH commented.
Comment #7
StuartDH commentedI'm trying to find a workaround for this by using entity tokens/taxonomy tokens/field tokens etc to see if the file directory of the field_image can be set by other fieldmappings (my 'cat' terms) during import.
So far, no luck. Has anyone else managed to get results this way?
Comment #8
mikeryanConsolidating with #1120136: Option to flatten or preserve file hierarchies on import - the broader issue is that both the file destination and the file field handler should allow you to specify whether or not to maintain the existing hierarchy. This will all be part of the effort in Migrate 2.4 to refactor file handling: #1240928: META: Refactoring of file destination/field handlers.
Comment #9
mototribe commentedthank you Stuart for posting all the examples, it really helped me with my photo migration!
Comment #10
Fidelix commentedComment #11
aendra commented@StuartDH -- Any idea how to create filefield entities within another entity? I ask because I'm trying to migrate my existing folder structure with filefieldhandler (which doesn't seem to work, nor will seem to work for the foreseeable future), but can't create entities directly -- I'm using the field collection field handler to populate field collections, within which are my image fields.
Any thoughts? Thanks!
Comment #12
StuartDH commentedDo you mean getting image fields to show in something like an Article content type?
If so, the nearest I got was manually copying a folder (with subfolder) then using file_link like post #1
The images showed up in the content type, but I couldn't seem to create thumbnails etc for them
Comment #13
aendra commented@Stuart -- Great, thanks for the help! I ended up doing that, then using phpThumb to manually resize all the images. Here's the code I used, for anyone else needing to do this before the shiny redone file handling comes out in 2.4:
(Not visible here: I included ThumbLib.inc.php in the constructor so it's available later on.)
Hope this helps someone!
(Edit 2012-04-14: fixed typo and changed the thumbnail creation routine to redo the phpthumb create method for each -- otherwise, square thumbnails try to resize the 100x100 thumbs and looks awful)
Comment #14
jamesrobertson commentedre post #13
@aendrew - been looking for a resize image function to use with Migrate. Just want to check before I spend too much time...
is the method...
$this->resize_thumbs($current_row->file);
referring to...
private function resize_thumbnails($path)
if so - is this just a typo?
Comment #15
aendra commented@James -- Yes, that's totally a typo. Fixed in the above code; thanks!
Comment #16
jamesrobertson commentedImporting an image from your oldsite (on a different server) is made really easy with phpThumb (thanks to @aendrew for introducing it to me)
I am pulling database information and files from www.djmag.com NOT /home/djmag/www
In the main ...NodeMigration class I have created an external connection (have a look at cross-database migrations)
So database stuff comes from this connection
But I want to pull files as well - so I have created this file mapping (see the beer.inc example for a better explanation)
and then I have created these few lines of code in the prepareRow() function
}
I really hope this helps people who don't want to copy files (in bulk) from their existing server to their new server in order to effect a migration. But want to be able to do it selectively and on the fly. There maybe many reasons for this... a) there is no need to, b) you may still be using the old server whilst the switch is being made, c) you may want the same information on two different servers...
I am new to Drupal and programming so please forgive some of my terms, but I hope this helps - I couldn't find information anywhere about this.
By the way (and drush will remind you of this) if you are using Migrate to pull info off another server remember to have the necessary migration tables on that other server - 'migtate_map_...' and 'migrate_message_...'
Lastly - thank you so much @mikeryan for this wonderful module
Comment #16.0
jamesrobertson commented.