Download & Extend

Inline module causing Image to remove uploaded image

Project:Image
Version:6.x-1.x-dev
Component:image.module
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed (won't fix)

Issue Summary

Drupal 6.4
I have Image 6.x-1.x-dev and Inline-6.x-2.x-dev installed.

I was receiving this error on SOME of my new Image nodes.
"The selected file could not be copied, because no file by that name exists. Please check that you supplied the correct filename."

At first I couldn't figure out my problem, then I narrowed it down to only occurring when I supplied a body. When i did NOT supply a body the image creation succeeds. After some debugging I figured out what was happening, it looks like the inline module gets activated because the (Input Format I am using has the Inline filter in it) body now has text. This when the inline_nodeapi method gets called and (eventually) calls node_save again. The images have already been processed but the new_file property still equals true. So during the node_save initiated by inline_nodeapi, the image_update method gets called, which ends up deleting the newly created file and then trying to copy a non-existent file!

Hopefully, I was able to capture the gist of what was happening here.

My thoughts for a solution would be to set new_file = false AFTER a successful image_insert operation. Thoughts?

Comments

#1

As a proof of concept, I tried this and it appears to have worked. At least I was able to successfully add the image WITH a body and Inline module activated.

AttachmentSizeStatusTest resultOperations
image.module.patch436 bytesIgnored: Check issue status.NoneNone

#2

Chuck,

I had the exact problems you did. Having installed everything yesterday (June 22 2009) I knew I had all the latest versions.

I tested out patch and so far, it works great. I dont see any problems yet but if I do I'll let you know.

#3

Just came across that one too. Question to chuckdeal97 and that0n3guy: after you've applied that patch what happens when you try to change the image (like realising you uploaded the wrong one) before submitting?

I fixed it via the input format - allowing inline image insertion on an image node seems crazy anyway :) At least in my use case.

#4

Alright... If I'm understanding you right, you want me to create a node (page), add an image to the body (i uploaded a new one and added some text in the body of the image node), change that image using the "start over" button (i uploaded another image w/ text in the body) and try it out....

Seems to work just fine... the image was the wrong size though, probably just didnt adjust the html in tinymce (i'm testing it w/ wysiwyg api and tinymce) -----EDIT... oh the image was the wrong size b/c the original image was smaller than the thumbnail html that was inserted into tinymce... so tiny read it big, but after submitting it displayed the actual file size... but that has nothing to do w/ this issue :P.

#5

"set new_file = false AFTER a successful image_insert operation."

EDIT: Perhaps +1.., but:

Can this have implications for the expectations of other modues?
Is this a case that is only relevant during the operation of this module?

Which cases exist where the new_file should be TRUE?
Which function or module is setting the new_file to TRUE in the first place?

The user may do more than this in the edit window, using several other modules that may use this variable too, and they might do that on other images elsewhere in the same body, or outside of the body area (its own fields, etc.)..?

Any potential conflicts that needs to be taken into account here?

#6

Status:active» postponed (maintainer needs more info)

Is this still true with the new, revamped Inline 2.x ?

#7

Status:postponed (maintainer needs more info)» closed (won't fix)

Sorry, without further information this issue can only be marked as won't fix.

Feel free to re-open this issue if you want to provide further information. Thanks.

#8

FYI I also had this problem. I was running the 2009-May-16 download of inline-6.x-2.x-dev.

I've just installed today's dev version (and today's version of img_assist-6.x-3.x-dev to be safe), and the problem is fixed.