My setup (on a multisite installation)
- Drupal 6.9
- Content Construction Kit (CCK) 6.x-2.1
- ImageAPI 6.x-1.2
- ImageCache 6.x-2.0-beta5
- ImageField 6.x-3.0-alpha4
- FileField 6.x-3.0-alpha6
- Lightbox2 6.x-1.9
- getID3() 6.x-1.1
My problem: Imagefield is only showing links instead of the images. I thought I had a problem with Imagefield. It turns out the problem is somewhere else. The fault lies with the Imagecache module.
If you go against the documentation and set the "File System" to private the Imagecache module works as intended. It creates the subfolders, the previews work and the imagefield module will acutually display a teaser image and the full-node image just like you specified in the "Display Field Options".
- What does not work now is the display to visitors of your site. You now only get to see any images if you are logged in as the user who posted the image.
- What does not work also is the lightbox. It starts and tries to access the image but instead ends up showing a camaera icon - I guess it also does not have any access rights to the original image.
So in order for all this to work we must find a way ro make the Imagecache module work with the "File System" set to "public".
My two cents,
Paul.
Comment | File | Size | Author |
---|---|---|---|
#4 | imagecache_366177.D5.patch | 2.96 KB | drewish |
#4 | imagecache_366177.D6.patch | 2.83 KB | drewish |
Comments
Comment #1
paul_constantine CreditAttribution: paul_constantine commentedCorrection. The headline should say "...set to private?"
Paul
Comment #2
nravens CreditAttribution: nravens commentedI also have this problem. Does anyone have a solution? I need to have imagecache working with public file system...
The Lightbox and viewing of original images issue is solved by setting user permissions.
But I still have a problem with Gmaps that gives the following warning:
"GMap marker file settings are not configured properly for Private download method, markers will not work!"
Any assistance, advice push in the right direction would be very much appreciated...
Comment #3
docken CreditAttribution: docken commentedWatching several strings on this. Currently having the same issues with Imagecache. No directories created for presets, images show red "x" not found. With the only change being turning on private downloads, all images work again, thumbnails generated and shown. But as noted, switching to Private impacts several other modules, as well as files previously uploaded to the site:
Drupal 6.10
ImageAPI 6.x-1.5
ImageCache 6.x-2.0-beta8
ImageField 6.x-3.0-beta3
...
Ken
Comment #4
drewish CreditAttribution: drewish commentedmarked #399790: Public File System not Working with Multisite as a duplicate.
this patch goes back to the D5 way of generating URLs which i think will be more reliable. it also adds a parameter to imagecache_create_url() which causes it to add the timestamp to the url to bypass the browser's cache.
Comment #5
apadernoComment #6
drewish CreditAttribution: drewish commentedgoing to go ahead and commit this so people can test it. it's in both DRUPAL-5 and HEAD.
Comment #7
drewish CreditAttribution: drewish commenteddidn't mean to revert the title
Comment #8
leenwebb CreditAttribution: leenwebb commentedHi,
I just installed the new dev version (and my /sites/default/files/ is set to 777) but I'm still not seeing any images in the imagecache folder. :(
My PHP version (asked in another related thread) is 5.2.6-2ubuntu4.1 .
Drewish, thanks for looking into this -- it's been driving me crazy!!
Comment #9
docken CreditAttribution: docken commentedAlso installed the latest dev version.
Works fine in private, but not in public mode as before.
This also seems similiar to the "creating in files" thread.
My files directory is under sites/domain/files. When creating a preset, the file is saved in the files directory but the link/src point to the sites/domain/files/imagecache/preset/filename (i.e. sites/domain/files/imagecache/preset/sample.png)
FileField 6.x-3.0-rc1
ImageAPI 6.x-1.5
ImageCache 6.x-2.x-dev (2009-Apr-13)
ImageField 6.x-3.0-rc1
Ken
Comment #10
Miteto CreditAttribution: Miteto commentedI've had this issue and just yesterday I've noticed that a .htaccess file is lurking in sites/default folder. It was a copy of the original .htaccess file that was supposed to be in the root folder except that line 101 - "RewriteBase /" was uncommented. I tried to delete it but it kept coming back. So I chmoded the damn thing to 644, then I deleted all the content in it and the problem vanished.
Still wondering why it kept generating ...
Comment #11
docken CreditAttribution: docken commentedI think I may have found the issue looking at Miteto's htaccess comment above.
Within the sites directory, there was an .htaccess file with the following lines
I simply commented out the "RewriteEngine off" line above and changed the file to say:
and voila everything works as planned.
I would look down through the directory tree and check any .htaccess files and see if one of them turns off the rewrite engine.
I still need to check to see if this will pose a security issue, but it seems to have fixed the imagecache issue!
Ken
Comment #12
apadernoI would rather not change a file that comes with Drupal (if that is the original file).
If the .htaccess file given with Drupal causes problems, it should be better to open a report against Drupal.
Comment #13
ikok CreditAttribution: ikok commentedHello all,
I've fixed the problem with method from this link http://drupal.org/node/399790#comment-1428428
Even though, the link is for D5 version but i could apply it for D6 (6.x-beta8) version as well and i would like to share (sorry, i don't know how to create a patch)
without changing the .htaccess file or set the file system to PRIVATE (my site works with PUBLIC file system) all i did was to modify 1 line of code in imagecache.module
here is how
1. In the imagecache.module, look for function imagecache_create_url (around line 302, in my case)
2. Replace
with this line
** 'system/files/imagecache/' is the imagecache dierectory path on my site, these can be different from yours**
After you save, Everything should back to normal and your site should working properly again.
Hope this helps,
iKok
Comment #14
ikok CreditAttribution: ikok commentedsorry, i didn't want to change the heading detials
Comment #15
apadernoThe proposed code is almost the code executed from
file_create_url()
, when the filesystem is set to private.Comment #16
ikok CreditAttribution: ikok commentedyes, i think there are
under imagecache.module, i don't understand why
file_create_url()
under public file system couldn't return the correct path of images, so i use the code from private file system instead. =)Comment #17
docken CreditAttribution: docken commentedThe Security note (DRUPAL-SA-2006-006) in the .htaccess file noted above relates to versions of Drupal prior to 4.7. You can see the note here: http://drupal.org/node/65409
I'm still doing some looking, but I'm guessing this .htaccess file is no longer needed. The file is probably left over from when I had that installed (My first site with drupal).
While I've done a complete delete and fresh install each time I've done a major Drupal version change, I always take the sites directory and drop it into the new install in order to move all files and attachments over to the new system.
I've looked in the 6.10 download, and there are no .htaccess files that are in the default install sites directory. Couldn't find any other requirements for these. I've deleted those files since they are not in a default install of 6.x version of drupal.
Agree about changing files in core without submitting an issue, but think the common denominator may be files left over from earlier installs of drupal. If not required anymore, then it shouldn't be an issue to delete them.
While the hardcoding the files directory fixes the problem, it makes it difficult if you later need to change the files directory location within the program, or to change that line for a multi site directory with files in different places.
Still not sure why Private would work and Public would not in this situation, but assume it has something to do with how private file system handles rewrites within the site.
Regards,
Ken
Comment #18
drewish CreditAttribution: drewish commentedClean URLs require that you have mod_rewrite installed and enabled. So if you meet that criteria the it sounds like the old .htaccess file is screwing it up. I've also double checked and those .htaccess settings are no longer used in Drupal 6 so I think you can remove it safely. That would also explain why I haven't been able to replicate the bug on clean installations of Drupal.
Now if you don't have mod_rewrite enabled at the present the only way you'll be able to generate images is by using private file transfers. I'm looking into a fix for this configuration but for now that's the workaround.
I'm really tempted to start two new issues to deal with the separate problems a) broken with mod_rewrite b) broken without mod_rewrite.
Comment #19
drewish CreditAttribution: drewish commentedI've added a note to the ImageCache troubleshooting guide about removing mod_rewrite off from old .htaccess files.
Comment #20
docken CreditAttribution: docken commentedThanks drewish. I've been using clean url's, so removing the leftover .htaccess files fixed the issue.
Can confirm this now works with clean url's enabled, and under both public and private with the latest dev version of Imagecache.
Regards,
Ken
Comment #21
drewish CreditAttribution: drewish commented#410200: Without clean URLs ImageCache doesn't create folders or images now deals with the later case.
Comment #22
ikok CreditAttribution: ikok commentedHi,
Pls take a look at http://drupal.org/node/399790#comment-1428428
davidlerin has done this for the multisite installation(D5 version), it may difficult but it possible, so it should work fine on that case =)
Comment #23
drewish CreditAttribution: drewish commentedikok, that's not a good permanent solution because it causes a performance hit for sites that have clean urls enabled.
Comment #24
fattshin CreditAttribution: fattshin commentedI hit this problem today, and I'm also having multisite installation.
Try Install 6.x-2.x-dev (20-Apr) but no help.
Finally solved it by assign a unique Temporary Directory for each site.
Comment #25
scafmac CreditAttribution: scafmac commentedA recent upgrade to ImageAPI broke imagecache for my multisites. For info & patch - #441586: Patch for 6.x-1.x-dev breaks imageapi_imagemagick on multisite configurations on Linux.
Comment #26
ikok CreditAttribution: ikok commenteddrewish, thank you for your suggestion, my site which has clean urls enabled, still working fine (may be it is not big enough to see the significant performance change), i'm thinking to try another solution as well =)
Comment #28
luf CreditAttribution: luf commented*TO FIX THIS ERROR*
I tried this as to post #11 changing .htaccess document located in the sites/default/files folder but still had some errors when trying to use ImageCache or make thumbnails. Thumbnails would instead show up as red X's and sometimes uploading a file especially under Ubercart > Taxonomy for the product gallery page I would receive errors: "file not found, file could not be copied" etc..
*If you still have errors after using the .htaccess found on post #11 change your Site Configuration > File System > Temporary Directory as seen in this post:*
http://drupal.org/node/131597#comment-2671100
System:
Windows Server 2008, IIS 7, MySQL 5.1, PHP 5.2, Drupal 6.15 w/ Remote Access
Comment #29
kndrLook at http://drupal.org/node/241541
Comment #30
kndrOops :) My mistake
Comment #31
timdiacon CreditAttribution: timdiacon commentedI've got a fresh instal of 6.19 running as multisite with clean urls enabled and I'm getting the same problem. My directory structure is:
sites
>>www.mysite-1.com
>>>>files
>>www.mysite-2.com
>>>>files
I've checked the root of the sites directory and there is no .htaccess file in there to attempt the fix suggested in post #11.
If I use public files the images do not appear although the image path in the html is as you wuld expect. If I switch to private files image cache works fine. Interestingly if I switch back to public files image cache still works. It seems it is the creation of the image which is failing under public files.
I'm reopening as it seems this problem as been ongoing for a long time with no definitive solution.
EDIT
Ooops - my imagecache and image api modules were both one version out of date - I've updated both of them and public files are working just fine.
Comment #32
timdiacon CreditAttribution: timdiacon commented