Upload twice or die
Boobaa - August 22, 2009 - 19:10
| Project: | ImageField zip support |
| Version: | 6.x-1.0-beta1 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Description
If one does not press "Upload" button on the zip upload form but simply presses "Save" button to submit the form, the zip file uploads, but the images do not get attached.
If one does press "Upload" button, the zip file uploads, images get attached, and when "Save" button gets pressed to submit the whole form, the zip file uploads again.
I am using firefox-3.5.2, and has not tested this odd behaviour with other browsers, but this upload-twice-or-die approach is simply annoying, not speaking about the time and bandwidth wasting.
Is there any chance to get around this bug?

#1
OK, studying the (uncommented) code reveals some information.
1. The Zip Upload's Upload button _must_ be pressed to have the module do anything useful, as all the image-attaching work is done in its AHAH callback.
2. That AHAH-backed Upload button is introduced by _imagefield_zip_form() (which is called from imagefield_zip_form_alter()), but this button is simply outside of the scope of the #ähah['wrapper'], so it will NOT be replaced by the HTML the AHAH callback returns.
The above info does answer why I have to upload my .zip twice to have images from it attached: first it must be uploaded by the means of that AHAH-backed Upload button, which does NOT clear the file input out of the way, so when I submit the whole form itself, the file WILL get uploaded again, but this time nothing is being done with it.
I do have struggled to clean it up a bit, but gave up.
First I tried to add the zip-upload part (in _imagefield_zip_form()) as a heavy-weighted fieldset, but this way 1. the zip-upload part was shown as a draggable item of the image-uploads, which is unneeded and confusing, 2. it was shown after the first empty image-upload, which is confusing as well.
Then I tried to move all the image-upload parts _and_ the zip-upload part into the same fieldset and give THAT fieldset an HTML ID being the same as the zip-upload part's #ahah['wrapper']. This way all the image-uploads and zip-upload should have been replaced by the HTML the AHAH callback returned, but I couldn't find a correct way to do it.
This was the point I gave it up for today.
I would gladly welcome a solution which addresses BOTH of the above-mentioned issues: 1. the zip should be extracted even on form submit, not only by the AHAH callback; 2. the AHAH callback should replace not only the image-uploads, but the zip-upload part as well.
#2
This is a module I didn't write, I took it over. As such, I semi know whats going on, because I don't "own" the code. The fact that AHAH is hard doesn't help. Keep plugging away at this; let me know if you wish to have cvs access.
Long term goal would be to abstract this out so it can AHAH load a set of images, the fact that it came from a zip shouldn't matter a whole lot.
#3
OK, this is annoying me so much that I decided to rewrite it.
The first step is going to be adding a form element (in hook_form_alter()) to be able to properly upload a .zip with a bunch of images to any given imagefield, by the means of the "standard" form submit. I will report back if and when I'm ready with this; but give me a headshot if this is a wrong approach.
#4
...and after several hours of headbanging into my keyboard I came up to the decision that I don't want to mess up with that CCK widget hell that this needs, so I totally rewrite it and took a rather different approach. I have added a new tab to the nodes that have multivalued imagefield(s) for those users who have update rights on the node. Going to that tab one can upload a ZIP file from which the images are added to the appropriate imagefield. Theoretically multiple multivalued imagefields should be supported, but wasn't tested.
Now I can upload tons of images to a multivalued imagefields without the need of flash or java, and without uploading the zip file twice. Additionally, my test shows that image order is kept (probably because of the files ordered in the archive, based on their name), which is great, too.
#5
The tab thing sure make the code easy to manage, but in terms of the user interface being intuitive this isn't ideal. Until the 2.0 branch replaces the 1.0 in terms of functionality, I would like to keep 1.0 as the recommended version. If you are ok with this, then lets move forward.
#6
@Boobaa, your solution is the best for multiple upload to imagefield.
Thank you! :]
Szy.
#7
Sorry for title change :/
Szy.
#8
k looks like i need to release this as the 2.0 branch