Hi everyone, I'm running the latest version of drupal with acidfree version release in May (due to highly critical display bug) I'm hesitant to upgrade to the latest version of drupal; I'm not sure why, however I noticed that displaying images inside of nodes doesn't seem to be working; here is the code that I'm using:

[acidfree:2210]

pic test number 2

Here is an example of the problem http://www.theblissfamily.org/?q=node/2220
The picture really exists, so I'm not sure what's going on here. Thanks for your help

Comments

lakyljuk’s picture

I have exactly the same problem, using Drupal 5.1, Image module 1.2 and Acidfree version from May (due to unproper displaying of thumbnails with version from June 27th). Viewing albums is ok, no problems, but when insert inline filter like [acidfree:xxx] I see only caption of this photo inside node, but no thumbnail is inserted. I see also following error when displaying node with inline filter inside:

warning: getimagesize(files): failed to open stream: Permission denied in d:\web\www\modules\contrib\acidfree\acidfree.module on line 1794

lakyljuk

pknag’s picture

I can confirm that I have same problem. I am using the Image module 5.x.1.3 though and the latest acidfree module. In my case I see a link to the image page that is clickable. But does not show the inline thumbnail.

pknag’s picture

After some mucking around I looked at the page source and it seems like the img tag is set wrong. I thought it should be of the form:
/drupal/system/files/images/filename-thumbnail.jpg
as it is in other cases, but in this case the the path is wrongly set to:
/drupal//home/some/path/files/images/filename-thumbnail.jpg

Notice that I use an absolute path to a dir in my filesystem and the download method is set to private in file-system setting. When I look at image nodes the img paths are correctly set, except when I use the [acidfree:nnn] tag.

I bet others have the same setup as mine and the problem shows up for them too.

Urfin Juss’s picture

Your image has the address: http://www.var.ru/www/html/famweb/drupal/upload1/images/100_1091.thumbna...
There can be a problem in an absolute path?
At me such problem is not present. Both with the present version of the above-stated modules, and with earlier versions.
IMHO an absolute way it is little bit another. For example:
/home/mysite/www (public_html)/files/images
In your case the reference to the image located on other site? I have correctly understood?
Because in the block " Rendom image " the path to thumbnail is specified correctly.
Try so: http://www.var.ru/upload1/images/100_1091.thumbnail.jpg (but me it seems this domain simply does not work)

lakyljuk’s picture

Even this problem is solved with latest dev version of Image module. I upgraded and problem with inline filter is gone.

lakyljuk

pknag’s picture

For me the problem persists with the latest -dev version of the image module (july 6 as you mentioned). The problem manifests itself in the source file as I mentioned earlier. The img path is constructed wrong:

/drupal//home/some/path/files/images/filename-thumbnail.jpg

Notice the double slash after /drupal. So it is taking the base URI and appending the absolute path to it. The absolute path being:
/home/some/path/files/images/filename-thumbnail.jpg

So the problem seems to me as coming from path construction. This is the only time I have seen the absolute path in the html source of a page. Usually I see it being constructed as:

/drupal/system/files/images/filename-thumbnail.jpg

which is relative to base URL of my site.

I hope I am clear as to my observation of the problem.

vhmauery’s picture

This sounds like you have some configuration issue. Not sure what it would be though. If it works for one site and not for another, that is usually what the problem is. Since I am not a Drupal configuration guru, I will leave this issue to someone else.

awb7422’s picture

fixed for me; I'm not sure why, however under Admin->site configuration->file system I had to set the file system path to be relative to the drupal install location despite having Private files option checked....Thanks for your help everyone..

vhmauery’s picture

Status: Active » Closed (fixed)
pknag’s picture

I am late here and after the issue has been closed. Looks like the solution is to use relative paths only for the filesystem. Otherwise the paths can get constructed wrong. Awb7422 seems to have fixed it this way. But I wonder why it should not work with absolute paths. Could the bug be in the file-system part of the core?