Create local copy of image for Imagecache and ThickBox integration

Do you mean that you would like to create imagecache versions of images that were originally uploaded to Flickr? I'd love to make that happen! Flickr is a great tool for managing your images but, websites often have special size requirements that aren't met by the basic sizes offered by Flickr.

I'll try to come back here if I learn more useful information regarding getting this done.

The problem with that is that imagecache actually creates a copy of the image, and emfield isn't pulling the image onto your site, but rather embedding the flickr hosted image on your site. I may be mistaken, but for this to work it would require actually importing the image, which may be outside of the modules scope. (I may be wrong on some of this and will ask Aaron to chime in)

yes, there's an older request for this somewhere in the queue as well. i don't think it would be too technical a challenge (although it would require some finagling to have it store the photo on the local server).

the larger issue is terms of service. it's already possible to tweak the settings in such a way as to break different providers' TOS. i tried to make the module to at least honor them in spirit if not in fact, at least with default settings. however, i'd need to research that more, for hosting those files on our own servers.

on the other hand, it's perfectly reasonable (if improbable) that someone might actually track down someone at flickr or somewhere and get permission to host their images on their server. so in that case, makes sense to allow the module to handle that, just not by default.

by the way, my donation box is paypal: aaron at culturefix d ot or g. :D

aaron

bump. probably after d6 release at earliest.

The image administration and management tools on Flickr are awesome. Drupal will never be able to provide the same level of innovation when it comes to batch image handling and interactive image management.

However, as many have pointed out, Flickr has a very limited when it comes to displaying your images on your site. Something that Drupal excels at (especially when coupled with imagecache and views).

The killer feature is going to be the one that allows me to upload and manage my files through Flickr, then rip local copies of the originals for themeing and customization on my own website. Perhaps maintaining a reference to the original source on flickr and use a field formatter to allow the user to choose the hotlinked file or the local imagecache derivative.

All of this is perfectly within the Flickr TOS. There is nothing that says you can't download your own images for reuse on your own site. That would be crazy.

I agree that this shouldn't be a problem in regards to TOS for the module itself, as long as there is a notice that puts the responsibility on the user when switching on that feature.

I'm in the same situation as Zach...I like the idea of using Flickr as the asset manager for my own content and have partners also supplying in that pool without having to get used to yet another interface. But I will need specific sizes from imagecache and therefore a local file.

Here's a simple snippet as a POC:

/**********************************************
 * Get Flickr pics to local file system
 **********************************************/
// Replace 'content_type_flickr', 'files/my_flickr' and 'field_pic_value' with names valid in your install.

$result = db_query("SELECT * FROM {content_type_flickr}");
$picpath = file_create_path('files/my_flickr');
file_check_directory($picpath, FILE_CREATE_DIRECTORY);
$count = 0;
$max_count = 5;

set_time_limit(500);
while ($f = db_fetch_object($result)) {
  $url = image_ncck_flickr_image_url($code = $f->field_pic_value, $width = 1024, $height = 1024, $formatter = NULL, $field = NULL, $item = NULL, $node = NULL);
  $filename = $f->nid .'_'. $f->field_pic_value .'.jpg';

  if (!file_exists($picpath .'/'. $filename)) {
    if ($count >= $max_count) break;
    $file = file_get_contents($url);
    file_save_data($file, $picpath .'/'. $filename);
    drupal_set_message(t('Saved %file locally.', array('%file' => $filename)));
  }
  else {
    drupal_set_message(t('%file already exists', array('%file' => $filename)));
  }
}

This is obviously not a solution, but merely a point that the thing itself is simple.

The more interesting question is when download should happen. Is it a "sync now" scenario? Most likely not, since you'd want the largest Flickr version and that could be some serious overhead as one big batch job.

So maybe a few on cron, similar to Drupal search indexing?

Or like imagecache on a per-view basis?

Or integrate it into the emfield import procedure, which would be my favourite, but again, not sure about performance impact.

Aaron, could you let me know whether you would be interested in having this as an option and if so, how you'd like it to work. I'll need this functionality regardless, but I'm happy to implement it in a way you see fit for where your module's going.

And I like Zach's formatter suggestion.

Ok, upon looking through the various em modules a bit further, I think the cleanest solution might be a mini module that handles local file saves.

Aaron, I noticed you already have hooks in place for adding field modifications, so I might use those. It would be great to get some general feedback in regards to this, since I'm still getting my head around how this all hangs together...

