Just performed update to beta6 (from beta5). Image path now is being written incorrectly and as an absolute path -- despite the image settings showing the default system filepath, so images are not displaying. Example:
<img width="100" height="76" class="image image-thumbnail " title="Photo: Beach Remote Sensing" alt="Photo: Beach Remote Sensing" src="http://mysite.net/system/files/images/beach-remote-sensing.thumbnail.jpg">

When I modify that URL (thru Firebug) to src="/sites/default/files/images/beach-remote-sensing.thumbnail.jpg" the image displays.

The images are saving to the correct folder, specified in the images config settings: /sites/default/files/images

How can I correct this? Where in the code (file/line) is this written out?

NOTE: I'm using Image Attach, and attaching the images through custom content type. Relevant modules:
Drupal 6.19
Image 6.x-1.0-beta6 (with ImageAttach and ImageGallery)
ImageAPI 6.x-1.8 (with ImageAPI GD2)

Comments

joachim’s picture

joachim commented
Status: Active » Postponed (maintainer needs more info)

"system/files/images/beach-remote-sensing.thumbnail.jpg"

That's a private files URL.

greta_drupal’s picture

greta_drupal commented

Yes. And???? How can I correct the pathing problem with Image? I have another site that uses private files with Image, and it works fine - no broken images (beta6 generates error, so I am using beta5). However, that site uses ImageCache. It would be nice if the Image module pathing would work correctly on its own.

joachim’s picture

joachim commented

What do you get when you put just the URL http://mysite.net/system/files/images/beach-remote-sensing.thumbnail.jpg into the browser? Perhaps there is a problem with permissions for private files?

I've just tried the private files URL for an image node's image file and it works fine for me.

greta_drupal’s picture

greta_drupal commented

When I browse to the precise (absolute) URL generated, I get "Access Denied"...as expected. Both as anonymous and authenticated user.

Must be some other disconnect. I sure cannot see it. But, happened after I did update. *sigh*

greta_drupal’s picture

greta_drupal commented

I reinstalled ImageCache and the images now are displaying. Although, I don't understand why that is necessary. It seems that ImageCache is somewhat redundant to Image. (I was trying to simplify.)

joachim’s picture

joachim commented

> When I browse to the precise (absolute) URL generated, I get "Access Denied"...as expected

Do you mean the private one or the real one?

What are you actually trying to achieve anyway -- are you trying to serve images as private files?

greta_drupal’s picture

greta_drupal commented

Answer: Browse the private URL, get Access Denied.

Intention:
There is a client-only area of this site for uploading/downloading files. So, the site was create with the private file system. Some of those files might be images. However, other than on this one page, the other images of the site should be available to the public.

It is odd that when I reinstalled ImageCache, the front page slideshow displayed again (#1 http://MidAtlanticTechnology.net). However, other slideshows on the site, created with a different module (Slideshow) and that do not use ImageCache, do not display except to authenticated user. Example: http://midatlantictechnology.net/Slideshow_NECapeFear

In contrast, another site (#2) is set as private file system, uses ImageCache, and also the Slideshow module for subpages -- those subpage Slideshows work fine (example: http://opcofamerica.org/news/opc-members-share-tchotchkes-memories).

#2 is using beta5 (because of error generated by beta6) and File Upload Path -- although I don't think that is of issue.

The subject site (#1) was working before the updates, so I guess that I'll have to roll everything back and start over. blah.

joachim’s picture

joachim commented

> Answer: Browse the private URL, get Access Denied.

Check permissions then.

You do realize also that imagecache and image are completely separate? (Unless you've applied the patch, that is.)

greta_drupal’s picture

greta_drupal commented

I have not changed any permissions from when it was working properly, but I did re-check them.

And, of course, I realize that the 2 modules are separate - I installed them. I was noting that their functionality (e.g., resizing images) is similar, redundant.

joachim’s picture

joachim commented

So is the problem is that the path system/files/images/beach-remote-sensing.thumbnail.jpg is 404ing when it should not, or is it that the path is incorrect?

Before you reinstall everything, debug the menu system for the system/files/image path.

BTW, just set my test system to use private files, and my image nodes all work fine.

greta_drupal’s picture

greta_drupal commented

Well, turns out that my post subject really isn't accurate. I had forgotten about the site's setting of private file system. So, the absolute URL is correct for private files, but the images are not displaying within the node. So, not technically a 404, but a broken image.

In troubleshooting, if I manually (through Firebug) change that URL to default/files/images where the files are stored, they display.

I'll check the menu db table. I didn't not change the file system setting at any point, so don't expect any issues there.

As noted, it works fine for another private file system site running beta5. So, it seems that I have no choice but to roll everything (core + contribs) back.

Thank you for the suggestions.

joachim’s picture

joachim commented

> So, the absolute URL is correct for private files, but the images are not displaying within the node. So, not technically a 404, but a broken image.

What I mean is that the broken image is caused by a the URL for the image returning something else - ok so a 403 rather than a 404.

The menu table won't tell you anything. You need to figure out why the attempt to output the image is giving you a 403.

I reckon this is due to the fix in #883338: image_fetch calling hook_file_download directly. This change for beta 6 means we properly invoke hook_file_download() for an image file.

What other modules do you have which implement hook_file_download?

kmajzlik’s picture

kmajzlik commented

I had same problem. SRCs of files seemed like http://mysite/sites/default/files/images//sites/default/files/images/image.jpg

This easy thing helped me: go to admin/settings/file-system and save. No changes, only submit the form.
I do not no why or how, but works.

amcoms’s picture

amcoms commented
Title: Incorrect, absolute URL being generated » default image attach link
Version: 6.x-1.0-beta6 » 6.x-1.x-dev
Component: image.module » image_attach
Category: bug » support

not sure if this is the right place to place this but I am finding it very difficult to understand why image attach has no control over for the link from the image attached and published in $content

is there anything that can explain how to change this default setting so that the url can be edited please?

joachim’s picture

joachim commented
Title: default image attach link » Incorrect, absolute URL being generated
Component: image_attach » image.module
Category: support » bug

No, this is not the right place. What part of changing the title and settings on this existing issue seemed like a good idea?

Ask on the forums or IRC for this kind of support question.

amcoms’s picture

amcoms commented

How very rude

joachim’s picture

joachim commented

No, I could have been quite a lot more blunt if I'd wanted to be, but that's not appropriate for an issue queue.

Nor is repurposing an existing issue. It does seem your question is very vaguely related in that it's about where things link, but that's pretty tenuous. The answer to your question, anyway, is probably 'theming'.