Hello everyone,
One of my drupal sites was using the standard files/ directory for file uploads.

I decided to change it to sites/ro.ma/files so that it's in its own place.

Then I updated the files table in database so that all the old files respect the new paths.

Then I cleared cache.

So, everything ok until that, but when I try to upload new files or to access my content type fields using imagecache it doesn't work. Files are evidently not created in the right place. The imagecache directory (sites/ro.ma/files/imagecache) is also empty and without subdirectories.

In example, this is the link to a previously uploaded file:
http://www.ro.ma/sites/ro.ma/files//imagecache/thumb/sites/ro.ma/files/p...

there is for sure some mistake in the path.

How to make everything work good as it was before changing path?

What do I need to do?

Comments

Aldus’s picture

I add that:

- I've set permissions 777 on the sites/ro.ma/files folder and all subfolders
- The imagefield works correctly, it uploads the image and shows the thumb. But after saving the content, imagecache creates nothing :(

raintonr’s picture

This is similar to a problem I have, after doing pretty much the same thing. Only I moved from private->public handling for performance (the public accessibility trade off was worth it) and altered the appropriate database paths in user pictures and files.

Anyhow, I now find that accessing http://my.site.com/files/imagecache/preset/file.jpg re-directs to the site homepage for some reason. I have a custom 'not found' page, one would assume that would be displayed at the very least. I've put some logging into the imagecache.module code and the menu item that is meant to trigger an image rebuild is not being accessed. I have no idea why, have cleared caches, etc.

I'm completely confused by the above.

--- Edit ---
Using wget on the above URL just returns a 404 error so perhaps the redirect is to do with the browser (Firefox on XP). The 404 error is seen in Apache log. This leads me to believe the rewrite rules are not sending a request to index.php as they should be.

This lead me look at the rewrite logging which confirmed the issue.

I then discovered an old .htaccess file in my files directory that had:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
<IfModule mod_rewrite.c>
  RewriteEngine off
</IfModule>

Looking at a newer install, this is now:

SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
Options None
Options +FollowSymLinks

So changed that and the problem is fixed. This would certainly be something to check.
--- Edit ---

What is odd, is that I find accessing http://my.site.com/system/files/imagecache/preset/file.jpg triggers the image rebuild as it should and displays the image. Once this has been done, http://my.site.com/files/imagecache/preset/file.jpg actually works as the derivative is now there in the filesystem.

Figuring out the why the menu is not being triggered is clearly the key, but I just don't see why that is being ignored.

avner’s picture

I tested it on a clean new installation with the same result -
preset is not saved

sgriffin’s picture

I just verified this myself.
I changed from private to public,
set permissions correctly on the new directory and uploaded a new image.
Imagecache failed.
imagecache directory was created but that was it.
I think there is not a "Check" for the current files directory and the files directory is cached in one of its settings.
Running update.php solved imagecache's issue immediately.

picardo’s picture

Having the exact same problem. Running update.db didn't do anything for me though. There are several presets that are working. The new presets I create inexplicably fail. The preset folders are created but the images are not processed.

savageanne’s picture

You've probably checked this already, but I was banging my head thinking that this was my problem, but in fact I had failed to give anonymous users permission to view the relevant CCK field.

geerlingguy’s picture

Same problem here... I switched to private file system and changed paths (to something like /home/user/private/files), and now no imagecache images are being created... the directories are created, but not the images.

geerlingguy’s picture

After a few hours' diagnoses, I finally found out that the GD toolkit wasn't installed on the system to which I transferred my site... it'd be nice if ImageCache would notify if this was not the case (without a visit to the Status page... maybe in the watchdog error log).

The GD image toolkit requires that the GD module for PHP be installed and configured properly. For more information see PHP's image documentation.

Also, for public downloads, make sure that the file system uses a directory structure that ends with the 'files' directory... I had /path/to/files/upload instead of /path/to/files, and that also caused trouble with private file handling and imagecache.

yixia’s picture

As geerlingguy said, it needs GD toolkit.
My problem is that after change the path in file system, image cache failed,
so I try to uninstall the ImageAPI GD2 and re-install it, the image cache could working.

drewish’s picture

Status: Active » Fixed
doublejosh’s picture

Same solution worked for me.

Set file system private... (which I presume changed folder permissions) images were able to be created... then changed it back.

Status: Fixed » Closed (fixed)

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

John Pitcairn’s picture

Having the same or similar problem ... filesystem was initially set to public, with a path of sites/sitename/files.

I then changed the filesystem to private, with a path of ../files/sitename. It's a relative path so the site can be staged between servers, and this has worked well in the past. This was done before uploading any images.

Imagefield uploads work fine, and the raw images can be viewed directly from the specified upload directory (filefield_paths is in use), ie system/files/images/imagename.jpg

Imagecache, when enabled, successfully uploads its preview image to ../files/sitename/imagecache_preview.png

But requests for system/files/imagecache_preview.png return 404. Imagecache cannot show the preview when creating a preset, and it cannot be viewed manually in the browser at that path.

Imagecache creates the ../files/sitename/imagecache directory, but does not create the ../files/sitename/imagecache/previewname directory.

PHP-GD is enabled (MAMP 1.9). Permissions on files directory are read/write for the webserver, update.php has been run, htaccess files in ../files and ../files/sitename look correct. Uninstalled ImageAPI and Imagecache, flushed caches, reinstalled, still no luck.

Er...

John Pitcairn’s picture

Status: Closed (fixed) » Active
John Pitcairn’s picture

OK, further testing:

MAMP 1.9/PHP5.2.13, Drupal 6.20, ImageAPI 6.x-1.9, Imagecache 6.x-2.0-beta10

Test 1:
Clean database install
Leave filesystem set to defaults
Enable ImageAPI, Imagecache
Create a preset - the preview works

Test 2:
Clean database install
Create new directory at ../files/sitename, webserver-writable
Set private filesystem, path ../files/sitename
Enable ImageAPI, Imagecache
Create a preset - the preview works

Test 3:
Clean database install
Leave filesystem set to defaults
Enable ImageAPI, Imagecache
Create a preset - the preview works
Delete the preset
Create directory at ../files/sitename, webserver-writable
Set private filesystem, path ../files/sitename
Create a preset - the preview works

Test 4:
Restore the original site database
Disable and uninstall Imagecache and Image API
Remove any references to those from the {system} and {variables} tables
The {files} table is empty
filesystem is private, path ../files/sitename
Leave the directory at ../files/sitename as-is
Enable Imagecache and Image API
Create a preset - the preview does not work

So I think in this case it's nothing relating to permissions, htaccess or GD. At some point, something in the database has gotten screwed up. I think it's time to give up, get a good strong coffee and rebuild the site. Fortunately it's not too far along.

Summit’s picture

Bookmarking interesting information here, still sometimes also problems with imagecache using Ubercart. looking forward for complete clear exact installation notice.
greetings, Martijn

ryanellis’s picture

Same issue here.
However, it works if logged in as site admin (user 1), so is definitely a permissions issue.
I agree with #15, a strong coffee is needed.

[edit] strong coffee worked!
(i) I set the files folder to chmod 777;
(ii) deleted then recreated the .htaccess file as shown in #2; then
(iii) (foolishly) forgot to set the imagecache preset permissions for anonymous and authenticated users (but I blame the lack of caffeine).

Then it worked!

Hope this is helpful to any caffeine deficient developers.

Cheers,
[redacted]

unc0nnected’s picture

All of these success stories send one on a rollercoaster of hope and despair as none of em work :(

Still stuck, directories not being created in imagecache/ , can't see any images except when set to original.. ugh. Ever feel like it's just one thing after another with drupal sometimes?

No coffee here, but drinkign some strong tea going into hour 8 of working on this problem

charlie-s’s picture

In the same boat. ImageCache works if I set file system to "Private"; for "Public" it neither creates the directories nor the resampled images. I have the .htaccess as noted above (the way it ships with Drupal 6.22).

maddentim’s picture

My experience is that changing the file system location or type of an existing drupal site is problematic. For a while I was putting multiple clients in a shared multisite, but in the end the multisite was way more trouble than it was worth.

Anyway, all sorts entries get made about where the files are that don't get updated when you change the drupal file system configuration.

My advice to all is to use the backup_migrate module. First, make a backup before you start. Then, preferably on a staging site, change the file system to what you want both in actual file system as well as the drupal file system config page. Now backup again -- make sure you don't overwrite the previous backup which it will if you only have the date and not the time in the backup file name!

Then open your backup file in a text editor and carefully hand fix all the references to the old file system setup. Be especially careful if you are changing anything in a serialized value. This is where the value is saved in an array of serialized information. Here is an example of one:

INSERT INTO `rules_sets` VALUES ('rules_set_1','a:4:{s:5:\"label\";s:44:\"Example: Empty rule set working with content\";s:9:\"arguments\";a:1:{s:4:\"node\";a:2:{s:4:\"type\";s:4:\"node\";s:5:\"label\";s:7:\"Content\";}}s:10:\"categories\";a:1:{i:0;s:7:\"example\";}s:6:\"status\";s:6:\"custom\";}');

So where it says {s:5:\"label\"; ... if you wanted to change the string "label" to "labels", you would need to change that 5 to a 6. The s:5 means a string of 5 characters and you now have 6 characters.

When you are finished editing, save the backup and then restore it on the site. If you did it right, your file system references should be all set. Good luck!

fizk’s picture

Status: Active » Closed (cannot reproduce)