Images do not display in secure filesystem.
ac - November 12, 2006 - 08:59
| Project: | Slideshow |
| Version: | 5.x-1.0 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
The themable function that creates the image markup seems to append 'system/' in front of the relative path (E.g. http://www.example.com/SYSTEM/pathtoimage/image.jpg).
#1
I think this is something to do with the secure file setup. I use IMCE on this test setup too, and that works and it uses the system/ in the file path. Maybe its not displaying for me for someother reason.
#2
Ok this is an issue with private file system. I have changed the title of the bug report. Images are not displaying properly when the file system is set to private
#3
I could not reproduce this issue with private file sytems. Do regular file attachments work? slideshow.module uses the exact same functions. Reopen this issue if you provide information on how to reproduce it. It could be that this problem is caused by imce.module, not by slideshow.module.
#4
I can successfully upload and attach images to a node, they simply do not display properly when the filesystem is private. I have replicated this with IMCE off. Upload module works fine in private mode, as does IMCE. The src of the image seems to be like in IMCE (eg includes system/ in front of the relative path) but the image does not render in the browser for slideshow. IMCE does render images that use this private src.
All I did to replicate was enable private files and upload and attach images to a slideshow node.
#5
I believe you need to add an implementation of hook_file_download because you aren't accessing the uploaded file but rather the scaled file. When you go to the url
system/files/filename.WIDTHxHEIGHT.extthe upload.module can't find that file in its table so it doesn't return any headers. I think you can fix this problem in one of two ways.1. Insert the scaled image file in to the upload.module table (this is probably the proper way to do things)
2. Use the following code to map between the new filename and the uploaded filename:
/*** Implementation of hook_file_download()
*/
function slideshow_file_download($file) {
// Map the slideshow scaled image back to the original uploaded image
$size = variable_get('slideshow_size', '640x480');
$extension = pathinfo($filename, PATHINFO_EXTENSION);
$original_uploaded_file = preg_replace("/$size\.$extension/", "$extension", $file);
return module_invoke('upload', 'file_download', $original_uploaded_file);
}
I had to do this in the 4.7.x version of this module but I am having other problems with the slideshow.module at this point so I can't be sure.
I would rather document my fix here and see if it helps other people while I track down my other problem.
#6
I just realized that the proper code in the 5.x version of this module is:
function slideshow_file_download($file) {// Map the slideshow scaled image back to the original uploaded image
$path = variable_get('slideshow_image_path', 'slideshow');
$original_uploaded_file = preg_replace("/$path\//", "", $file);
return module_invoke('upload', 'file_download', $original_uploaded_file);
}
#7
Yup, I had this problem also. Had to revert to public.
#8
I added a slideshow to a 5.x site with private file downloads and encountered the same problem. The code at #6 resolved the problem.
#9
I do not know the state of the slideshow module, but can this be closed or should a patch be generated? People are still having this issue as of May 2008, would a patch be accepted?
#10
I had this problem and adding the code from #6 to the end of the slideshow.module file fixed so I'd say a patch or version rev would be on order.
#11
Fixed in 2.x-dev
#12
Automatically closed -- issue fixed for 2 weeks with no activity.