image_attach now working for DRUPAL-6!

Yeah. Doesn't look like image_attach got much love.
I saw that function just now and came looking for "WTF is that? It's nowhere in my code!"

I'm not even getting the error because attachment isn't even getting that far.

It seems (as I'm lookin at the traces now) that this node creation on-the-fly in the image_attach_nodapi(prepare) phase is just not firing as it used to.
Well... what is 'prepare' (form initialization) doing actually creating nodes as a side effect??
It may have been convenient, but it looks like it's no longer working at all.

Plus ... Why has image.module now got this cool little image_create_node_from() function if image_attach isn't going to use it?
I'm trawling the code right now to see what's missing.
Currently, image_attach 6.x-1.0-alpha is really not there at all.

I can, however, attach existing images :)

image_attach_nodeapi(prepare) just isn't happening any more. Only once at the beginning.
(DRUPAL-6-2 FWIW)

Capturing image uploads from that is not going to work.

On node form "Preview" the calls are:
image_attach_nodeapi load
image_attach_nodeapi validate
image_attach_nodeapi view
image_attach_nodeapi alter
on node form "Save" they are :
image_attach_nodeapi load
image_attach_nodeapi validate
image_attach_nodeapi presave
image_attach_nodeapi update

If image attachments are going to happen on-the-fly (like they used to) maybe their creation should be inside hook_form_alter() instead? ... No, that doesn't seem to happen on submit any more!

Man, has everything been cached away? Maybe I should give up and move to image_field instead ...
... No, I want my images to be first-class nodes!

I'm still investigating. Looks like a patch/fix may be large.

OK... here's the fix!

As I found out hook_nodeapi is not a good place to do interesting things anymore in D6, and has a critical problem that stops us being able to do things as before ... even if that was possible otherwise.

I've shifted the make-a-new-image-on-the-fly action out into a custom handler, so it happens as part of the FORM processing, not the NODE processing. That actually feels a bit closer to the right way anyway, as the image node creation is the problem of the UI, not the node_save. Sorta. Better than having it in 'prepare' anyway.

The code is (I think) a bit tidier, and is even smaller, making use of image.modules create_node_from().
For whatever reason, there's a few tiny implementation differences, such as the owner of the created node will be the person who uploaded it. Previously it was the owner of the owning node. No clue what difference that makes. I just left that quirk out because create_node_from() seemed to know what it was doing.

So anyway, it now works!

There's not much in the way of special error-handling if an image is invalid or too big in this code. I figured that's a job for create_node_from() to do in a more re-usable, consistent way, if it's needed. Currently that seems to be working very well.
Uploading a non-image for example chucks a form error from the image-node creation form. Sweet.

... and to think earlier this evening I just wanted to try out an imagecache update ... I couldn't even get that far without getting sidetracked ...

Still. Bonus win, I think. (clean scan with coder.module also)
Next week ... AJAX version! [yeah right]
.dan.

title & status change!

that patch didn't work for me...

$ patch < image_attach_port_to_D6.patch
(Stripping trailing CRs from patch.)
patching file image_attach.module
Hunk #1 FAILED at 184.
Hunk #3 FAILED at 266.
2 out of 3 hunks FAILED -- saving rejects to file image_attach.module.rej

any ideas what I'm doing wrong?

A quick visual scan of the current HEAD of image_attach.module shows nothing unexpected changed there. Not sure what's up with the patch then. It's pretty clean if you want to try merging the three hunks by hand.

I applied the patch, and Image Attach now stores images, but all is not well.

I got the following message when I saved a node with a picture in it:

Warning: Division by zero in pathname.../image.module on line 193.

Drupal stored the original file, but did not create a preview or thumbnail.

I looked at the code and found that the call to image_get_info($file->filepath) at line 192 was returning a null value. A call to is_file() reported that the temporary file referenced by $file->filepath did not exist.

I run under Windows, and I noticed that $file->filepath was using mixed delimiters in the pathname, e.g., "C:\DOCUME~1\user\LOCALS~1\Temp\php\upload/filename.jpg". I don't know whether that could get other functions upset. I corrected it, and that did not help.

Since this is happening in image.module, it's not clear to me whether it is an Image problem or an Image Attach problem. Image works correctly when used alone, though, so I'm at least inclined to suspect the latter.

My attention is drawn to the pathname in $file->filepath, which is a customary location for temporary files in Windows. There is also a temp subdirectory in the files/images directory. I wonder whether Image Attach is storing temporary files in one place and Image is looking for them in the other.

I'm not personally doing any development in D6 at the moment. I just upgraded this (as far as it went ... which apparently isn't far enough) in order to get some supporting images for another module I AM looking at for D6.
Although I don't currently dev much on windows, I have in the past, but I'm not sure if this problem is a pathname one, or, more likely, a temp directory thing.
There is certainly a good chance that it's an incorrect path concatenation here somewhere, although PHP on Win is used to these problems and usually figures out what you meant.

Sorry, this task is not fresh in my head, nor is there space in my head this week to look into it. Some more error-checking would be welcome (eg that null filename should trigger a form error, rather than a (!) division by zero?)

All I can do today is wish you luck. I've got a long awaited launch (maybe) this week.

subscribing

Thanks Dan, works fine for me :)

thanks, commited to D6.

The problem that I reported in message #8 is still there in alpha2. I've discovered that it affects Linux as well as Windows, though, which puts a somewhat different face on it. It appears to be a completely different problem, so I have started another topic for it; see http://drupal.org/node/271788.