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
Comment #1
Aldus CreditAttribution: Aldus commentedI 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 :(
Comment #2
raintonr CreditAttribution: raintonr commentedThis 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:
Looking at a newer install, this is now:
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.
Comment #3
avner CreditAttribution: avner commentedI tested it on a clean new installation with the same result -
preset is not saved
Comment #4
sgriffin CreditAttribution: sgriffin commentedI 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.
Comment #5
picardo CreditAttribution: picardo commentedHaving 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.
Comment #6
savageanne CreditAttribution: savageanne commentedYou'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.
Comment #7
geerlingguy CreditAttribution: geerlingguy commentedSame 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.
Comment #8
geerlingguy CreditAttribution: geerlingguy commentedAfter 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.Comment #9
yixia CreditAttribution: yixia commentedAs 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.
Comment #10
drewish CreditAttribution: drewish commentedComment #11
doublejosh CreditAttribution: doublejosh commentedSame solution worked for me.
Set file system private... (which I presume changed folder permissions) images were able to be created... then changed it back.
Comment #13
John Pitcairn CreditAttribution: John Pitcairn commentedHaving 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...
Comment #14
John Pitcairn CreditAttribution: John Pitcairn commentedComment #15
John Pitcairn CreditAttribution: John Pitcairn commentedOK, 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.
Comment #16
Summit CreditAttribution: Summit commentedBookmarking interesting information here, still sometimes also problems with imagecache using Ubercart. looking forward for complete clear exact installation notice.
greetings, Martijn
Comment #17
ryanellis CreditAttribution: ryanellis commentedSame 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]
Comment #18
unc0nnected CreditAttribution: unc0nnected commentedAll 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
Comment #19
charlie-s CreditAttribution: charlie-s commentedIn 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).
Comment #20
maddentim CreditAttribution: maddentim commentedMy 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!
Comment #21
fizk CreditAttribution: fizk commented