SMTP mail arrives in Textpattern (finally!)

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.

Bloke · 2024-03-30 06:54:09

Ah yes. Internally, the name of the file input control is a random md5-string concatenated with the name of the input field. Which is great for avoiding clashes but useless if you want to query it. Might have to rethink that. Thank you for the alert.

phiw13 · 2024-03-30 07:14:21

OK… old man deletes draft email to host support team.

Thanks for confirming I did not miss the magic incantation!

Textpattern CMS

Textpattern CMS support forum

#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!)

#31 2024-03-30 06:54:09

Re: SMTP mail arrives in Textpattern (finally!)

#32 2024-03-30 07:14:21

Re: SMTP mail arrives in Textpattern (finally!)

Board footer