_image_build_derivatives should leave files in their original location [#256210]

first, I use http://drupal.org/project/uploadpath and http://drupal.org/project/upload_image module in addition to image and upload. Those have some issues of it's own in Drupal-6 but I got all to behave as it should.

My use case with all those modules is:

- I create Page/story/book nodes

- I use the attach_file functionality of the upload module to upload images. Then

- uploadpath kicks in and copies the image into a specified subdirectory "sites/domain/files/newfolder/*.jpg" and updates the files table

- upload_image kicks in and creates a image node out of that $file from the files table. The physical files remain untouched in "sites/domain/files/newfolder/*.jpg" (checked this by commenting out the _image_build_derivatives call from the module)

But at some point - either directly in the module (if not commented out) or later, if the images are actually displayed, the _image_build_derivatives (from image.module) gets called and this function seems to move/create all images into "sites/domain/images", ignoring the current file location.

To me this seems to be a bug. I would expect the images to remain in their location and to get the derivatives build next to it?

Jens

Comments

Comment #1

ansorg commented 13 May 2008 at 11:42

any opinions on that?

this behavior really makes the uploadpath modules useless.

I looked at the image code. The key function seems to be

function _image_filename($filename, $label = IMAGE_ORIGINAL, $temp = FALSE)

it gets used by _image_build_derivatives (and possibly others) and converts all given filepaths into something in the defined default images destination folder.

I tried to modify this function so it would not rewrite paths if the uploadpath module is installed. But I could not get it to work reliably in all cases (i. e. image_import did not work).

Could somebody suggest what would be a good way to get this working?

Jens

Comment #2

yesct commented 3 June 2008 at 06:19

http://drupal.org/node/103793 (control of naming) is a much bigger issue, but related in that it moves files around (and might be able to move them "back" to the "right" place).