[REQUEST] Add file upload to contact form

uli · 2015-05-13 14:24:25

Bloke wrote #290729:

Note to self: find a way to bust this conversation away from the sticky topic in which it resides as it’s kind of off-topic!

Done.

aslsw66 · 2015-05-14 12:41:07

I know this is the context of email, but I would like to be able to do file upload more broadly eg. along the lines that sed_afu did. Yes, I note the various security issues involved which means lots of care is required, but it’s still there!

I assume that I could hack something together from this functionality – once I see the code for how files are handled more generally. I’m not PHP expert, but I’m always happy to try something out once I can see someone else’s example ie. “stand on the shoulder of giants”!

Bloke · 2015-05-20 13:47:25

First drop of a tentative zcr_file_attach plugin has been mailed to dorka for evaluation. It hooks into zem_contact_reborn only, so not much hope of it being a standalone utility right now, aslsw66.

It’s not very clever. Here are a few problems that may or may not have solutions at some point:

It only accepts one file. But zipping is fine to bypass this restriction.
Currently requires jQuery to be present on the page so the enctype attribute can be added. Will probably figure out a better way using callbacks, or drop back on native JavaScript. It’s only one line of code.
Files are sent on submit (not asynchronously via AJAX) so if you pick a large file, you have to wait, potentially timing out the page.
File size checks via the maxlength attribute are done, but it seems browser dependent what it does in the event of a violation. Chrome, for example, will swallow the file and not even throw any notification, so the plugin thinks nothing’s been submitted, which means I can’t display an error. The form just reverts to as it was, with no message or anything. Frustrating. Might be the same in all browsers, dunno.
The accept attribute allows lists of acceptable file extensions or MIME types to be designated. Browsers use this to limit your choices in the file picker, but PHP seems to blindly set the MIME type to whichever one is derived from the file extension. So if you set accept="image/jpeg, image/png" and renamed presentation.pdf to presentation.jpg, PHP would report the file was a JPG and let it through. D’uh. Might be some extra checks I can do with the native file calls or by reading the file sigs to determine the actual MIME type. Wrote a script to do that a while back which ran through an entire folder of un-suffixed files and set the correct .extension by regexing file headers in hex and comparing them with a giant lookup table. Fun.
If you submit a form and other fields fail, the file widget does not retain its previously-selected file. This is actually a universally-implemented browser feature and is not supported in HTML for security reasons: no default filename. No known workaround.

That said, if anybody wants a pre-release copy to tinker with, drop me a line.

dorka · 2015-05-22 07:59:59

Hi Stef,
I am happy to say that the plugin works just great.

Currently requires jQuery to be present on the page so the enctype attribute can be added. Will probably figure out a better way using callbacks, or drop back on native JavaScript. It’s only one line of code.

It is important to mention that it requires also a modified version of ZCR, it didn’t work with the previously installed version.

Files are sent on submit (not asynchronously via AJAX) so if you pick a large file, you have to wait, potentially timing out the page.

I tested on a broad band, so the file size limitation took action before the time out of the form, anyway. It would be realy usefull though if there was a visible progress bar mapping the upload. This will prevent from leaving the page before the transfer is finished.

File size checks via the maxlength attribute are done, but it seems browser dependent what it does in the event of a violation. Chrome, for example, will swallow the file and not even throw any notification, so the plugin thinks nothing’s been submitted, which means I can’t display an error. The form just reverts to as it was, with no message or anything. Frustrating. Might be the same in all browsers, dunno.

Well, it worked just fine in Chrome, FF and Netscape on McMavericks and in Chome an FF on Win 8.1. I tried the plugin without and with file size limitation. In both cases an allert appeared on reaching the server/plugin limit.

The accept attribute allows lists of acceptable file extensions or MIME types to be designated. Browsers use this to limit your choices in the file picker, but PHP seems to blindly set the MIME type to whichever one is derived from the file extension. So if you set accept=“image/jpeg, image/png” and renamed presentation.pdf to presentation.jpg, PHP would report the file was a JPG and let it through. D’uh. Might be some extra checks I can do with the native file calls or by reading the file sigs to determine the actual MIME type. Wrote a script to do that a while back which ran through an entire folder of un-suffixed files and set the correct .extension by regexing file headers in hex and comparing them with a giant lookup table. Fun.

Didn’t test sending fake .jpg file, I think Stef could be trusted that this hack realy works and there is nothing we can do about it :-).

Suggestions for taking it further:

Updating the existing zcr in order it to work with zcr_attach_file right out of the box
Progress bar mapping the file upload + optional explanation note bellow.
Options for localizing the texts in:

excessed-file-size allert
not-accepted-file-type allert
explanation note bellow the future progress bar

Thanks Stef, realy great work!

Bloke · 2015-05-22 08:32:01

dorka wrote #290983:

I am happy to say that the plugin works just great.

Yay!

it requires also a modified version of ZCR, it didn’t work with the previously installed version.

Yes, I made a few changes the other day on GitHub to fix a few warnings that were thrown due to the use of the file attach plugin.

a visible progress bar mapping the upload.

That would need to be done via AJAX, as soon as you select the file. I’ll see if I can find a suitable jQuery plugin or something that works and is permitted to be embedded without restriction in the plugin. Failing that I might have to (gasp) code something myself, but that’s a last resort :-)

Incidentally, doing this might permit us to allow more than one file to be attached, perhaps with a limit specified by a tag option. Who knows.

Updating the existing zcr in order it to work with zcr_attach_file right out of the box

When the new plugin goes into beta (which I’d hoped to do today, but maybe it won’t be just yet) it’ll ultimately replace the current version.

Options for localizing the texts

