SMTP mail arrives in Textpattern (finally!)

Bloke · 2024-03-22 22:08:41

jakob wrote #336956:

Excellent, yet another string to the bow of com_connect

Yeah, I’m pleased with the implementation on the whole. It could do with some more thorough testing. I’ve only tried it with one file uploader in a form, with and without multiple. It should allow multiple file upload widgets of differing types and accept lists.

There’s a tonne of validation goes on server side, but I’ve not vigorously tested what happened if you exceed file size maximums and so forth. At the moment I think it will not send the entire message if one of the files goes over size. And, annoyingly, if you then repick the files and try to resubmit the form, it will tell you the form has already been used and the page needs refreshing. That’s irritating and I’d love to find a way round it. Creative solutions welcome.

the com_connect_file needs adding to the readme table of contents

Oops. Probably missed one. I’ll fix that for completeness, thank you.

phiw13 · 2024-03-25 05:45:25

Some attempt at testing:

localhost, Apache + PHP 8.3, com_connect updated.
debug mode: ON.

Code used:

<txp:com_connect_file label="Attach PDF file" accept="application/pdf" max="1000000" multiple="0" />

Pressing submit, com_connect error message, attaching 1 small PDF file (~ 11kb ):

Attach PDF file must not exceed 1000000.

Wut ? 11kb is more than the specified max-limit ? (in bytes, according to the docs)
Oh, the message might be more kind when saying “not exceed 1000000 bytes” (although little old me thinks kb would me much more clear for the average user ).

OK, trying without specifying a max value, now the error says not exceed 8388608 (which is the value set in php.ini, I think (upload_max_filesize = 8M))

sigh/ can‘t seem to get further there…

–^–

Docs:
- Perhaps you may clarify what the values for multiple are (e.g. multiple="1" -> multiple files, multiple="0" -> 1 file only)

- the last sentence in the “required” entry does not belong there:

required=“boolean”
Whether this file must be supplied. Available values: 1 (yes) or 0 (no). Default is whatever is set in the <txp:com_connect> tag’s required attribute – if neither attribute is set then default is 1. You should set the required attribute on only the first radio button of the group, or set the same identical attribute value on all radio buttons in the group.

Bloke · 2024-03-25 06:49:51

Sorry about the hassle. For some irritating reason, I had a real job trying to get the uploads file size limited. Some browsers were fine with the hidden max_file_size attribute and the server side testing per file, some treated it as an overall size for all uploads, and some ignored it or always told me that no matter what I uploaded was too big.

Thought I’d ironed it out, but it looks like I need to do more rigorous cross browser testing. Thanks for giving it a go. I’ll fix the copy n paste docs error too, thank you.

phiw13 · 2024-03-25 07:33:27

I see I forgot to mention it, my testing was done with Safari TP, Brave and Firefox.

I hope you manage to iron it out as this could make com_connect really powerful.

colak · 2024-03-25 16:31:47

Just tested with a 10.1MB file.

Code used.

<txp:com_connect_file label="Send file" max="8000000" accept=".pdf,.docx,.doc,.txt,.rtf,.pages" required="1" />

All worked like a dream on PHP v8.0.30 and latest txp 4.9.0-dev (82e9fc43f1cb2612ff6a22219a774a07)

phiw13 · 2024-03-26 03:14:52

With the latest update to com_connect – I get the same result as before both locally and a remote server (running PHP 8.2) (Attach pdf file must not exceed 1000000.)

Observation: marking the txp:com_connect_file as not required (required="0") makes the file upload work – the form is submitted without problem (localhost is not configured to actually send email).

From the live server, I receive the email. But no file is attached.

If I do not specify a template for the email body, then the email has this in the body field:

Email: xxx@yyy.tld

Name: tester2

Subject: Site issue

MAX_FILE_SIZE: 1000000

Message: testing the attachment of files(2)

I accept the above information will be used to contact me.: Yes

if I do specify a template for the email body (<txp:com_connect […] body_form="pw_contact_message_body">), then I recieve the same email, without the MAX_FILE_SIZE line (an no attached file).

The body_form contains this line (the name="attached_pdf" is the name of the file upload field):

<txp:com_connect_if name="attached_pdf"><txp:com_connect_value name="attached_pdf" /></txp:com_connect_if>

