Imagecache couldn't display or create files anymore after upgrading D6.14

I'm having the same problem. I don't now if it's related to having PHP 5.3

introfini

I've tested in another box with php 5.2.9 and it works great.

@etcetera9 what's your php version?

introfini

same problem here as the original poster.

ubercart generated imagecache images are working fine, but none of my own defined presets work any more, after upgrading to drupal 6,14. even tho' the images are being created on the server, nothing is being displayed.

[i'm running PHP 5,2,9]

FOLLOW-UP:

on further investigation, i'm beginning to wonder whether the culprit may not be imagecache after all. i had the following symptoms:

• image thumbnails and fullsize versions created by ubercart/imagecache were working fine
• image thumbnails created by views/imagecache were not displaying all. instead i was getting a text link which pointed to <full path to appropriate imagecache folder>/<'alt text' for image> so, as opposed to pointing to the name of the image file, the link points to its alt text [???]
• thumbnail images were being created properly by imagecache as i could see them being created on my server
• thumbnail images would also display properly inside the views module when i hit the live preview button - just not on the actual pages themselves
• the views module generated thumbnail images were supposed to link to thickbox popups of the full size image.

since i'm juggling three variables here; imagecache, views and thickbox, i decided to simplify things a bit and so changed the views module output to just generate the imagecache thumbnail linked to the imagecache fullsize , rather than imagecache thumbnail linked to imagecache fullsize displayed in a thickbox popup.

success! - all my imagecache thumbnails are now displaying properly on my pages again and, clicking on them links to the full version [although obviously i've now lost my thickbox ajax popups]. so, i'm now coming round to thinking that the guilty party might actually be thickbox, rather than imagecache.

i realise that, if so, this now becomes a thickbox issue, rather than an imagecache one, but i thought i'd post my findings here, in case anyone else is having similar problems and assuming that the drupal upgrade has broken imagecache.

[Drupal 6.14, ImageCache 6.x-2.0-beta10, Thickbox 6.x-1.5, Views 6.x-2.6]

Same problem here after upgrading.

I have private file system, php 5.2.9

well, i've fixed my problem. it did turn out to have been caused by thickbox, after all. the latest version of thickbox removes a redundant variable in a function that i'd overridden in my site's theme. so imagecache was working all along. it was thickbox which was broken and unable to display the images or thumbnails.

now, it's pretty unlikely that this obscure set of circumstances will be the same ones that are causing the rest of you to have problems, but just on the off-chance, here's the thread wherein i solved mine:

http://drupal.org/node/588616

Yup, same problem as everyone else. I get the imagecache flder being created but that's all that imagecache does. No subfolders, no thumbnails and no images. I'm using Drupal 6.14

My sites/default/files/imagecache directory is fully writable so it's not a permissions thing...

Anyone with any ideas?

having exactly the same problem. whenever I create a new preset a new folder inside of imagecache folder is created and the imagecache_sample.png file is copied there. Once I create and action for that presest the sample image disappears.

Same problem here, imagecache doesn't display thumbnails and can't display when used together with imagefield

I am having a similar problem. The thumb images are now created in files/imagecache_thumbs rather than the previous files/imagecache/thumbs

Is this a problem with specifying where the files are to be saved?

same problem here...... i think we need a patch to fix this fast!

I think I had a similar problem which I just fixed by manually editing the imagecache.module file (gulp...) (and just added a note about this to this node as well: http://drupal.org/node/392100)

I was getting this error:

mkdir() [function.mkdir]: File exists in /home/kcaravan/domains/kitchencaravan.com/public_html/sites/all/modules/contrib/imagecache/imagecache.module on line 555.

(meaning: the directory exists and so imagecache won't create it, but for some reason it also won't create the image in the directory that exists)

I solved my problem by adding a check for the directory by changing line 555 of the imagecache.module file from:

 if (!file_check_directory($dir, FILE_CREATE_DIRECTORY) && !mkdir($dir, 0775, TRUE)) 

to:

  if (!file_exists ( $dir )) { mkdir($dir); }
  else if (!file_check_directory($dir, FILE_CREATE_DIRECTORY) && !mkdir($dir, 0775, TRUE)) 

I'm not a php developer and don't feel confident creating or issuing a patch, but perhaps this will help get to the root of the issue people are reporting?

thanks for the hint rainbreaw but it didnt work for me :(. i still can't see the pictures created with imagecache.

i recognized that the files are created directly in the files/preset directory and not in files/imagecache/preset as before, but the links to the images are still pointing to files/imagechache/preset

Could it be the responsibility of the image api? That's the error that pops up.

I am using imagecache to display FastGallery images and I just recently noticed (after upgrading imagecache Module to vers 6.x 2.0 10 beta) after flushing the cache and rescanning for new pictures that my imagecache directory holds some pictures for the thumbnail preset I use in the gallery but for the big image preset there are just some random pictures present. So no wonder that the Gallery cannot display any of them when clicking on the thumbnail link.
I cannot tell whether this issue came up when I upgraded Drupal to 6.14 .Since some of the pic still work it might very well be I did not notice the problem at that time. Did anyone get ahead on this issue?

Same problem. Just upgraded from Drupal v6.12 to v6.14, and from imagecache 6.x-2.0-beta9 to 6.x-2.0-beta10.

Images no longer are showing up. Tried creating a new preset, and it created the folder just fine. Uploaded an image, and it gets saved in the correct file. Directory permissions are correct.

I'm using private files, so that whole section of my server wasn't touched when I did the upgrade.

I reverted back to 6.x-2.0-beta9, still with Drupal v6.14, and everything works fine again.
I would say the problem is definitely with beta10.

I went back to 6.x 2.0 beta9 and it did not change things for me. When I rescan Fast Gallery for images it claims to create the directory " directory files/imagecache/fast_gallery_thumb/photos/07 has been created" but inside there is only the first thumbnail.

Same problem here, file seems to upload fine to both /files and /imagefield_thumbs directory, however, when viewing the source code on my products page the image is pointing to a folder within image cache, which does not exist and neither does the graphic. I am assuming the presets should be folders within imagecache so I tried to manually create them and tried uploading a graphic, I can upload and it previews fine without errors, but the graphic wasn't found anywhere in the presets folders I manually created. This has to be a bug.

Also, mine didn't happen on an upgrade. I have Drupal 6.13 and php 5.2

So frustrated, I have been at this for hours.

Anybody with insight into this issue? Fixes, workarounds?

Just a reminder to check permissions for the imagecache module and make sure that you have permission to view images from the profile you're using (admin/user/permissions). I forget that step sometimes when I create a new profile and it really messes me up for awhile.

Also, if you're in maintenance mode and have a Private file system it won't display any of the images.

Guys I am on IIS, so I think I am in a different category, working through a fix that someone else posted here, in case anyone else is working in IIS.

http://www.caspianit.co.uk/imagecache-wrong-path/comment-page-1/#comment...

Same problem, I was on 6.13 and it stopped working, not sure when. Upgraded to 6.14 and it still does not work. What is really strange is I have a multi install and sites running the same drupal code base and same modules are not having the problem, only one of the sites is. Same directory permissions. So weird. Any body got anything on this?

(subscribing)

Sounds like I have the same problem (although there seem to be a lot of variants here!)

Recently upgraded from 6.13 to 6.14 & I also recently upgraded from Filefield 3.0 >> Filefield 3.2

Files upload fine and imagefield thumb is created but no imagecache file is created in the pre-existing thumb preset directory

I've had similar problems with IC before. Hopefully this time I can resolve them!

See http://drupal.org/node/410200 also...

Ok I'm running 6.14.
- I've tried ImageCache 6.x-2.x-dev (2009-Oct-08) and 6.x-2.0-beta10.
- I have clean URLs on and public file system.
- Permissions are set 777 on everything and owner is correct
- I've tried all the suggestions about changing this or that or deleting and recreating the .htaccess file
- I've tried this http://drupal.org/node/410200#comment-1709746
- and this http://drupal.org/node/410200#comment-2005114
- as well as this http://drupal.org/node/241541#comment-2118354
- and this http://drupal.org/node/241541#comment-2196200

And nothing works! Again what is really strange is that it's only one site in a multi install, so they're using the same drupal install and the same modules and three work fine and one doesn't. This is killing me.

subscribing

Tried downgrading/uninstalling Imagecache, Imageapi, Imagecache profiles & Views, no luck. Even tried downgrading core to 6.13, which I don't recommend to anybody.

subscribing

Okay, progress:

First thing, if you think you may be going insane, clear your browser's cache.

Second, it seems to be getting stuck in a loop when you upload jpg files. Only jpgs. Pngs and gifs work fine but if I upload a jpg I get "too many HTTP redirects".

Safari says:

Too many redirects occurred trying to open “http://localhost/sites/default/files/imagecache/user_image_default/pictu...”. This might occur if you open a page that is redirected to open another page which then is redirected to open the original page.

Chrome says:

Error 310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.

Firefox and Opera say pretty much the same thing.

I'm not sure if this is the same issue others are experiencing but is sounds similar here is a picture of my issue. (Also how can I subscribe to this?) As shown in the picture the image simply doesn't show up.

I finally solved my jpg infinite loop problem by either uninstalling and reinstalling Imagecache or more likely deleting everything in the sites/default/files/tmp folder. But I have to say I'm a little nervous about using this on a production site with this bizarre behavior.

I had two sites this was happening on. Uninstalling and reinstalling Imagecache worked on one. The other one I noticed a .htaccess file in the sites/mydomain.com/ folder. Once I deleted it it started working again. No idea where it came from, none of my other sites have one in there. Man I spent a lot of time on this.

In tracking down the infinite redirect problem, I discovered that if for some reason you have a stale image creation process in progress, you may end up with invalid images in your tmp directory that cause imagecache to go into an infinite loop.

Fix the problem by clearing your /tmp directory. If you're not sure where that is, open sites/all/modules/imagecache/imagecache.module and add the following code after line 418:

print $lockfile;
return;

Then, load any valid imagecache url, for example: http://example.com/sites/default/files/imagecache//imagecache_sample.png
The printed value is the file that is causing the problem. Delete it. Don't forget to remove your debug code.

this is for the tmp/infinite redirect problem?

Kahenya, you are a godsend. I actually registered just to post this. It works for me on the following:
PHP 5.3.1
Drupal 6.14
Imageapi 6.x-1.6
Imagecache 6.x-2.0-beta10

This problem sneaked up on me while I was upgrading my PHP.

Thanks a lot Kahenya! works for me as well ; )

Thanks a lot Kahenya! works for me as well :-)

#36 needs maintainer's review, right?

Kahenya,

I tried what you said and it did not work. Here is what I did step by step so let me know if I messed up at any step. Thank you in advance.

1. I uninstalled CCK, imagefield, Filefield, image API and imagecache by unchecking them from the modules list.
2. After that I went to the modules folder and deleted the modules out of the folder.
3. I deleted all the folders created initially by imagecache in /sites/default/files
NOTE: I was able to delete all the folders in /sites/default/files by selecting them all but imagefields_thumbs would not delete and I got an error message saying I do not have permission. So I deleted it using command line. Also imagefields_thumbs was the only folder with the subdirectory inside called images from before so there was something that was able to be written in here.
4. After deleted everything I went online and got fresh copies of CCK, imagefield, Filefield, imageAPI, and imagecache
5. Then I opened up imageapi and went to line 164 and made the change.
6. After that I installed the modules again.
7. I tried to create the preset but it did not work as the sample image did not show up.

I could be wrong NareshKosgi (I've yet to try #36 Fix) but I think kahenya meant unistall by going to the "Uninstall" Tab on the modules page (/admin/build/modules/uninstall)

If you simply uncheck the boxes on the main modules page (/admin/build/modules) then you are in fact _disabling them_ and _not uninstalling them_

Be aware that by uninstalling them as described you will lose any data associated with those modules

Always do a backup in case you end up worse off!

Apologies if this is what you'd already done but just clarifying for anyone who's uncertain

Bobuido thanks for the help I am new to drupal and didn't think of that. Thanks for the help. That helped me with some issues with image cache but I still have one last problem..

update on my problem:

Whenever I create an action for a preset the images are never created (and have set the line in 164 and it does not help and made the folders private). Do I need to install GD library or imagemagic library for the actions to occur?

If I set no actions everything works fine (directories are made images are created) but then again there really isn't a point to using image cache if I can't set actions....

However, if i set an action the images are never created in the image cache directory. thanks in advance for any help

-Naresh

Glad that helped :) Everyone's new to Drupal at some point

Yes the actual image actions (e.g. scale) are performed by whatever library you choose - So enable one of them on the Modules Page

Imagecache will require _one_ to carry out any image manipulation - Not both

The Status Report page ( /admin/reports/status ) will tell you some info if you use GD Library - I'm not sure if the same applies to imagemagik (I've only ever used GD so far)

Thanks a lot now everything works!!

Thank you, thank you, thank you!! Kahenya, you're a life-saver, this worked PERFECT for me!

Kahenya:

I spent all day trying to get ImageCache to work; your process finally fixed it. Thanks.

I am having the same problem as #33 and #35 but don't have a sites/files/tmp directory, so I assume no stale image creation process. Uploading .pngs instead of .jpgs works around the problem. 2 questions:

@ #35: Where in the module code should that snipped be inserted? I tried on line 419, but I think my imagecache version is different than what was being used back in dec and the result was a file location that did not exist on my server.

Anything else that could be causing the problem off the top of your head besides a stale proccess / lockfile?

I have not tried kahenya's fix in #36, seems like there are two issues here and theirs is for the other one.

I'm not sure how much that process helped in the end but I was still unable to get Imagecache working after going through Kahenya's steps

I've finally resolved the issue by commenting out some old Apache re-write rules I found laying about. I think they were left over from an old version of our website. I think originally they were implemented for CleanURLs to function but are now obsolete. Or perhaps they were never required in the first place... Regardless, now they're removed all seems well!

If like me you've tried everything, take a look through your Virtual Hosts config and see if there's anything there. If it worked in your dev environment but not on your production server it may be something you've overlooked (although unlikely)

Also just to say I'm running with ImageAPI-dev (as detailed by Kahenya) and beta10 of Imagecache. Thought I'd better try and upgrade given it has a security patch. :)

