Preview Forgets Image Directory Path and Filename

That would be because there is no way to programatically set an input type file field (think security hole).

Once you hit preview, you should see the image as a thumbnail and no longer need the filepath -- the server already got it.

I'm using DRUPAL-4-7 branch of both Drupal and Acidfree and I'm getting this error. When selecting an image and hitting preview, no image thumbnail is displayed and upon clicking Submit, I get "No file supplied".

Just submitting straight away works just fine.

Drupal 4.7.0
Acidfree 4.7.0 module v 1.62.2.18
WinXP Pro
Apache 2.2.0
PHP 5.1.1

Preview does nothing, no thumbnail, no image. Submit works Ok, though.

Is preview working for anybody? I've tried to figure out where to look, but not sure about a proper fix.

Maybe you should just remove the Preview button.

@vhmauery Do you have any idea on this one? I know you may be busy, and I can take a look at it, but I could use a push in the right direction as there is a lot going on in acidfree.

Thanks for a great module!

I have hunted and hunted. I am stumped. I guess I don't understand the new forms api as well as I thought. That and how previews work in 2.7... I will keep working on this, but I would really appreciate any help people could offer.

Thanks for looking! At least I know you're still out there. I'll get into acidfree a bit more when I get some time and see what I can find.

I noticed this bug on a 4.7 site I run.

Anyway, I am trying to build another site that doesn't need all of Acidfree's features. So to learn Drupal better, I thought I would convert the image module to use the filemanager module. I decided to use acidfree as a guide. I noticed that image uses hook_prepare to create temporary images for preview while acidfree does not. That's when I went to my other site to see how acidfree's preview worked, and found it was broken. I am still very new to this, but maybe you need to use hook_prepare and create a temporary image to display for the preview?

Here is a patch based on the hook_preview tip. (thanks for that by the way!)

I have done a basic sniff test on my dev box and would like some further testing. Please try it out in various scenarios.

I'll try this out and report back. Another place to look is the new imagefield.module for CCK (although the previews are still a bit funky in that as well).

Thanks vhmauery, I'll post back here in a few days.

I gave the patch a try, and it seems to work. However, the method used is "exploitable" to some degree. I have run into this same problem while working on my filemanager-capable image module. For the preview, we need to keep track of the filemanager "fid" values for the various sizes of the image.

One method is to store that info in the form as hidden values. However, I was able to use the Firefox Web Developer toolbar to change the values during the preview. Once I submitted, I had access to images that belonged to other acidfree nodes. When I deleted my modified node, the images from the other nodes got deleted too.

I thought of creating some sort of hash to pass along on the form with the image list to verify that the values were unchanged, but it seems clunky.

I am now considering passing that data in $_SESSION. Seems like a good way to do it but I'm not sure if it is proper Drupal module programming. The Drupal documentation on proper form preview handling is nonexistant or at least hard to find.

I searched a lot on this problem last night and found this thread from last winter. It looks like it was mostly unresolved but one developer has decided to use $_SESSION also.

okay, I am going to say that the exploit is the form api's problem. Between the lack of parameters for hook_prepare and hook_form, it makes it impossible to use the '#type' => 'value' form element, which never actually gets passed to the browser. The form api should have some '#readonly' => true property or something. Or it should compare the hidden values that come back from the browser to see if they are the same as the ones sent.

So I think I will commit this patch. It is in version 1.62.2.35

okay, I am going to say that the exploit is the form api's problem.

That's fine with me. Do you know if this has been reported as a problem/bug of the Drupal core yet? I'd like to see that it is fixed by them.

I have no idea if this is a new exploit or not.