Closed brandsis closed 3 months ago
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.
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.
Note that this test was done in my test site, which is internet-facing.
Sorry, something was missing try again with version 4.1.4.
Roman, I've installed v4.1.3 and still no joy...
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.)
It's fixed in 4.2.1. Please close this Issue if it's solved....
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?
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:
notify_email
, notify_from
, notify_reply
, confirm_to
, confirm_email
, confirm_reply
Name <mail@domain.com>
and placeholders.Please test it and let me know...
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.
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.
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?
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...
{{{name}} <{{email}}>
and {{email}}
but still submission emails do not arrive.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...
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
.form_confirm.yml
fields.panel.css
) and from the notification and confirmation emails.Many thanks.
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.
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...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?