Support for drag & drop, multiple file selects and instant uploads in file field

[Soma]

Ohhh thanks Ryan, I already thought I was crazy. I wasn't sure and I tested this today before and it suddenly worked. Didn't know you fixed it already!

[Pete]

Antti - this doesn't work on my live or dev serer in Opera 11.6 - what I mean is that the progress bars don't show and no thumbnails appear. Strangely, clicking Save shws the uploaded files on the next page, but that's a little inconsistent.

Just to throw another issue into the mix, on ONE server I use, images never finish uploading in Firefox, but finish fine in Chrome. I've been working with ryan on another issueand he's fixed one error message I was seeing in the source code, but on this one server I get the json error mentioned in this thread: - also worth checking out the screenshot from Firebug I attached as the ajax request is oddly throwing a 404 error for a page we know to exist (is. the one I'm editing!) but as I say this is only in the latest version of Firefox. Strangely FF can upload fin on my local server as well as other servers so I suspect that that one is an environment issue whereas the Opera issue is present on any install.

I'm not sure if the FF issue is related to the Opera issue though, but thought it was worth mentioning as they're both related to the image uploader.

[Pete]

Fixed this. Bizarrely

In InputfieldFile.js I added the following:

xhr.setRequestHeader("Content-Type", "application/octet-stream");

after this areound line 203:

xhr.setRequestHeader("X-FIELDNAME", fieldName);

It seemed to then basically stop producing a 404 error and stop malforming the JSON. I suspect it is a server/PHP combo that caused it as the server with the issue was PHP 5.2.7 whilst my dev server is 5.3.x, but could have been any number of variables.

Since the fix in pretty harmless I guess it may as well be added to the core? I'd do that Git thingy but Git is being a git and not working for me at present

Also, whilst I was there, shouldn't this line:

xhr.setRequestHeader("X-FILENAME", file.name);

have an extra hyphen, so file-name instead of filename? I've seen it with a hyphen elsewhere so not sure if that is correct (presumably either can be used else it wouldn't work would it?).

Still cannot get the progress bar uploader working in the latest version of Opera, but since I don't use Opera I've got less incentive to try and fix that one

[ryan]

Wow how did you find that fix Pete? Good find! I will add this to the core, but just want to make sure the issue goes beyond one case, just to be on the safe side (?) Unless there's something out there that says this is a safe/expected header for this context. I'm not yet familiar with this octet-stream.

Someone correct me if I'm wrong, but I don't think it matters if it's X-FILENAME or X-FILE-NAME. It's just a matter of what we're looking for on the PHP side, i.e. $_SERVER['HTTP_X_FILENAME'] vs $_SERVER['HTTP_X_FILE_NAME'].

[Pete]

Pure fluke. I figured that there must be something wrong with the headers coming back from the server since it worked on other servers, and found a blog post where someone said it was good practice to give the browser an idea of the content type (but alas I didn't bookmark it... think it was a search for "xhr header" so if I find it I'll post the link.

From my days working with an old download script, octet-stream was the default mime-type - think of it as a slightly lazy catch-all. You could specify the precise file type, but you would then need to have a mime-type table to send the right header for every possible filetype allowed by a field (which is nearly impossible as the user can specify their own types!), whereas in my experience octet-stream was fine for all cases I've run into in the past with those sort of scripts.

In fact, since this was a Firefox issue, this post seems rather more helpful than the one I originally found as there's a section where it attempts to work out the mime type:

EDIT: https://developer.mo..._XMLHttpRequest

EDIT2: Although Mozilla's example above defaults back to plain text, so not the best example as what we're sending is a file. There's a brief description of octet stream here: http://kb.iu.edu/data/agtj.html

[Pete]

That last link wasn't very useful either after reading it again as several posts lile that one assume that because octet stream tells the browser to expect application data that it will be a .exe file, which is not the case - its any binary file.

This link better describes it: http://mimeapplication.org/octet-stream.html

It's more of a catch-all that prevents us from having to specify a correct MIME type. Thinking back to the download script I used to use again, there was a list of MIME types in the source code and if a file didn't match any but was still an allowed file type (as set by the user - same as you can do in ProcessWire) then it defaulted to this.

Not sure if that's much help. MIME types are just yet another thing where if you're not careful you end up with different results in different environments, but come with a handy catch-all that seems to work in all the cases I've used it in.

[ryan]

Thanks Pete, sounds like we should definitely go ahead and add the octits-stream to keep the firefox happy. I will plan to add this. Thanks for your research and testing here.

[Pete]

Amusing mis-spelling there - wonder if it was intentional or iPhone

[Adam Kiss]

[…] add the octits-stream to keep the firefox happy. […]

I just found this. Hilarious.