- Issue created by @adamps
- First commit to issue fork.
- π¦πΊAustralia mingsong π¦πΊ
For a better compatibility with other modules, including core modules, I would suggest keeping the recipients field of a contact form entity identical to the mailer policy's setting.
The reason is that, other module might still rely on that field of a contact form entity. Hiding recipient from "Contact forms" page would cause confusions to other module's users.
- π¬π§United Kingdom adamps
That's an interesting idea and I see your point.
However it would be a big change to the strategy of this module. There are quite a few email builders that overrides. Currently they have an import function, and after that they ignore the config of the original module, which is hidden in the UI. If this module is uninstalled, the prior original config comes back untouched.
Adding triggers from when a policy is saved to alter original module config would be a big change. The structure of the configuration of this module isn't always identical to the original - for example this module accepts a policy for all contact forms, with an override per form. When the "all" policy is changed we would need to alter all module config except the ones specifically overridden. And the all the override actions would have complex effects.
It would add a lot of code and effort focussed "backwards". It doesn't feel right to me.
- π¦πΊAustralia mingsong π¦πΊ
Absolutely agreed. It is very complicated.
If we introduce a new token, for example [symfony_mailer:address:to], and then use this token as the default value of a contact form, instead of the hardcode one [site:mail] in the following line.
https://git.drupalcode.org/project/symfony_mailer/-/blob/1.x/src/Plugin/...
This token will be replaced with the correct recipient address via the following line.
https://git.drupalcode.org/project/symfony_mailer/-/blob/1.x/src/MailerH...
If this approach works, it would be way simper and also leave the origin config untouched.
- π¬π§United Kingdom adamps
'#default_value' is just for newly created contact form entities to allow the form to validate.
There isn't any value to assign for [symfony_mailer:address:to] - the site admin hasn't yet created the mailer policy that would actually contain the to address. Even if we had a value it wouldn't work because the to address could later change.
- π¦πΊAustralia mingsong π¦πΊ
True.
Regarding the '#default_value', it also affect when the Contact form is edited and saved. Because the form altered by
https://git.drupalcode.org/project/symfony_mailer/-/blob/1.x/src/MailerH...
Agree, it is not idea and won't work for all scenarios.
- π¬π§United Kingdom adamps
I see it like this. This issue is about when emails for the contact module are overridden, which is optional.
- If sites would like to keep everything the same as before then they shouldn't override.
- If they override, then some parts of the contact_form entity will no longer be used as they are replaced by Mailer Policy. This is intentional and is one of the goals of this module. Maybe even one day Core will take this change.
AFAICS the contact_form entity isn't used outside of contact module, except in test code.
I still feel that the solution in the IS is correct. It's not complicatedπ. Anyway this issue maybe isn't the top priority.
- π¦πΊAustralia mingsong π¦πΊ
Good point.
Generally speaking, I would suggest that when we alter a form from other modules, such as overriding the '#default_value', we can also modifying the description of that field if it hasn't been hidden. For instance,
$origin_description = $form[$key]['#description'] ?? ''; $form[$key]['#default_value'] = $this->token->replace($default); $form[$key]['#description'] = $origin_description . $this->t( ' (This value is managed by Synfony mailer policies below)');
- π¬π§United Kingdom adamps
Yes I agree - however we only alter the default when the field is hidden