More options for email adresses requested

[brandsis]

Last night I updated my Form Block Suite plugin to the latest 4.1.1 version and the 'from_email' config setting appears not to be working now. It was working perfectly before.

This is what I have in my config.php file...

'microman.formblock' => [
    'from_email' => ["form@brandsistency.com" => "Brandsistency website"]
],

But this is how my Inbox now looks...

All I did was replace the plugin folder. I made no changes to config.php or to the form in the Panel. Did I miss a required change?

[plain-solutions-gmbh]

Is could reproduce the Bug and it's fixed in Version 4.1.2. If it still occurs, make sure the field Recipient's address is empty.

[brandsis]

Hi, Roman. I've installed 4.1.2, cleared both the Kirby and browser cache and retested the form. The issue is still occurring. The submission process works fine but the received email still displays the raw server email address as the sender, rather than what's configured in config.php.

I'm not sure I understand your suggestion to empty the Recipient's address field. I did try it but that means, of course, that the email does not send and it's the email that's the issue.

[brandsis]

Note that this test was done in my test site, which is internet-facing.

[plain-solutions-gmbh]

Sorry, something was missing try again with version 4.1.4.

[brandsis]

Roman, I've installed v4.1.3 and still no joy...

[brandsis]

Hi, Roman.

Just in case this update is useful, I reverted my plugin to v4.1.0 for the purpose of retesting. 4.1.0 was the version running when the from_email setting was last working, but it has not fixed the issue. I'm not sure why. As before, I have this in my config...

'microman.formblock' => [
    'from_email' => ["form@brandsistency.com" => "Brandsistency website"]
],

...but emails are still arriving from 'brandsis@premium88.web-hosting.com'.

(As this hasn't worked, I'll update back to v4.1.3.)

[plain-solutions-gmbh]

It's fixed in 4.2.1. Please close this Issue if it's solved....

[brandsis]

Hi, Roman. It looks like the display name/email address is not picking from the from_email config setting but is instead using the 'Recipient's address' field from the Panel. In other words, the email says it's coming from the same email address that it's being sent to. I have 'from_email' => ["form@brandsistency.com" => "Brandsistency website"] in config.php but this is how the email arrives...

Similar to the submit button text discussed separately, it would be helpful to be able to specify different senders – at least different display names – for different forms. For example, "Website contact form" or "Website application form". Would that be possible using Extend options as well? Or, would it be worth adding new fields "Sender's address" and "Sender's display name" in the Send notification section?

[plain-solutions-gmbh]

Explentaion: Why the name ist not shown:

Leave this field empty and the from_email option will be taken:

If it's empty and you don't want to show this field in you panel. Overwrite the props 'type: hidden' on the notify_email field. (I don't think I need to explain how to extend an option anymore)

Feature: Custom Sender/Receiver Options for Notifications/Confirmation

Version 4.3.0 includes 2 updates:

1. Following items are now official a part of messages: notify_email, notify_from, notify_reply, confirm_to, confirm_email, confirm_reply
2. For these items, you can use Name <mail@domain.com> and placeholders.

Please test it and let me know...

[brandsis]

Thanks for v4.3.0, Roman. I do like your treatment where notify_from is the {{ name }} <{{ email }}> of the submitter. And the reply address is the submitter's as well.

Are those new settings included by default or do I need to add them as fields via form_notify.yml and populate them in the Panel? I installed 4.3.0 and then deleted from_email from config.php – thinking the new items would handle this – and now I am not receiving emails at the notify_email address.

[brandsis]

Also, is there a way to hide/remove the CAPTCHA response from the email? It occurs to me that the recipient of the submission doesn't need to see the response to that question, as its only purpose is spam protection.

I have managed to hide it from the k-dialog modal view in the Panel through panel.css but not sure if/how I can do the same for the email output.

[brandsis]

Roman, I've just created a new form_notify.yml file in the folder /site/blueprints/snippets and added sections for notify_from and notify_reply as follows...

notify_from:
  label: form.block.options.notify_from
  type: text
  width: 1/2
  when:
    enable_notify: true

notify_reply:
  label: form.block.options.notify_reply
  type: text
  width: 1/2
  when:
    enable_notify: true

But those fields have not appeared in the Panel...

I tried hard coding the labels as "Sender's address" and "Reply address" respectively but that did nothing.

Am I doing something wrong?

[brandsis]

I've moved that new blueprint content from form_notify.yml to form_options.yml. The fields do then show up in the Panel...

But...

• The dynamic labels don't populate 'friendly' text, so I had to hard code them. Do the fields not have label defaults?
• I populated the fields with {{{name}} <{{email}}> and {{email}} but still submission emails do not arrive.
• It would be great if notify-related fields could be grouped together. The same applies to confirm-related fields but I haven't tried customising that section yet.

[brandsis]

Hi, Roman @youngcut.

I don't know why it wasn't working before but submission emails have now started to arrive, which is great news. I can now get this working for the client site I'm migrating to Kirby. 😀

Whilst they're not crucial, it would be helpful if you can feed back on the other items, as I think they would improve the UX...

• Fields added to (a copy of) form_notify.yml to be grouped within that section in the Panel. Currently, they appear at the bottom of the options drawer. So, for example, the notify_from and notify_reply fields are separated from notify_email, notify_subject and notify_body.
• The same for form_confirm.yml fields.
• The spam protection entry to be hidden or hideable from the response in the Panel (which I've done via panel.css) and from the notification and confirmation emails.

Many thanks.

[brandsis]

Hi, Roman. I realised that I was slightly wrong in my last comment. Unless I am doing something wrong, which is perfectly possible, my custom form_notify.yml is not working.

The reason the notify_from and notify_reply fields were at the bottom of the options drawer is that I'd mistakenly left them in the form_options.yml file. But if I remove them there, so they are included ONLY in /site/blueprints/snippets/form_notify.yml, they do NOT appear in the Panel even after clearing all cache. They only appear in the Panel if they are included in form_options.yml.

This is my form_notify.yml content...

enable_notify:
  type: toggle
  label: form.block.options.enable_notify

notify_email:
  label: form.block.options.notify_email
  type: text
  placeholder: form.block.options.notify_placeholder
  help: form.block.options.email.help
  width: 1/2
  when:
    enable_notify: true

notify_subject:
  label: form.block.options.notify_subject
  type: text
  help: form.block.default.help
  width: 1/2
  when: 
    enable_notify: true

notify_body:
  label: form.block.options.notify_body
  type: textarea
  help: form.block.default.help
  buttons: false
  when:
    enable_notify: true

notify_from:
  label: Sender's address
  type: text
  width: 1/2
  when:
    enable_notify: true

notify_reply:
  label: Reply address
  type: text
  width: 1/2
  when:
    enable_notify: true

line1:
  type: line
  when:
    enable_notify: true

But those fields do not appear in the Panel...

I noticed that the README has the fields as type: email but I had them as text fields when in form_options.yml and it was working.