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 Only local images are allowed./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.)


dopry’s picture

Status: Active » Postponed (maintainer needs more info)

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.

matt2000’s picture

It seems to be an issue with the CCK integration.

Sharique’s picture

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.

dopry’s picture

@matt2000: just how is

It seems to be an issue with the CCK integration.

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.

dopry’s picture

Category: bug » support

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 Only local images are allowed. + some wrapping blocks?

matt2000’s picture

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="" 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 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="" 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>

soxofaan’s picture

Title: Clean-URLs still required? » imagecache + CCK imagefield + clean-URLs
Version: 5.x-2.0-beta » 5.x-2.0-rc2
Status: Postponed (maintainer needs more info) » Needs review
708 bytes

This is indeed an issue with imagefieldCCK integration

The formatters for imagefield generate (absolute) urls of the form 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 disabled
works in my setup

dopry’s picture

Title: imagecache + CCK imagefield + clean-URLs » file_create_url does not generate urls without clean urls enabled properly.
Project: ImageCache » Drupal core
Version: 5.x-2.0-rc2 » 5.x-dev
Component: Code » file system
Category: support » bug
Status: Needs review » Needs work

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.

soxofaan’s picture

Title: file_create_url does not generate urls without clean urls enabled properly. » wrong url from imagecache_create_url() when no clean urls + public downloads
Project: Drupal core » ImageCache
Version: 5.x-dev » 5.x-2.0-rc2
Component: file system » Code

No, there is no problem with file_create_url(). For example, file_create_url('') generates the following urls for the four possible combinations of clean urls and download methods:

No Clean URLs + public downloads  :
Clean URLs    + public downloads  :
No Clean URLs + private downloads :
Clean URLs    + private downloads :

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
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, which can be picked up by imagecache.

So what imagecache_create_url('preset', 'foo.jpg') should generate is:

No Clean URLs + public downloads  :
Clean URLs    + public downloads  :
No Clean URLs + private downloads :
Clean URLs    + private downloads :

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.

dopry’s picture

@soxofaan, if everyone filed issues like you my life could be much easier.... :) I'll try to work a patch asap.

dopry’s picture

well there is a simpletest now... even though the issue is nor corrected... check DRUPAL-5--2 ...

soxofaan’s picture

Status: Needs work » Needs review
7.68 KB

Here is my take on the issue.

I changed imagecache_create_url() from

function imagecache_create_url($presetname, $path) {
   $path = _imagecache_strip_file_directory($path);
  return file_create_url(file_directory_path() .'/imagecache/'. $presetname .'/'. $path);


function imagecache_create_url($presetname, $path) {
  $path = _imagecache_strip_file_directory($path);
  switch (variable_get('file_downloads', FILE_DOWNLOADS_PUBLIC)) {
      return url(file_directory_path() .'/imagecache/'. $presetname .'/'. $path, NULL, NULL, TRUE);
      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.

dopry’s picture

Status: Needs review » Fixed

hmm that url() caching issue is annoying good catch... This one is totally committed.

soxofaan’s picture

Version: 5.x-2.0-rc2 » 5.x-2.x-dev
Status: Fixed » Needs review
8.12 KB

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.

casey’s picture

Do paths need to be absolute?

dopry’s picture

committed to DRUPAL-5--2 and HEAD.

drewish’s picture

Status: Needs review » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

scifisi’s picture

Version: 5.x-2.x-dev » 6.x-2.0-beta10
Status: Closed (fixed) » Needs review

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 '' 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:

And I will post my findings there - all comments gratefully received.

scifisi’s picture

Sorry forgot to mention the modules I'm using - they are the latest as of 24/09/09

Drupal 6.14

hanoii’s picture

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:

return 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:

return url(file_directory_path() .'/imagecache/'. $presetname .'/'. $path, $args);

And attached is the patch

tamasco’s picture

Version: 6.x-2.0-beta10 » 6.x-2.x-dev
Priority: Normal » Critical

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.


abastida’s picture

The patch is working fine for me, as well. I was turning crazy until I found these thread. Thanks a lot, Hanoii

florian.cathala’s picture

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.

UNarmed’s picture

Dude thanks a bunch!! i have been looking for something like this the entire day =D

Works like a dream!

hanoii’s picture

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.

hanoii’s picture

Status: Needs review » Reviewed & tested by the community shows another test and confirmation the patch on #24 fixes that issue as well. I think this issue can be moved to RTBC

vivianspencer’s picture

This patch works great, thanks hanoii

yingtho’s picture

The 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.

hanoii’s picture

+++ imagecache.module	21 Jan 2010 09:19:58 -0000
@@ -309,16 +309,16 @@ function imagecache_action_definition($a
+      return url(base_path() . file_directory_path() .'/imagecache/'. $presetname .'/'. $path, $args);

Are 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:

  $base = $options['absolute'] ? $options['base_url'] .'/' : base_path();

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.

yingtho’s picture

You are right. I removed the base_path because i noticed the double slahes after the domain name. See new patch.

Oleksa’s picture

Nice patch,
tested and works as expected

YK85’s picture

thanks for the patch - works great

maijs’s picture


usta’s picture

Great patch!

quartarian’s picture

Dude... I've been waiting for this for a while. You are the best. This patch works great.

kndr’s picture

Same findings inside (was marked as duplicated). BTW patch #31 works good for me.

kndr’s picture

Unfortunatelly, 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).

rmmcclay’s picture

Thanks 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.


EugenMayer’s picture

Tried the patch and it work. Good work!

erickantoniorp’s picture

Hi 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?


drewish’s picture

Status: Reviewed & tested by the community » Needs review

The 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.

kndr’s picture

The 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: As I've told #38 will don't work immadietaly - it opens the gate for changens in another modules.

Oleksa’s picture

If 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?)

kndr’s picture

#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.

kndr’s picture was marked as duplicated

EugenMayer’s picture

well 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:

$base = $absolute ? $GLOBALS['base_url'] . '/' : '';

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

$base = $absolute ? $GLOBALS['base_url'] . '/' : base_path();

Iam so much dissapointed that the maintainers dont seem to care at all. This is not a minor issue...

drewish’s picture

Status: Needs review » Needs work

EugenMayer, 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//'...

kndr’s picture

Status: Needs work » Needs review

I've just tested #38 with instalation in a sub-directory, using public files, with mod_rewrite enabled. Wysiwyg_upload (patched with 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

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

drewish’s picture

1.79 KB

After 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.

drewish’s picture

2.94 KB

Here's a unified diff for easier reviewing.

EugenMayer’s picture

drewish / 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.

kndr’s picture

#51 looks good for me :) Thanks

drewish’s picture

Status: Needs review » Fixed

Thanks for everyone's patience. I've committed the patch from #51 to HEAD.

EugenMayer’s picture


drewish’s picture

also committed to DRUPAL-6--2, i realized the patch applied fine, i was just working on the wrong branch /me slaps his forehead.

EugenMayer’s picture

Hmm could not apply patch of #50 and #51 to beta10. Can somebody reroll it?

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kasmel04’s picture

absolute 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.