Hello all, this is great module!

I try to describe the problem as shortly as I can, and then propose a solution for it.

I am building an image gallery. Images are uploaded to a nodes having an image field. Content type is made specifically to have an image plus some keywords and other metadata related to the image. One image per node. Images uploaded are as originals or downsized a bit. Then Imagecache Actions is used to make all the other versions of those images. Large images with watermarks, small images without watermarks for thumbnails and so on. There might be several different versions of single image to use in different views.

Trouble starts here:

If I use public file system path for the image fields, that results as a security problem to my original images. It is very easy to just edit the thumbnail's path in browser a bit to get also the original image file.
If I use private file system path for the image fields, that results as a performance problem for the thumbnails made from the originals (by imagecache actions).

So, I am stuck between performance issue and security problem.

As the private file system really can't be used due the performance issue, my current solution is to make 2 image fields, both in public file system:

First field is for large images having already watermarked, before the image is uploaded to the server, and then that image is used in different sizes, done by imagecache actions.

Second field is for small images without watermark, they serve as a base for few different thumbnails made by imagecache actions.

Now I have fixed the security issue (by doing the watermarks manually on big version of images) and also the performance issue by using the public file system for the image files.
But there is now new problem, and that is the additional work of making 2 images instead of 1 plus also doing the watermark manually. Well, more work, but the thing works then.

(Additionally, 2 images per node makes some other module (Galleria from aino.se) harder to use dynamically, because it presumes there is only 1 image per node - just for example how this problem grows bigger and bigger. I settled down to making static version of Galleria, so it's working at least somehow, but it's again bit more work)

I hope you do see what is the problem here. So far I haven't found any good solution for this, but I have figured out this might be a feature lacking from Imagecache Actions.

And the proposed new feature:

The solution could be an option to choose between public and private file systems every time when you add a new image style. This way you could keep bigger versions of images safely in private file system and smaller thumbnails in public file system which works lot faster.

I have been really wondering around this problem for many weeks, and I believe this might be the correct way to solve this kind of trouble. So far I have been able to build whole site without touching any code, and I try to keep it that way :-)

Any feedback would be greatly appreciated, thanks!

Comments

fietserwin’s picture

This module just defines a set of additional image effects (additional to the image handling that is part of Drupal core and contains some effects and image style handling).

If you have a problem with performance with private files, you'd better target your search for a solution to that area. BTW, I don't see why there would be a performance problem? AFAIK it should be possible to upload the originals to the private part, but create the derivatives on the public file system (why else would there be a directory public under each style name in sites/default/files/styles? This suggests there could be a directory private as well).

dman’s picture

Yeah, what is being requested here relates to *how* image style generation works. We at imagecache_actions only get to affect what happens inside individual processes, not where things get saved at the end.

AFAIK it should be possible to upload the originals to the private part, but create the derivatives on the public file system

That shows that in theory a solution could be built, but there is no actual way to choose or utilize that right now. Current behavior is all-private or all-public.
To add that (quite sensible) feature request to choose the storage mechanism, it will have to be in image processing in Drupal core. Shouldn't be an impossible patch!

That would solve a LONG-standing problem of how you want your originals to be protected but the thumbs to be public. Would be a good solution.

The performance problem mentioned is that all requests to 'private' files involve a drupal bootstrap before files are piped back, compared to public files that are sent back immediately by the webserver using optimized means.

potatosauce’s picture

Ok thank you for quick commenting for both of you!

I read the comments few times to understand better. It looks like I should make request somewhere else concerning the Drupal core, and what particular things it offers to Imagecache Actions to utilize.

If IA focuses on the image editing side, but the file handling and permissions and so on are done by Drupal core, I should find someone who can do some re-designing or some addition in the core.

From my viewpoint, I do understand mostly only what happens in the browser and also something what happens on the server and between browser and server. But I do not know how things are programmatically arranged inside the code, "under the hood" :-)

So, it is obvious I should present the problem to someone who can do something about the core.

But I cannot really explain to him/her, how the core should be changed, to offer the needed functionality or API or something for Imagecache Actions to get this public/private side selection per image style possible. It even might be something else what cracks the problem, but so far as I have seen this, I think it should be some way to define the IA's single image styles to be public or private (with permission checking or something like that).

I'm already thinking that this will be more complicated than I thought :-)

In the perspective of making thumbnails, this thing is really quite big problem. At least when it is a question about making the original image safe, and making only the derivatives public. I searched lot of pages concerning this trouble, and it looks like that bootstrap thing is found elsewhere too, but also the fact that if you get thumbnail viewed, then you get also the original viewed. Like dman said, the bootstrap thing is the performance issue, and if you have like 100 thumbnails on 1 page, it is pretty much unnecessary load for the server.

This is definitely a photographing people's big trouble to get their work online properly, but it could probably affect many other things too.

I hope this case won't be closed unsolved. I just have to figure out where I should present this problem, and also how to present it, because I can perfectly understand that the people maintaining the file handling things are probably prioritizing their work from their own viewpoints which might be completely different than to allow the file field derivatives to have their own set of paths or permissions or something like that.

potatosauce’s picture

I have created now issue in Drupal core. Took quite many weeks I can see, but I hope this leads to something good :-)

The link to the Drupal core issue:

http://drupal.org/node/1903190

fietserwin’s picture

Status: Active » Closed (duplicate)

Closing this issue, now that it is in the core queue.

fietserwin’s picture

Issue summary: View changes

added a sentence or couple to describe better what I am trying to do and how Imagecache Actions is related to it.