Thanks for taking this on, Nicolas!

That might be the best place for now. Once we have functionality in place, we can revisit the best place to call it. Feel free to use the hooks, since they're there, and let me know if you need new hooks.

Sorry I've not been available for this task; between the port to d6, writing my book, and work, I haven't had much time for some of these funner tasks.

But I'll try to take a look at what you're doing this week to lend a hand if I can.

Thanks,
Aaron

Thanks for grabbing this by the horns, NicolasH. I need this feature so badly but I lack programming chops to pull it off.

(I drafted the following before I read your post suggesting a mini module. But I figured I'd post it here anyway.)

With regard to syncing, I was thinking the field would have a Widget setting to 'Maintain a local version of this image'. If checked, the local version would be created during the emfield import procedure. Then, in the node edit form, there would be a checkbox to 'Rebuild local version of this image', similar to the 'Rebuild derivative images' checkbox used by the image module. All of this information could be stored in an array and made available at the theme layer. So, in my node template, a field called 'field_my_emfield' might look something like this:

Array(
  [0] => Array
    (
      [local] => Array
        (
          [fid] => 1
          [title] => Example image
          [alt] => example.jpg
          [nid] => 30
          [filename] => example.jpg
          [filepath] => sites/example.com/files/example.jpg
          [filemime] => image/jpeg
          [filesize] => 66180
        )
      [external] => Array
        (
          [embed] => http://www.flickr.com/photos/username/167874516/sizes/o/in/set-72157594166891596/
          [value] => 167874516
          [provider] => flickr
          [data] => Array
            (
              [owner] => 32793221@N00
              [title] => example.jpg
              [description] => 
              [tags] => Array()
              [emthumb] => Array()
            )
         )
    [view] => <img src="http://example.com/sites/example.com/files/example.jpg" alt="Example image" title="Example image" width="700" height="260" />
  )
)

Oh the things I could do with this kind of field.

I like the idea of being able to batch rebuild, or sync these image fields, but for now, but I think it might increase the scope such that we get stymied, and I think something like the above workflow would be a great first step.

With regard to the refresh mechanism, there is an open issue report to address this, which I think could be used for this as well:

http://drupal.org/node/253251

@#11

That's pretty much how I see the field structure as well. The fact that that is essentially what imagefield is, made me ponder a bit whether it could be a straight conversion from emfield to imagefield, but then my head started to hurt, so I'll focus on "local version of emfield for Flickr" for now.

Where I'll most likely need Aaron's input is when trying to make this more extensible for other providers - but I'll leave that out of the equation just yet.

Aaron...an early heads up. I think one additional hook I will need is to add formatters to the embedded image field. I would use the same method that imagefield uses in simply harvesting the presets from imagecache.

Ok, just to keep people in the loop...I have attached a mini module (emlocal) that will copy a Flickr image down into a user-specified directory within "files".

The checkbox for updating doesn't do anything ATM...the file will be downloaded regardless. I need to actually store the local file location and the update setting in the emfield settings database field. With the version attached this only happens on update.

It would be good to get some input from others...

+1 on the concept

I'm not (yet) an EMF user, but I thought I saw that there's an "Import to local Image-module node types from Flickr" somewhere, or am I just confused?

If so then the that's another way to go, due to "Imagecache 4 Image" is a sub-module of the currently shipping dev version of Imagecache. IMO works like a charm. . .

I'm unassigning myself, since there hasn't been any obvious interest from the EMF module developer and we built our own solution.

The whole issue of localising external files might also be a bit bigger than EMF...anyway, just got Aaron's book and look forward to get my head into this space again.

So is this statement true?

There is currently no way to automate the downloading of photosets from Flickr to a Drupal site and the creation of (whatever type of) nodes there.

Other than having someone program it for me of course. . .

That is true.

I plan to look at this functionality again in the next week or two. Thanks for the head start on that, Nicolas! And you got a copy of my book! Wow, cool! They haven't even sent me a copy yet... :(

Good start, NicolasH. We need to make this more generic, and able to handle an image from any provider, whether Flickr or Picasa, or even a thumbnail from YouTube or Blip. Looking at this issue today.

Thanks,
Aaron

Setting this as a duplicate of #300006: Update emthumb to work with Drupal 6 / CCK 2, as I'll roll this functionality into emthumb.