Imagecache can't write files to symlinked non-standard location

Looking at it...
You have migrated a site that used to be located in the default directory and are now serving it from a {sitename} multisite location.
Fair enough, but there ARE going to be side effects.

In this case, the system - the database - still thinks your original images are in the old default path.
Look at the SQL 'files' table.

However the new system settings know you've started to use the new /sites/bustedinaustin.com/files/ path.
(remember that warning that says "do not change the files directory on a working site" ? Yeah, what it says.)

The system (image.module) retrieves the old image path from the DB : sites/default/files/images/Austin_v2i5_front_0.jpg

Says "Is this path recognised as including the files dir /sites/bustedinaustin.com/files/? No? Then it must be underneath the files dir!" ... and glues the paths together. Giving you the long wrong version.

This is a weakness of the image module and the Drupal6 filesystem in general, that it used to save the full path to such files.

You should find that your image nodes themselves are all invalid, even without imagecache, due to this.

Until Drupal 7, the work-around is a search & replace in the files table of the DB. Or symlinks.
Or heck, copy (or link) all your old files over to where it's looking for them!

cp -r sites/default/files sites/bustedinaustin.com/files/sites/default/files
... messy as, but it may help until you clean up the DB.

Cool.
Here's a better title for those who come looking next time.

I'm having a similar problem to this.

When calling the image, it generates the address:
/sites/default/all/imagecache/preset/IMAGE
When it should generate:
/sites/default/all/imagecache/preset/sites/default/all/IMAGE

The file's path is being saved properly to the database, imagecache is just having a hard time adding the file system's path before the file name.

I've uninstalled and reinstalled the image module, I've flushed caches, and now I feel like I have nothing left to try. I know I could just change the file system to the base, but that's messy. And I know I could just write a PHP script to direct it to the right file, but that's also messy.

Any thoughts?

It look slike your problem is something quite different.
The example paths you listed do not include the files/ directory, so something is wrong there from the beginning.

That was actually just a mistake on my part when I was transcribing the problem. Thank you for pointing it out. The actual paths:

When calling the image, it generates the address:
/sites/default/files/imagecache/preset/IMAGE
When it should generate:
/sites/default/files/imagecache/preset/sites/default/all/IMAGE

Are you still a bit confused? sites/default/all ???
Seeing as this issue is about moving away from 'default' and into a named multisite - why doesn't your multisite name appear in the URL? Transcription problems again?

If the source image was
/sites/default/files/IMAGE.jpg
Then the derivative is expected to be found at
/sites/default/files/imagecache/presetname/IMAGE.jpg
This is correct. If a file starts within the files dir, the files dir is not repeated in the imagecache path.
I don't know why you are inserting 'sites' into your expected path/

It's possible to run it on a path outside of the files dir, eg
/sites/all/themes/mytheme/IMAGE.jpg
Then the derivative is found at
/sites/default/files/imagecache/presetname/sites/all/themes/mytheme/IMAGE.jpg

What imagecache does is
- take a request for the path under a presetname
- look for a file matching that request directly underneath the sites files/ dir
- if not found, look relative to the drupal root.

Thus you CAN (if you are mad) ask for both
/sites/default/files/imagecache/presetname/IMAGE.jpg
/sites/default/files/imagecache/presetname/sites/default/files/IMAGE.jpg
... and both will return the same result.
But only the first one is normal, expected, and created by the imagecache api calls. The second syntax is not right.

Then perhaps there is a larger problem that I am missing.

The generated path is
/sites/default/files/imagecache/presetname/IMAGE.jpg
And the place that the image is properly being stored is
/sites/default/files

If that should be generating a picture, but isn't...then what could be wrong?

For reference, when I visit
site.com/sites/default/files/imagecache/presetname/sites/default/files/IMAGE.jpg
...the image is loaded properly.

**EDIT:
Upon further inspection, the image is not loading properly at site.com/sites/default/files/imagecache/presetname/sites/default/files/IMAGE.jpg.
It isn't throwing the same 404 error that the currently generated link throws, though.

After switching from ImageMagick API to GD2 the problem went away. All of them.

I apologize for the inconveniences. I've been tweaking things to get ImageCache working for a while and I guess in the process I switched to ImageMagick API.

**EDIT: I don't know why this fixed the single image's issue.

Correction...

The one file I'd been trying to get to load finally loaded.

Newly updated files and other presets are not working, still.

**EDIT:
site.com/sites/default/files/imagecache/presetname/sites/default/files/IMAGE.jpg
The long path works (with GD2). The short path does not.

***EDIT 2:
If I look for the picture in the long path, it creates the picture and then I can find it using the short path. I guess image creation isn't working properly...

***THE FINAL EDIT (hopefully):
Although the temp directory was listed as writable in the File System tab (and is writable), changing it to a new directory that I created seems to have fixed the errors.
**crosses fingers**

To fix the original reported issue:

If you have direct SQL access, e.g., through a shell or PHPMyAdmin:

Run the following query:
UPDATE files SET filepath = REPLACE(filepath, 'sites/default/files/', 'sites/example.com/files/

where example.com is the name of the directory your site is located in.

If you don't have direct SQL access:

• Install and enable the Development (devel) module, which allows you to run PHP code on your site.
• Go to the page devel/php
• Enter db_query("UPDATE {files} SET filepath = REPLACE(filepath, 'sites/default/files/', 'sites/example.com/files/')"); where example.com is the name of the directory your site is located in and click the Execute button
• Disable and/or uninstall Development.

Doest it means that I'll have to always run the SQL update after moving a site?
This is a hard work.
I always develop the site on localhost after I upload with a new dns.
So I always have to run the Update?
Is there any other way to avoid this?

I have this same problem, and a solution that works in my situation.

Production site: file_directory_path = 'sites/example.com/files' (set at /admin/settings/file-system)

Development site: exists in sites/example.com, but I access the site using subdomain.mydomain.com, and I have a symlink in the sites directory going from example.com to subdomain.mydomain.com to facilitate this.

It seems that when you access the site via another domain name (subdomain.mydomain.com in my case), drupal automatically updates the file_directory_path variable. So, in my case, it changes it from sites/example.com/files to sites/subdomain.mydomain.com/files. Obviously, this messes up Imagecache, as described above.

The fix: Add $conf['file_directory_path'] = 'sites/example.com/files'; to settings.php. This ensures that when the site is accessed via a different domain name, what is in the files table and what ImageCache is looking for (the content of the file_directory_path variable) matches.

the result: ImageCache generates it's URLs correctly, even when changing the domain name,

Ok, we have a multitude of sites (running on a multisite install) and we decided that we wanted all our content images to live in the same place. So we created a site called media. Our developers were complaining about the heinously long urls (ie /domain.com/sites/domain.com/files/imagecache/myimage.jpg ). So, we set up a symlink in the multisite webroot to media.

ie /multisite_bucket/webroot/media and symlinked to /var/www/media/.

Then we changed the default file system path drupal uses to media/multisite_bucket/domain/ (and yes, path is relative)

So IMCE is working like a charm. But imagecache isn't. We have the folder /media/multisite_bucket/domain/imagecache, but it won't write the preset folder or the image. We're using ImageAPI with GD2. File perms are correct, apache owns the files.

Any ideas?

My problem is similar but not exactly the same - I'm relatively new to Drupal and after reading all the troubleshooting and advice on forums I’m still not clear on how to fix it.

When I configure my content type field path to point to imagecache/square_thumbnail

The display of that image is pointing to:

sites/default/files/imagecache/square_thumbnail/imagecache/square_thumbnail/RCMtest2.png – I expected it to point to the first one below.

But the actual image is in:

sites/default/files/imagecache/square_thumbnail/RCMtest2.png – I expected it to be here

and also to:

sites/default/files/imagefield_thumbs/imagecache/square_thumbnail/RCMtest2.png – this doesn’t bother me much but I don’t see the purpose in keeping it.

When I remove the configuration from the type field – so the path is just files/ the problem remains but involves different directories.

Pointing to:
sites/default/files/imagecache/square_thumbnail/RCMtest6.png

But I can’t find the actual image anywhere (using search) and can’t see any issues in the log.

If there is an alternative to image cache that works better please let me know. I’m only using it to auto resize images.
What is the correct way to set this up? Is this definitely a bug or did I install something wrong?

Any advise will be much appreciated.

Activating "ImageAPI GD2" fixed this for me!

I second the fix in http://drupal.org/node/697086#comment-3162416 . I have adopted this method when starting new sites and no longer encounter issues anymore.

Bookmarking, great thread.
So procedure when already in the situation that some nodes are having wrong url;s:
1) Update database with #13
2) Then add #16 to settings.php
Right?

greetings, Martijn

In our case the problem isn't the domain, it's the fact that imagecache insists on using /sites/default/files rather than the file system path set in the site config. The fact is, the default url is horrid for SEO. On a multisite, no one wants to type /sites/mydomain.com/files/mydomain.com/imagecache/blah blah. We have a symlink in our drupal document root called /media, so our path for files looks like http://mydomain.com/media/images/etc. The fact is, Drupal / all modules should respect the file system path as set by the admin in the site config. We set this up on a brand new site with no previous images and it *still* failed.

I have one of my devs working on this. Cross your fingers, we may have a fix soon. *If* we can get it committed.

Update: This is actually not an issue with imagecache itself, it's how core handles the file paths. It's in D7 too. We suspect Drupal is doing a realpath() type check where the symlink path doesn't match the Drupal path (for example, symlink path is /var/www/media and url is mysite.com/media/ and Drupal root path is /var/www/mysite/webroot/ with a url of mysite.com ). We can upload files via Drupal fine, but we can't manipulate / resize them using Imagecache.

Just in case someone ends up here with the same issue as comment #22. Indeed, realpath is the issue here. Imagecache cannot write images on a symlinked directory. This issue is also reported here #155781: "realpath" check breaks symbolic links in file directory and has fix, but it needs some work (breaks some tests).

Cheers.