[REQUEST] Add file upload to contact form

dorka · 2015-05-12 05:26:22

Hi, I am not a developer so I am not sure if I am entitled to place my wish in this list, but it is the best place I found.
I need an extention to zem_contact_reborn enabeling (perhaps with the help of mem_form) sending attachment to a mail recipient via contact form.
I will be glad to commission this work to someone. Only I need help estimating the budget. Thanks.

Bloke · 2015-05-12 14:35:06

dorka wrote #290663:

I need an extention to zem_contact_reborn enabeling (perhaps with the help of mem_form) sending attachment to a mail recipient via contact form.

The new in-development zem_contact_reborn ought to be able to handle this with a module (plug-in). It would probably offer:

A tag for inserting a file input box (although you might be able to use <txp:zem_contact_text type="file" />, it’d be better to have a dedicated tag so it could check file size limits and permit only certain mime types, etc).
A mechanism for receiving the file, encoding it and adding the appropriate headers to the mail message, then returning the bundle to ZCR to do the mailing process.

The latter could either be done on submit, or using a jQuery uploader plugin which transmits the file via AJAX in the background like Gmail does. The submit handler is simpler, but less user friendly. The AJAX method is sexier, a lot more involved code-wise, and possibly with more potential to clutter your file system with part-finished uploaded files from bots using the contact form. Not really thought it through fully.

I could certainly try and knock up a module to see how well it works.

btw, although tempting, I’d shy away from permitting multi-file uploads. If people really want to send you many files, they can zip them up.

mem_form would work as an alternative, but, well it’s mem_form so the documentation is fun to decipher. Not sure if it’s possible to integrate the two plugins or you’d have to use it in lieu of ZCR.

dorka · 2015-05-13 08:02:44

Hi Bloke,
thank you, that will be great!
if I get it right, there are two steps involved:
1. releasing the new version of ZCR
2. writing the module that will handle the file submition – the one you write about.
I surfed around a bit to find out how far is the new ZCR from launch, but didn’find much. Is there someone out there who knows? Ruud probably?
And is there something I can do to motivate you guys to spare your little time and big skills to this little gadget?

ruud · 2015-05-13 08:14:50

dorka wrote #290707:

I surfed around a bit to find out how far is the new ZCR from launch, but didn’find much. Is there someone out there who knows? Ruud probably?

No, that would be bloke/stef

Bloke · 2015-05-13 10:20:00

dorka wrote #290707:

how far is the new ZCR from launch

It’s basically done but I have one pending bug report to chase down when I get a moment.

is there something I can do to motivate you guys to spare your little time and big skills to this little gadget?

Let me know how you’d prefer it to work (AJAX or on-submit) and I’ll see what I can do.

dorka · 2015-05-13 11:21:46

On submit is just fine.
I suppose when you say “on submit” you mean that the upload of the file starts when the user submits the entire mail. I am thinking of a solution when you can upload the file with separate command and submit the entire mail afterwards: Choose file > Upload file > Submit mail. This will prevent interrupting the upload by clicking away. Or is this solved otherwise?

Bloke · 2015-05-13 11:37:29

dorka wrote #290719:

when you say “on submit” you mean that the upload of the file starts when the user submits the entire mail.

Yes, nothing is done until the user clicks Send.

The alternative is to do like Gmail and other mail clients, whereby the moment you select a file it begins uploading in the background, then gets attached at Send time. That’s a lot more work because it requires public-side AJAX / jQuery code.

Things we need to do under this approach:

Prevent form submission until the upload has finished, which requires signalling.
Check only one file is uploaded per mail (which seems reasonable given that zip exists).
Tie the uploaded file (dangling in some server-based no-mans-land temp directory) to the mail.
Ensure any used, unused, partially-uploaded, broken, or dangerous files are purged to avoid cluttering the file system of the server.

Since the default upload place is a temporary folder and Textpattern ships with this tmp folder publicly accessible, there’s a chance that someone could upload a script or some payload which would be runnable from any browser. In theory of course. That might not be a legitimate concern if the system temp folder is used, I’m not sure without trying it.

dorka · 2015-05-13 11:51:48

How about sticking to the first option, but uploding manualy with a separate command as I wrote above?

dorka · 2015-05-13 11:55:02

I guess the issue with publicly acsessible tmp folder is irrelevant to the process of uploading we chose. Am I right?

Bloke · 2015-05-13 12:02:20

dorka wrote #290725:

How about sticking to the first option, but uploding manualy with a separate command as I wrote above?

Not entirely sure how to get that to work.

ZCR uses the first pass (displaying the form) to configure itself to know what to expect later, and then the second pass (on submission) validates form inputs and checks no violations have taken place. So it needs to “know” in advance to expect the file. EDIT: Maybe if it was a discrete process, and always executed first, we could somehow write a hidden or secret field to the form to indicate which file the mail should attach. Kind of inconvenient if someone decides on a whim to add a file after they’ve started typing though…

dorka wrote #290726:

I guess the issue with publicly acsessible tmp folder is irrelevant to the process of uploading we chose. Am I right?

Yeah. It’s probably of little concern as PHP will most likely use the system tmp directory.

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!

Last edited by Bloke (2015-05-13 12:04:08)

colak · 2015-05-13 12:06:36

Bloke wrote #290721:

Since the default upload place is a temporary folder and Textpattern ships with this tmp folder publicly accessible…

I always move that below the root of the site as I hope that it boost’s the site’s security

dorka · 2015-05-13 12:16:58

Ok, I see I understand too little to be a good partner in this decision. I guess I am fine with On submit option, but if you decide AJAX would appeal to more users and will take longer before refactoring becomes absolutely necessary, I won’t argue.

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.

Textpattern CMS support forum

#1 2015-05-12 05:26:22