Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.)
Comment | File | Size | Author |
---|---|---|---|
#51 | imagecache_241541.patch | 2.94 KB | drewish |
#50 | imagecache_241541.patch | 1.79 KB | drewish |
#38 | optional_absolute_paths.patch | 2.61 KB | kndr |
#31 | 251541_imagecache_create_url_06.patch | 1.48 KB | yingtho |
#29 | 251541_imagecache_create_url_05.patch | 1.49 KB | yingtho |
Comments
Comment #1
dopry CreditAttribution: dopry commentedWell 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.
Comment #2
matt2000 CreditAttribution: matt2000 commentedIt seems to be an issue with the CCK integration.
Comment #3
Sharique CreditAttribution: Sharique commentedIt 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
Comment #4
dopry CreditAttribution: dopry commented@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.
Comment #5
dopry CreditAttribution: dopry commentedI 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?
Comment #6
matt2000 CreditAttribution: matt2000 commentedFile 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:
Comment #7
soxofaan CreditAttribution: soxofaan commentedThis 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.jpg
which 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.jpg
when clean urls are enabled/?q=path/to/files/imagecache/preset/image.jpg
when clean urls are disabledworks in my setup
Comment #8
dopry CreditAttribution: dopry commentedIf 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.
Comment #9
soxofaan CreditAttribution: soxofaan commentedNo, 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:
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.jpg
Because 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:
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.
Comment #10
dopry CreditAttribution: dopry commented@soxofaan, if everyone filed issues like you my life could be much easier.... :) I'll try to work a patch asap.
Comment #11
dopry CreditAttribution: dopry commentedwell there is a simpletest now... even though the issue is nor corrected... check DRUPAL-5--2 ...
Comment #12
soxofaan CreditAttribution: soxofaan commentedHere is my take on the issue.
I changed imagecache_create_url() from
to
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.
Comment #13
dopry CreditAttribution: dopry commentedhmm that url() caching issue is annoying good catch... This one is totally committed.
Comment #14
soxofaan CreditAttribution: soxofaan commentedThis 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.
Comment #15
casey CreditAttribution: casey commentedDo paths need to be absolute?
Comment #16
dopry CreditAttribution: dopry commentedcommitted to DRUPAL-5--2 and HEAD.
Comment #17
drewish CreditAttribution: drewish commentedComment #18
Anonymous (not verified) CreditAttribution: Anonymous commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #19
scifisi CreditAttribution: scifisi commentedI'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.
Comment #20
scifisi CreditAttribution: scifisi commentedSorry 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
Comment #21
hanoiiI 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:
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:
And attached is the patch
Comment #22
tamasco CreditAttribution: tamasco commentedHello 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.
Comment #23
abastida CreditAttribution: abastida commentedThe patch is working fine for me, as well. I was turning crazy until I found these thread. Thanks a lot, Hanoii
Comment #24
florian.cathala CreditAttribution: florian.cathala commentedI 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.
Comment #25
UNarmed CreditAttribution: UNarmed commentedDude thanks a bunch!! i have been looking for something like this the entire day =D
Works like a dream!
Comment #26
hanoiiAny 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.
Comment #27
hanoiihttp://drupal.org/node/410200#comment-2330050 shows another test and confirmation the patch on #24 fixes that issue as well. I think this issue can be moved to RTBC
Comment #28
vivianspencer CreditAttribution: vivianspencer commentedThis patch works great, thanks hanoii
Comment #29
yingtho CreditAttribution: yingtho commentedThe only problem with the patch from #24 is that its not taking into account if the base_path is not at root and absolute should be a variable that the user can choose but defaults to FALSE. See included patch.
Comment #30
hanoiiAre you sure base_path() is needed? I think url() added the base_path() properly. Have you tried it w/o it?
Look at this bit from the url() function:
The $absolute argument since like a good idea, although, why would you want to have an absolute URL in here? It can lead to some problems, like the ones outlined on this issue.
Powered by Dreditor.
Comment #31
yingtho CreditAttribution: yingtho commentedYou are right. I removed the base_path because i noticed the double slahes after the domain name. See new patch.
Comment #32
Oleksa-1 CreditAttribution: Oleksa-1 commentedNice patch,
tested and works as expected
Comment #33
YK85 CreditAttribution: YK85 commentedthanks for the patch - works great
Comment #34
maijs CreditAttribution: maijs commentedSubscribing.
Comment #35
usta CreditAttribution: usta commentedGreat patch!
Comment #36
quartarian CreditAttribution: quartarian commentedDude... I've been waiting for this for a while. You are the best. This patch works great.
Comment #37
kndrSame findings inside http://drupal.org/node/366177 (was marked as duplicated). BTW patch #31 works good for me.
Comment #38
kndrUnfortunatelly, I've stumbled across side effect of #31 patch. I am using wysiwyg_imageupload module (#31 works good) and lightbox2 (#31 works bad). After second thougts, I am sure that changes commited to imagecache should be more safe and backward compatible. First of all, any changes should keep recent imagecache default behaviour (absolute paths guarantee that there will be no more unknown side effects and unknown issues - example, abolute path works good with lightbox2 module) but on the other hand commited changes should give opportunity for other developers to change absolute paths into relative paths (this is important in wysiwyg_imageupload module). Please consider my patch proposal, which retain recent default imagecache behaviour but opens new possibilities for future development. I know, that this kind of patch will not resolve problems immadietely - modules maintainers will have to make changes into own modules but this changes will be small and this way we will be sure, that we avoid unknown side effects with another modules (which works good so far). I am' attaching new patch. There is also little changes inside theme_imagecache function, which will make possible to patch wysiwyg_imageupload module (and many others modules, I think).
Comment #39
rmmcclay CreditAttribution: rmmcclay commentedThanks Hanoii!
Your one-liner, #21, solved my problems with imagecache not creating preset directories.
I tried using Private which kinda worked. But after using your fix, I set it back to
Public which I prefer.
-r
Comment #40
EugenMayer CreditAttribution: EugenMayer commentedTried the patch and it work. Good work!
Comment #41
erickantoniorp CreditAttribution: erickantoniorp commentedHi everybody, i had patched my imagecache.module file with #31 recomendations, and all files are being created at right preset directory. The problem is, i can not see the view, or the gallery i had created. So... it seems like a problem with path.... because when i am logged it apperars, when i logout, i can not see the images... I had set permissions for anonymous user, but my pics still don't appear. So... is there any other function i must change when page will display them?
Thanks
Comment #42
drewish CreditAttribution: drewish commentedThe patch in #38 didn't apply for me and more problematically didn't seem to work for sites in a sub-directory, using public files, with mod_rewrite enabled.
Comment #43
kndrThe patch #38 should be transparent after apllying and it doesn't make any effect withouth changes in other modules. If drupal doesn't work for sites in a sub-directory, using public files, with mod_rewrite enabled it means that imagecache withouth this patch doesn't work too. Here is the sample modification in module wysiwyg_imageupload, which cooperate with #38: http://drupal.org/node/790430#comment-2945562 As I've told #38 will don't work immadietaly - it opens the gate for changens in another modules.
Comment #44
Oleksa-1 CreditAttribution: Oleksa-1 commentedIf there are issues with #38, what about patch in #31 it is tested and works ok (as it mentioned it has some problems only with lightbox, may be this is issue for lightbox?)
Comment #45
kndr#38 is derived from #31 and its logic is exactly the same but #38 requires additional work inside other modules (like wysiwyg_imageupload). In my opinion, better (and safe) way is to make new feature (relative or absolute paths) and describe it in README.txt. This way, other maintainers have the chance to make patches for their own modules. Without #38, it is impossible to change the behaviuor of other modules (which depends on imagecache) since imagecache always return absolute paths.
Comment #46
kndrhttp://drupal.org/node/656516 was marked as duplicated
Comment #47
EugenMayer CreditAttribution: EugenMayer commentedwell i think we still have an issue left, eventhough i think the patch provided does a good job. Those changes need to be done on the patch above:
This is rather wrong. If base_path != /, the absolut path will be right, the relative wont, as base_url includes base_path AFAIK.
So the code here must be
Iam so much dissapointed that the maintainers dont seem to care at all. This is not a minor issue...
Comment #48
drewish CreditAttribution: drewish commentedEugenMayer, if i didn't care i wouldn't have bothered commenting on this at all let alone testing and reviewing the patch in #42. I believe it's a problem but I'm not going to commit a half right fix that'll cause problems for a whole other group of people. Lets focus on getting it right.
I'm not sure your proposal make sense. base_path() is just
return $GLOBALS['base_path'];
. Testing it in a site on the root returns '/' so your code would return '//'. In a subdirectory it returns '/subdir/' so your code would yield '/subdir//'...Comment #49
kndrI've just tested #38 with instalation in a sub-directory, using public files, with mod_rewrite enabled. Wysiwyg_upload (patched with http://drupal.org/node/790430#comment-2945562) and Lightbox2 works good. Drewish, you should give more informations about what went wrong in your environment after aplying #38. EugenMayer, I think that #47 is not neccessary since url() function does the job.
My instalation:
drupal 6.16
cck
filefield
imageapi
imagecache
imagefield
jquery_ui
jquery_ui_dialog
jquery_update
lightbox2
transliteration
wysiwyg
wysiwyg_imageupload
Steps:
1) added imagefield to story content type,
2) created imagecache preset
3) created story with image inserted via wysiwyg_imageupload
4) uploaded some images to filefield
5) set imagefield display to lightbox2->original
Comment #50
drewish CreditAttribution: drewish commentedAfter seeing kndr's comment I retried my testing and couldn't replicate the problem. I'm going to chalk it up to a fluke in my testing environment since it seems to work correctly in the subdirectory. Since the patch didn't apply I rolled my own and incorporated a few docs fixes and changes to the string concatenation.
Comment #51
drewish CreditAttribution: drewish commentedHere's a unified diff for easier reviewing.
Comment #52
EugenMayer CreditAttribution: EugenMayer commenteddrewish / kndr:
You are right, base_url() would be wrong due to url(), i missed that one. Iam also using the patch in #38 since some weeks with a _lot_ more modules then kndr, actually my whole system depends on imagecache. Starting from an icon-framework to user profile api, galleries and so forth. Actually they all seem to work flawlessly.
I have also applied the fix to wysiwyg_imageupload to reuse that relative path argument. That also worked out. Also used the argument in the new implementation of wysiwyg_imageupload, which also worked out.
Summarized i think those changes are quiet robust, as my env. is heavily based on imagecache and all the integrations work.
Happily to see those changes finaly making its way into core.
@drewish: I really think this module needs more co-maintainer. We currently have 147 issues, lets say half of then are unqiue and valid. Thats still a load of work, a load of errors for a module beeing used that often. And i really think that you currently dont care to much about this module, because you work 24/7 on drupal 7. It might be clever to look for people helping you out here, so this great module becomes shiny again.
Comment #53
kndr#51 looks good for me :) Thanks
Comment #54
drewish CreditAttribution: drewish commentedThanks for everyone's patience. I've committed the patch from #51 to HEAD.
Comment #55
EugenMayer CreditAttribution: EugenMayer commentedThanks!
Comment #56
drewish CreditAttribution: drewish commentedalso committed to DRUPAL-6--2, i realized the patch applied fine, i was just working on the wrong branch /me slaps his forehead.
Comment #57
EugenMayer CreditAttribution: EugenMayer commentedHmm could not apply patch of #50 and #51 to beta10. Can somebody reroll it?
Comment #59
kasmel04 CreditAttribution: kasmel04 commentedabsolute pathing breaks http:// -> https:// proxying as the path is built from the source rather than the destination.
I will have to either manually generate paths to images or write a theme function to handle this case.