Option to "download" original image

I concur. I use the image gallery for backgrounds, and many non-technical users do not know how to get the image downloaded.

There's also a method of using a PHP file to "force download" an image (http://elouai.com/force-download.php). This could also be an option.

Again, please consider this.

After doing some further research, I've figured out how to force a download of the image. This could be made as an option, but I've only done hard coding as of now. (This could probably be a seperate issue, but it depends on this module). This may break something else, so please double check it multiple times. I've only added the "Content-Disposition.." line. I think it also causes the size of the file to be unknown for the user agent, so, if there was any way to pass a file size in a header, that would be a good idea as well.

function image_file_download($file) {
  $size = image_get_info(file_create_path($file));
  if ($size) {
    $headers = array('Content-Type: ' . $size['mime_type'],
      'Content-Disposition: attachment; filename="'.$file.'"'); //changed
    return $headers;
  }
}

Updated to patch to head, and I also added in the forced download. I added a new item to the access controls, "download images", to show the link to the correct users. I tested it somewhat, and it seems to be working.

I don't think a developer for the image.module has commented, so it would be nice to hear what you think about the idea.

Keeping up with head

[bump]

Sure would be nice to have some feedback. If nobody wants this, I'll stop messing with it, but I personally think it's needed.

+1 from me on the concept. Didn't have time to review the patch yet.

i want this! any movement on it - i've been searching for something like this all day!

Lucy

Has this been already implemented in the Image module? Or is it an addon?

This is really useful, thanks.

I don't think it's been implemented yet, but I gave up on it since I really didn't get any response from the developer. I don't think he's been doing much with the module lately anyways.

Updating the patch against head. I'd appreciate some kind of feedback from the maintainer if possible.

*bump*

Would this be better as an add on module? Is there a better way to implement this? Any feedback is better than no feedback.

Does anyone care anymore?

Yes, but it's up to the module owner to add it, unfortunately.

i don't think it should be a specific permission but rather an options to show the link.

I can't get any of these patches working with the latest 5.1 image module... Last one is the closest, but the first chunk (on line 38 if i remember correctly) fails. I can't find any other good solutions to this, so... *bump*

This is a nice feature. I've updated the patch against the DRUPAL-5--1-2 version. I also added the Content-Length header, so the browser will know the file size and display the progress bar appropriately.

thanks!

i really don't like that patch... and it won't apply to HEAD any more. i'd rather this be added to the $link_options in the image_admin_settings() so the admin can select which sizes the want downloaded.

I would love to try this, but am confused on where exactly I put this patch- I am assuming it either overwrites the image.module file or appends it. Additional tips for newbies would be helpfull.

webiedesign, see: http://drupal.org/patch/apply

Been searching and searching to solve this issue. After much fiddling I have the my Image Collections working the way I need them to except for an automatic link to download the original. If I edit each image separetly I can get the link in by selecting the File attachements - List _original.
But for thousands of images that is kind of a nightmare.
Can anyone tell me how to make this option automatic in the code somewhere?

Did anyone ever respond to merrillie? I would sure like to be able to permit the "download original" link as an option while importing or something (so it doesn't have to be done image-by-image)! Maybe there is a solution to this by now, but I haven't seen it yet.

No response, I am still having to edit each image seperately and tick the list _original file attachment.

I haven't had a chance to play with the newest version that also includes the view module but I suspect it might be possible to find a solution there. I get scared to update anything to do with my image galleries as I sometimes get these horrible derivative messages which now only come when I attempt upgrades.

On a last note I am loving the image module for displaying my image collections.

Patch against 5.x-2.0-alpha1

tracking

+1 Ive been looking for something like this

+1 Ive been looking for something like this

-function image_file_download($file) {
+function image_file_download($file, $download = NULL) {

You can't go changing the arguments on a hook implementation!

Re: "You can't go changing the arguments on a hook implementation!"

It won't make any difference to existing calls to this function, so why not?

+++ image.module	(working copy)
@@ -51,7 +51,7 @@
-  return array('create images', 'view original images', 'edit own images', 'edit images');
+  return array('create images', 'view original images', 'edit own images', 'edit images', 'download images');

Please remove the permission - it's senseless, because everyone can access/download original images, and we already have the "view original images" permission.

+++ image.module	(working copy)
@@ -408,7 +408,8 @@
-function image_file_download($filename) {
+function image_file_download($filename, $download = FALSE) {
@@ -422,10 +423,12 @@
+          if ($download) {
+            $headers[] = 'Content-Disposition: attachment; filename="'.$filename.'"';
+          }
@@ -812,7 +822,7 @@
-        $headers = image_file_download($file);
+        $headers = image_file_download($file, $download);

As joachim already mentioned, we won't add a custom argument to a hook.

Instead, the returned array can be altered in our function.

+++ image.module	(working copy)
@@ -467,6 +470,13 @@
     if (!user_access('view original images')) {
       unset($links['image_size_'. IMAGE_ORIGINAL]);

Additionally, this should cater for the existing user permission.

+++ image.module	(working copy)
@@ -467,6 +470,13 @@
+    if (user_access('download images')) {
+      $links['image_download'] = array(
+        'title' => t('download'),
+        'href' => 'image/view/'.$node->nid.'/_original/download',
+        'query' => 'size='. IMAGE_ORIGINAL,
+      );
+    }

Like drewish already mentioned, this should be added to the $link_options in the image_admin_settings(). so the admin can select which sizes get a download link.

Beer-o-mania starts in 20 days! Don't drink and patch.

Subscribing. I really need the ability to download the actual original, not the current _original dealio.

Not sure what you mean about 'actual original' vs _original -- _original is the saved file. If you uploaded something larger, it's not there.

I mean that image appears to process _original from the actual original. It takes /images/picture.jpg and gives you node/_original. There's no way for me to protect that file via htaccess because that is a virtual path and not a physical path. Plus, it's slower to download because image goes through the pain of processing it. What I'm saying is I'd love for the ability to have download original actually point to /images/picture.jpg so that the actual original pops up in a new window instead.

Once image has token support, or Filefield Paths has full image support, then I can do this myself via Custom Links. But I'm not sure why Image goes through the process of serving node/_original instead of just using the actual file path.

Can't you just go to admin/settings/image/nodes and set 'original' Link to 'New window'?

No I can't, that's what I'm saying. If you choose that, the file you get is drupal/image/view/nid/_original which is not a physical path instead of drupal/sites/default/files/images/folder1/12345.jpg which is the actual path.

I don't understand your point here.
Is the existing URL broken, or merely undesirable, and if so, why?

It's not broken, it's undesirable, for multiple reasons.

1) Because it is not an actual directory, I can not protect it with htaccess, which I use to maintain a premium membership level.

2) Because it processes it in some way, it is slower. When I use Lightbox to grab the actual original, it is instantaneous. Clicking download using this method takes a few seconds to start downloading.

3) Because it's not an actual file, people can't save it easily. I would be forcing them to come up with their own filename for every file they wish to save because every single file is _original. Also there is information in the filenames I don't want to lose, like subject and author.

Those are my main three reasons. I can see how the current method would be useful, but I think this other method would also be a very useful alternate option.

And again, I can get around this once there is token support with the help of custom links.

It's a Drupal path rather than a physical path precisely so you can have a 'view original images' perm, I think.

So, does this mean there is an option to simply download/view in browser?

1) Viewing the original image, it doesn't fit into theme - that is the themes problem (I understand, but having a failsafe option in adjacent modules is a benefit)
2) If Original "link" went to the file instead, it would load in its max resolution and be completely visible to anyone with a proper browser (or browser linked to an image viewer)
3) I may have completely missed something, please let me know

