scenario:
My form has “name”, “mail”, “subject”, “message”, “some_more” fields. I want to receive a mail in this form:
subject: [{{app.name}}] {{subject}}
reply_to: {{name}} <{{mail}}>
body: html template with {{message}} and all field contents
altMessage: pretty text message without HTML
The templating is no problem. I just have to pass the options anyhow.
A few days ago @artur added this useful trigger to the forms
$this->app->trigger('forms.submit.before', [$form, &$data, $frm]);
and he added the option to add altMessage
to the mailer options. So I started to rewrite my FormValidator addon to use the new features.
Well, it’s nice to validate or manipulate the submitted data, but there is no option to pass mailer options. If it would be like [$form, &$data, $frm, &$options]
, I could manipulate everything I need.
While fiddling with the forms, I repaired a bug to have mail subjects again, but I don’t like this solution. If I don’t want, that users can change the mail subject with a simple POST, I have to validate against it and send my own $_REQUEST['__mailsubject'] = "..."
to have my custom subject. I think, it should be in $options['mail_subject']
.
I didn’t understand, how to send the right csrf hash to use the inbuilt variant to pass form_options through the api and actually, I don’t want to use it. It’s a security risk to give users the ability to change mailer settings.
Another way would be, to bypass the defaults
- by extending the forms and adding a new api endpoint or
- disable the inbuilt mailing and do the mailing inside my script from
forms.submit.before
orforms.submit.after
.
But this doesn’t feel right.
I started a test repo with a few fixes here.
I posted the same text 3 days before in the issues, because it felt more like an issue, than a support question. But now I think, that the forum is a better place to discuss such things.