wrong url from imagecache_create_url() when no clean urls + public downloads
matt2000 - April 1, 2008 - 22:44
| Project: | ImageCache |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs review |
Description
The removal of this requirement was listed as a feature of 2.0, but derivative images are not being generated automatically. I am using CCK imagefield to display the images, which injects a /files/imagecache/preset/myimage.pic'>, but if the image doesn't exist, it's not created. However, if I enter ?q=files/imagecache/preset/myimage.pic into my browser address bar, the image will be created & displayed (on a blank white page, BTW, not inside Drupal.)
#1
Well it obviously works without clean urls if it works with ?q=/path/to/file....
ImageCache injects the path to the imagecache image...
Are clean url's enabled or disabled on your site? This may be an issue with the theme function not printing properly if clean urls are disabled.
#2
It seems to be an issue with the CCK integration.
#3
It is also not working ubercart. I'm using image field cck for for displaying product images. So it turns out to be a cck integration issue.
i'm using imagefield 2.x rc6.
--
Sharique
#4
@matt2000: just how is
supposed to help anyone help you?
@safknw: umm get your own issue and don't post in this one again. please include some details about the problem you are having when you get your own issue. otherwise noone will be able to help you.
#5
I can confirm that clean-urls + imagecache are not your issue... can you detail how your file handling is configured, and how the views displaying the output work? can you paste the actual html output here? maybe the + some wrapping blocks?
#6
File downloads are set to private, stored in '../secure-files/' .
I've got it working now most of the time, but sometimes when the site is loaded by an anonymous user, all the cached images will disappear. (from the page, they still exist on the server.)
The nodes associated with the disappearing images do not have any restricted access.
Imagefield was set to save images in a subfolder of ../secure-files/, but changing this to the main directory doesn't seem to improve anything.
I'm not sure what you mean by "maybe the + some wrapping blocks" ?
Here's an HTML excerpt:
<div class="view view-success-stories"><div class="view-content view-content-success-stories"><div style="display: block; opacity: 0.9999;" class="nodearea success">
<div class="success-thumb"><a href="/ibew229/?q=node/30">
<img src="http://uwsclient.com/ibew229/?q=system/files/imagecache/thumbnail/success_images/hunterstown+drawing.jpg" alt="" title="" class="imagecache imagecache-thumbnail"> </a></div>
<div class="title"><a href="/ibew229/?q=node/30">Hunterstown Combined Cycle Gad Fired Power Plant Project</a></div>
<div class="entrytext"></div>
</div>
<div style="clear: both;"></div>
<div style="display: block; opacity: 0.9999;" class="nodearea success">
<div class="success-thumb"><a href="/ibew229/?q=node/31">
<img src="http://uwsclient.com/ibew229/?q=system/files/imagecache/thumbnail/success_images/Sovereign+Bank+Stadium+3.jpg" alt="" title="" class="imagecache imagecache-thumbnail"> </a></div>
<div class="title"><a href="/ibew229/?q=node/31">Sovereign Bank Stadium, Home of York Revolution Project</a></div>
<div class="entrytext"></div>
</div>
#7
This is indeed an issue with imagefieldCCK integration
The formatters for imagefield generate (absolute) urls of the form
http://example.com/path/to/files/imagecache/preset/image.jpgwhich obviously doesn't work when clean urls are not available (if the image does not exist before).attached patch makes the formatters generate (relative) urls:
/path/to/files/imagecache/preset/image.jpgwhen clean urls are enabled/?q=path/to/files/imagecache/preset/image.jpgwhen clean urls are disabledworks in my setup
#8
If what you say is true, you patch is not fixing the right thing. file_create_url() should generate the proper URL to a file. You patch also will not generate URLs for private files at all since it doesn't use file_create_url.
#9
No, there is no problem with file_create_url(). For example, file_create_url('foo.bar') generates the following urls for the four possible combinations of clean urls and download methods:
No Clean URLs + public downloads : http://example.com/path/to/files/foo.barClean URLs + public downloads : http://example.com/path/to/files/foo.bar
No Clean URLs + private downloads : http://example.com/?q=system/files/foo.bar
Clean URLs + private downloads : http://example.com/system/files/foo.bar
This is correct behavior.
The three last cases are compatible with how imagecache works.
The problem lies however in the first case (no clean urls and public download).
With the current implementation, imagecache_create_url('preset', 'foo.jpg') would generate the url
http://example.com/path/to/files/imagecache/preset/foo.jpgBecause clean urls are not available, imagecache can't catch this request and the image won't be generated nor showed.
The url should be
http://example.com/?q=path/to/files/imagecache/preset/foo.jpg, which can be picked up by imagecache.So what imagecache_create_url('preset', 'foo.jpg') should generate is:
No Clean URLs + public downloads : http://example.com/?q=path/to/files/imagecache/preset/foo.jpgClean URLs + public downloads : http://example.com/path/to/files/imagecache/preset/foo.jpg
No Clean URLs + private downloads : http://example.com/?q=system/imagecache/preset/foo.jpg
Clean URLs + private downloads : http://example.com/system/imagecache/preset/foo.jpg
This can't be obtained with just a file_create_url() call.
But I also agree that my patch of #7 does not works for private downloads, so this is still CNW.
Important side note (it took me some time to figure this out): to test the use cases of no clean urls, it is not enough to disable the clean urls option in the admin interface. Even if this setting is disabled, clean urls are still supported, they are just not generated by default by url() and l(). To really test this you should disable the rewrite module of the webserver or set a bogus RewriteBase in .htaccess for example.
#10
@soxofaan, if everyone filed issues like you my life could be much easier.... :) I'll try to work a patch asap.
#11
well there is a simpletest now... even though the issue is nor corrected... check DRUPAL-5--2 ...
#12
Here is my take on the issue.
I changed imagecache_create_url() from
<?phpfunction imagecache_create_url($presetname, $path) {
$path = _imagecache_strip_file_directory($path);
return file_create_url(file_directory_path() .'/imagecache/'. $presetname .'/'. $path);
}
?>
to
<?phpfunction imagecache_create_url($presetname, $path) {
$path = _imagecache_strip_file_directory($path);
switch (variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC)) {
case FILE_DOWNLOADS_PUBLIC:
return url(file_directory_path() .'/imagecache/'. $presetname .'/'. $path, NULL, NULL, TRUE);
case FILE_DOWNLOADS_PRIVATE:
return url('system/files/imagecache/'. $presetname .'/'. $path, NULL, NULL, TRUE);
}
}
?>
I also added some more documentation to the function.
I also worked on the simpletest test. Note that there is a method drupalVariableSet() that automatically stores the original values of Drupal variables and resets them after the test has run, so there is no need to do that tedious housekeeping yourself.
There is however still a tricky problem with the test. The function url() caches the clean_url setting per page request with an intern static variable. That means that it's futile to change the clean_url setting after url() has run once. The result is that the test are guaranteed to fail now ;)
I think the solution is to make a different page request per _ImagecacheCreateUrlTest() call. I'll have to look into this.
#13
hmm that url() caching issue is annoying good catch... This one is totally committed.
#14
This patch fixes the problem with SimpleTest test mentioned in #12.
Now for each use case a node is created with the PHP evaluator on the body and a proper imagecache_create_url() call in the body. The node view, which is a separate page view, can now be checked if the generated URL is how it should be.
#15
Do paths need to be absolute?
#16
committed to DRUPAL-5--2 and HEAD.
#17
--project followup subject--
Automatically closed -- issue fixed for two weeks with no activity.
--project followup subject--
Automatically closed -- issue fixed for two weeks with no activity.
#18
Automatically closed -- issue fixed for two weeks with no activity.
#19
I'm having this problem as well. There is deffinately a problem here. It's either imagecache itself or an incompatability with another module and variables not being passed.
When I activate the imagecache module a directory is created in sites/default/files/imagecache - Fine. However if I create a preset arbitrarily called 'test' I would have thought that a directory called 'sites/default/files/imagecache/test' would be created - but it isn't.
I have a Prieview link which points to 'mysite.com/sites/default/files/imagecache/test/imagecache_sample.png?1253797544' there is no directory called test and no image called imagecache_sample.png - However!
imagecache_sample.png IS copied to /sites/default/files! Just not to /sites/default/files/imagecache/test.
It's as though the function imagecache_create_url in the file imagecache.module isn't working properly.
On line 321 there is the code:
return url($GLOBALS['base_url'] . '/' . file_directory_path() .'/imagecache/'. $presetname .'/'. $path, $args);
Which for all intents and purposes looks to be ok.
I would like to find the code that saves out the imagecache_sample.png, then I think I could track down the problem slightly more easily - I'm new to PHP but have been a programmer for many years.
The fact that /imagecache/ is hard coded in there would mean to me that it 'must' be another routine or imagecache_sample.png would at least be saved there but it isn't.
This is what I have found so far:
http://www.caspianit.co.uk/imagecache-wrong-path/
And I will post my findings there - all comments gratefully received.
#20
Sorry forgot to mention the modules I'm using - they are the latest as of 24/09/09
Drupal 6.14
imageapi-6.x-1.6.tar.gz
imagecache-6.x-2.0-beta10.tar.gz
imagefield-6.x-3.1.tar.gz
#21
I have this problem as well, I think this is a critical for the few of us who are not using clean URLs on some sites (will be probably changing that soon, but the bug is still there).
I tried to trace back the problem and it seems that in revision 1.100, the patch #366177: Imagecache seems to work only if the file system is set to private that was applied has some difference from the one in #12 which was probably only applied to D5 and I think the one applied has a bug.
The problem I think is just one line:
<?phpreturn url($GLOBALS['base_url'] . '/' . file_directory_path() .'/imagecache/'. $presetname .'/'. $path, $args);
?>
Problem is that the url() function treats absolute URLs (with http://) as external ones, and they don't get processed as internal drupal URLs to properly decide whether to add ?q= or not. Absolute URLs will be generated anyway by url() because the $args tells it so.
Following is the fix:
<?phpreturn url(file_directory_path() .'/imagecache/'. $presetname .'/'. $path, $args);
?>
And attached is the patch
#22
Hello hanoii,
Your patch is working perfectly for me. I just applied it and after flushing my presets, all imagecache images now display.
Thank you very much for your effort.
Cheers,
tamasco.
#23
The patch is working fine for me, as well. I was turning crazy until I found these thread. Thanks a lot, Hanoii
#24
I had some trouble with a site behind a HTTP proxy. The path to the images was an absolute path http://internal.url/sites/[...]/image.png rather than http://external.url/sites/[...]/image.png or better, a relative path.
The problem was fixed with hanoii's patch + "absolute" arg set to FALSE.
Here is the patch.
#25
Dude thanks a bunch!! i have been looking for something like this the entire day =D
Works like a dream!
#26
Any follow-up on this issue from any of the developers? About the patch from #24, it makes sense that the URL are not absolute, or was there a reason for them to be?.
Also, just as a cross-link, I think the following issue #410200: Without clean URLs ImageCache doesn't create folders or images might be a duplicate or be also fixed by this issue. I left there a reference to this issue some time ago.