Dunno, maybe I am doing something totally wrong, I have no idea what it might be.

Full form template:

<h1><txp:section title='1' /> – Empty Spaces</h1>
<txp:com_connect class="contact-form-form" classes="element:warn-field, required:required-field, wrapper:error-message" label="" to="xxx@l-c-n.com" from="xxx@l-c-n.com" subject="[emps] test form"  thanks="First part of testing has been successful" body_form="pw_contact_message_body">

<section class="contact-form-container" aria-label="contact form">
<div class="input-field"><txp:com_connect_email break="" class="" label="Email" name="email" placeholder="Your email address" /></div>
<div class="input-field"><txp:com_connect_text break="" class="" label="Name" name="name" placeholder="Your Name" /></div>
<div class="input-field contact-subject">
  <txp:com_connect_select break="" class="" label="Subject" name="subject" options="{Select one},General enquiry,Site issue,Other…" />
</div>
<div class="input-field"><txp:com_connect_file break="" class="" label="Attach pdf file" name="attached_pdf" accept="application/pdf" max="1000000" required="0" /></div>
<div class="contact-message"><txp:com_connect_textarea class="" name="message" break="" label="Message" max="256" /></div>
<div class="input-radio-field"><txp:com_connect_checkbox class="" label="I accept the above information will be used to contact me." name="accept" /></div>

<div><txp:com_connect_text hidden label="" name="office_phone" required="0" />
<txp:com_connect_expect name="office_phone" /></div>
<p><small>Please note that fields marked with <span class="required">*</span> are required</small></p>
<txp:com_connect_serverinfo name="REMOTE_ADDR" label="IP number" />
<div class="submitfield"><input type="submit" value="Submit"></div>
</section>
</txp:com_connect>

nothing crazy or unexpected I think.

phiw13 · 2024-03-26 03:19:12

BTW, a small issue: classes specified on the <txp:com_connect container are not propagated to the txp:com_connect_file tag.

<txp:com_connect class="contact-form-form" classes="element:warn-field, required:required-field wrapper:error-message">

<div class="input-field">
  <txp:com_connect_file break="" class="" label="Attach pdf file" name="attached_pdf" accept="application/pdf" max="1000000" multiple="0" />
</div>

output

<div class="input-field">
  <label for="attached_pdf" class="comRequired">Attach pdf file</label>
  <input class="comRequired" accept="application/pdf" id="attached_pdf" name="attached_pdf" multiple="" type="file" form="com394332ecc17c4f8b8b23ab47738aec4b" required="">
</div>

Expected: the class="comRequired" is replaced by class="required-field"

Bloke · 2024-03-26 07:08:20

Pants. Forgot to hook the tag into those. Great spot, thank you.

Dragondz · 2024-03-26 08:45:14

Hi

Nice evolution for the plugin!

I admit that i am wondering if it s too complicated to create a plugin that instead of sending the files on Email to store them on the server ?

Cheers.

Bloke · 2024-03-26 09:37:39

Dragondz wrote #336965:

a plugin that instead of sending the files on Email to store them on the server ?

That’s easy. The plugin would hook into the com_connect.deliver callback, grab the $fields array which holds all the data passed into it, loop through the attachments and move_uploaded_file() each of them to your chosen location. Then just return com_connect.skip or done or something like that (I forget what they’re called offhand) to halt regular processing of the mail.

Edit: you could maybe also alter the body text and remove the attachments after you’ve moved them, then return true so the email is sent anyway with the other bits of the submitted form as you require. That gives a prompt to whoever needs to know that the files have been uploaded and stored.

Last edited by Bloke (2024-03-26 09:40:29)

Dragondz · 2024-03-26 10:32:12

Hi Stef

Thanks for the details.

I will try to put something together.

Cheers.

phiw13 · 2024-03-27 05:16:48

More interesting issues:

In the (required) email field, fill in an address of the type “string @tools” – yes, that is a valid email address, it could be used on a private network (like bigCO, university, … for the internal network).
Fill the (required) file_upload field
(fill other fields as needed)
submit

The plugin error handler rejects the email address, flags the error.

Now look at the <input type=file>: the contents has been blown away and the field has lost its upload button (source code inspection shows that the type=file attribute disappeared and the value attribute is not included or is empty).