This is already possible through the magic of Textpacks. Although there are no official editors for language strings (why has nobody written a plugin yet?!) you can either add the language strings to your txp_lang database table if you’re comfortable doing that, or install ied_plugin_composer.

The plugin composer makes it easy on a plugin-by-plugin basis. To use it, open up the zcr_file_attach plugin for editing, open up the Textpacks twisty and enter the plugin’s prefix zcr_file. As soon as you tab out of that box, the composer will hunt through the plugin code for textpack strings and show the current English ones. Pick your language from the dropdown and put in your own strings. That’s it.

If you want to export them for publishing on your own site or to send them to me for inclusion in later versions of the plugin, you can do so using the Export Textpack(s) facility at the bottom of the page. Select the language(s) you want to export and hit the link.

dorka · 2015-05-22 09:04:45

That would need to be done via AJAX, as soon as you select the file. I’ll see if I can find a suitable jQuery plugin or something that works and is permitted to be embedded without restriction in the plugin. Failing that I might have to (gasp) code something myself, but that’s a last resort :-)
Incidentally, doing this might permit us to allow more than one file to be attached, perhaps with a limit specified by a tag option. Who knows.

Sound good to me! See what you can do, it will be great.

Just IMHO: sending multiple files via email form is not a big priority. Sigle file will do for the 80% of the cases, when it is needed. So it will be great as a side effect (and of course, it will be cool feature to have) but… :-).

Bloke · 2015-05-22 10:18:39

dorka wrote #290987:

Sound good to me! See what you can do, it will be great.

Will do. Probably won’t be next week though. My Internet coverage will be patchy.

sending multiple files via email form is not a big priority.

Noted. But usually, jQuery / AJAX upload plugins support multiple uploads so it might just come “for free” as part of the package. The trick will be to find a way to limit the number of files to 1 or some admin-specified value.

EDIT: On this note, anyone have any recommendations for lightweight jQuery / javascript uploaders that are compatible with GPL2 and don’t have commercial usage licence restrictions? I used to always default to uploadify but maybe there’s something better now?

Last edited by Bloke (2015-05-22 10:20:38)

philwareham · 2015-05-22 10:53:57

Bloke wrote #290984:

That would need to be done via AJAX, as soon as you select the file. I’ll see if I can find a suitable jQuery plugin or something that works and is permitted to be embedded without restriction in the plugin. Failing that I might have to (gasp) code something myself, but that’s a last resort :-)

jQuery-File-Upload is very popular and is MIT licenced – could that be a possibility?

Or there is Plupload file uploader as used by WordPress and others, which is GPLv2 (the same as our licence) – I’d be very keen for that in Textpattern core in the future.

Bloke · 2015-06-03 09:14:21

philwareham wrote #290992:

“jQuery-File-Upload” … “Plupload file uploader”

I like the look of Plupload, thanks for the tip. It’s big, but the fact everything is rolled into one JS file means it’s easy to embed in the zcr_file_attach plugin.

On the surface it’s fairly simple to handle the server side stuff. Just gotta figure out how to tell ZCR that there’s a file uploaded in a temp location “waiting” to be attached when the form is submitted. Must be a way to do that. I’d ditch the silverlight+flash fallback mechanisms as they wouldn’t work on iThings, and I don’t particularly like either platform anyway.

It is quite bare though and would need quite a bit of love to make it as pretty out of the box as jQuery File Upload. jFU itself is a sprawling mess of files that I’d need to untangle to weed out the parts that are not necessary for simple file attachments, so I probably won’t go there.

Unless anyone comes up with anything else I think it might be Plupload FTW.

philwareham · 2015-06-03 09:17:43

I can look at the pretty stuff for you, I think.

Bloke · 2015-06-03 09:23:33

philwareham wrote #291272:

I can look at the pretty stuff for you, I think.

That’d be ace, thanks. There are some nice looking examples for Plupload but they all seem to use jQuery UI, which is not available (yet) in core to use by the plugin. I wouldn’t want to have to bundle that in the plugin as well.

Would be great if the file attach plugin could be modular so you could choose the front-end you prefer, but they all work so differently in the way they handle AJAX that it’d be tough to implement. I don’t have much choice other than to pick one that’s lightweight and pretty enough to offer basic file uploading with progress bar / delete ability.

philwareham · 2015-06-03 09:27:01

jQuery UI is in core of Textpattern 4.6. I’d rather use that than create new stuff. How about minimal version for 4.5 and jQuery UI version for 4.6?

Textpattern CMS

Textpattern CMS support forum

#13 2015-05-13 14:24:25

Re: [REQUEST] Add file upload to contact form

Bloke wrote #290729:

#14 2015-05-14 12:41:07

Re: [REQUEST] Add file upload to contact form

#15 2015-05-20 13:47:25

Re: [REQUEST] Add file upload to contact form

#16 2015-05-22 07:59:59

Re: [REQUEST] Add file upload to contact form

#17 2015-05-22 08:32:01

Re: [REQUEST] Add file upload to contact form

dorka wrote #290983:

#18 2015-05-22 09:04:45

Re: [REQUEST] Add file upload to contact form

#19 2015-05-22 10:18:39

Re: [REQUEST] Add file upload to contact form

dorka wrote #290987:

#20 2015-05-22 10:53:57

Re: [REQUEST] Add file upload to contact form

Bloke wrote #290984:

#21 2015-06-03 09:14:21

Re: [REQUEST] Add file upload to contact form

philwareham wrote #290992:

#22 2015-06-03 09:17:43

Re: [REQUEST] Add file upload to contact form

#23 2015-06-03 09:23:33

Re: [REQUEST] Add file upload to contact form

philwareham wrote #291272:

#24 2015-06-03 09:27:01

Re: [REQUEST] Add file upload to contact form

Board footer