Otherwise this module is doing very well, many uploaders and very patient viewers.

I haven't a clue what the last two attachments are trying to show me.

This issue will move forward when: someone fixes the patch, and other people test the new patch.

You might want to check out the File Force module: http://drupal.org/project/file_force

hey there guys,

I've been working on this within the rewrite of the file_force module - see #358800: Image module support for this particular part of that. However, there is a slight problem with the implementation of the image_fetch function in the Image module, as reported in #883338: image_fetch calling hook_file_download directly - I'll wait for that to get fixed first and then commit my changes to the file_force module.

PS. Once all this is done, file_force will be ready for release, so you're all welcome to grab it and give it a test run ;)

Cheers,
Martin

I've posted a patch at #883338: image_fetch calling hook_file_download directly but I'm away from my localhost right now and can't test it.

Moreover, the sort of testing this patch needs is with the interactions with all sorts of other modules this change will result in -- so if you are subscribed to this issue, please go and test that patch with all your various configurations.

Hey guys,

I would like to advertise the File Force module as it now supports a new type for Image node links that will make the user's browser download the image scale of your choice. (See #358800: Image module support for the particular issue.)

2.1 release with all these and many other features is out now by the way! :)

Looks like great stuff arski!

Does this module address the original request in this issue? If so, we can close this :)

Yeh, you can go to admin/settings/image and select "File Force" in the "Link" column for the original image and/or any image scale. So I suppose that does take care of this request :)

Great!

Closing as 'won't fix' since technically this is happening in another project.

I'm not sure if the File Force module really solves this problem.

I think the TS was looking for a way to view the actual original image through a direct link to the actual file, and not to the "_original" alias for usability reasons. For example, the link pointing to the "Original" image should point to www.example.com/sites/default/files/example.jpg instead of www.example.com/node-title/_original for reasons explained by "2noame" in post #41.

I made a small patch to add a new link option to the Image settings page. It's really simple and I don't think it causes any problems, but I'm no drupal expert so I might be wrong.

The included patch adds a "Direct link to image" link option to admin/settings/image (in addition to "Hidden", "Same Window" and "New Window").

Perhaps this should be included in the Image module?

Could you roll this as a single patch on the project please?

I'm not sure if I did it right, but here's the patch against 6.x-1.0-beta6.

I missed this due to the status not being changed.

Anyone care to review?

Well, I know nothing about patch reviewing, but I just applied patch in #54 to Image 6.x-1.0 ( not beta6 ) and everything went smooth. It works as expected except one thing: if site is multilanguage and uses path prefix, then direct link to image is formed with this prefix ( like http://example.com/ru/images/test.jpg ). So with no surprise it throws 404 error due to wrong path. But seems like it's not Image module issue, or maybe this can be somehow "hacked"... I don't know.

Well, that's a patch review! :D

You applied it, tested it, and found it mostly works but not quite. Hence we set the status to 'needs work'. Thanks for reviewing!

(IIRC, the matter of path prefix on multilingual sites has already come up -- whoever takes this up should search the past issues for clues.)

Tested the patch with Drupal 6 1.0, works fine over here (haven't tested with prefixes as above).
You can see it at work here for example: http://www.indigorenderer.com/node/1050

You sure that's working? I see 'Seat Leon-studio cam02' but it's not a link.

Subscribing.

I tried either File Force and Download File modules and found they do different things from what requested. Actually the point is to add a link to the original file (e.g. http://example.com/files/images/example.jpg) instead of embedding the original image in a page.