kahenya: THANKS!

I just made those changes in last imageapi version an imagecache beta 10

old - array_unshift($params, $image);
new - array_unshift($params, &$image);

WORKS

subscribing, is there a permanent fix to this issue?

I had this issue and it seems to be fixed after applying the fix described in #53. Makes sense, because for me, PHP 5.3 introduced a warning that said that imageapi.module was passing by value to a function that expected a reference.

This page talks about the new warning as of PHP 5.3:

http://php.net/manual/en/language.references.pass.php

"Note: There is no reference sign on a function call - only on function definitions. Function definitions alone are enough to correctly pass the argument by reference. As of PHP 5.3.0, you will get a warning saying that "call-time pass-by-reference" is deprecated when you use & in foo(&$a);."

My guess is that somehow this change in PHP's behavior broke the imageapi module.

I did not uninstall or reinstall anything, I just added the ampersand. Seems to work -- so far! Use at your own risk.

This is weird because, looking at the PHP note, it seems like exactly the opposite thing (HAVING an ampersand) should cause a warning.

Found a probably better patch here:

http://drupal.org/node/540486#comment-2616056

Okay this totally seems like a duplicate of the ImageAPI link everyone keeps linking to. That's been fixed and ImageAPI 6.x-1.8 is out so go upgrade and re-open this if problems persist.

subscribe, all the same problems as above

i had the same issue,

what i did is
i changed the directory /files/imagecache permission to 777
and line no 555 on imagecache.module to 0777

hope this helps

The fix above did the trick but only when upgraded to current dev version of imageapi and beta of imagecache

Thanks :)

After trying all the other fixes suggested in the numerous topics about this issue, mbbala's fix in comment #60 made it happen - thanks a ton!

Please note, I had to do the above AND get my host chown the relevent folders to php.

HTH
Chris

I had the same issue (infinite loop when trying to access an imagecache image), but it ended up being the 'tmp' directory contents (as referenced in #36). Deleting the offending temp imagecache image from the 'tmp' directory fixed the issue for me. It seems to occur when imagecache gets more than one request to generate an image in short succession (especially if the image takes a while to generate). The presence of a 'temp working' file in the 'tmp' directory messes up the workflow.

Just my two cents ... none of this is backed up by code exploration - just theorising!

Another post just confirming that emptying the tmp directory solved the infinite redirect issue.

I am also facing the issue. My images are not shown. I was seeing backup option it asked me to create back and try to create a directory and it made every thing worst. now I do not have backup and images are also not shown in my website can anyone help me to resolve