A typo in the email domain or TLD could also trigger the error and bug, eg. @tool.su (five characters required for that TLD).

Bloke · 2024-03-27 09:08:57

That is indeed bizarre. I thought I saw that the other day when I was testing but put it down to my debug output interfering. The input control had been replaced with a text box somehow after submission.

I believe the invalid email filter is unfortunately out of our hands but I will check. PHP has a built in function:

filter_var($email, FILTER_VALIDATE_EMAIL);

We employ that, and it does have its issues with non-standard addresses, but we also wrap it in our own validate email function, which may be doing something we don’t want.

The fact the form loses the files on submission with errors is irritating. I don’t know how to get round that and keep the link to the files in the input box. I’ll have to ask the internet if there’s a way round it, but I suspect it’s not possible. Unless anybody here knows a way?

Bloke · 2024-03-27 09:35:56

Bloke wrote #336971:

I suspect it’s not possible.

Indeed it is not

It’s a lot of extra work to store IDs to files and restore the links if the file input is not sent on resubmission. Plus, what do we do if the user decides they don’t want to submit one or more of the files they’ve uploaded that are loitering on the server? And how do we clean up existing ones?

Lots of rakes to step on.

phiw13 · 2024-03-30 05:37:27

On a different domain, but same server than my test playground, i managed to see the file upload/attachment work reasonably well – as long as I use the default body form. If I use a custom template for the message body (body_form atribute) no email ever reach me (I verified that my custom template is not to blame, as it works (email send and received) when no attached files are included).

What would be the magic formula here to reference the file ?

I tried both with and without <txp:com_connect_value name="" />, incl in combination with <txp:com_connect_if name="". No go :-(.
I did not find anything in the httpd or php logs

(asking before I go bothering the host support team, in case of false expectation)

–^–^–^–

That is indeed bizarre. I thought I saw that the other day when I was testing but put it down to my debug output interfering. The input control had been replaced with a text box somehow after submission.

Yeah that is seriously annoying. Any error (as deemed by com_connect) that is not caught by the browser build-in validation triggers this great disappearance trick.

The fact the form loses the files on submission with errors is irritating

I don’t think you can prevent that unfortunately. The only eventual workaround would to be to extend the browser build-in validation / error-reporting mechanism with your own messages with JS – at least that is supposed to be possible for required fields. But I am not sure it is worth the effort, and cover enough ground.

–^–

BTW – email validation: in my book it is only a minor nuisance; being fairly strict in what you accept here is probably on the safer side.

Textpattern CMS

Textpattern CMS support forum

#16 2024-03-22 22:08:41

Re: SMTP mail arrives in Textpattern (finally!)

jakob wrote #336956:

#17 2024-03-25 05:45:25

Re: SMTP mail arrives in Textpattern (finally!)

#18 2024-03-25 06:49:51

Re: SMTP mail arrives in Textpattern (finally!)

#19 2024-03-25 07:33:27

Re: SMTP mail arrives in Textpattern (finally!)

#20 2024-03-25 16:31:47

Re: SMTP mail arrives in Textpattern (finally!)

#21 2024-03-26 03:14:52

Re: SMTP mail arrives in Textpattern (finally!)

#22 2024-03-26 03:19:12

Re: SMTP mail arrives in Textpattern (finally!)

#23 2024-03-26 07:08:20

Re: SMTP mail arrives in Textpattern (finally!)

#24 2024-03-26 08:45:14

Re: SMTP mail arrives in Textpattern (finally!)

#25 2024-03-26 09:37:39

Re: SMTP mail arrives in Textpattern (finally!)

Dragondz wrote #336965:

#26 2024-03-26 10:32:12

Re: SMTP mail arrives in Textpattern (finally!)

#27 2024-03-27 05:16:48

Re: SMTP mail arrives in Textpattern (finally!)

#28 2024-03-27 09:08:57

Re: SMTP mail arrives in Textpattern (finally!)

#29 2024-03-27 09:35:56

Re: SMTP mail arrives in Textpattern (finally!)

Bloke wrote #336971:

#30 2024-03-30 05:37:27

Re: SMTP mail arrives in Textpattern (finally!)

Board footer