Incorrect information on "Contact forms" page

Created on 11 March 2023, over 1 year ago
Updated 19 February 2024, 4 months ago

Problem/Motivation

When overriding building of contact emails, the "recipients" field is hidden in favor of using Email Policy. However the hidden field is still displayed on the "Contact forms" page (/admin/structure/contact). The same would be true anywhere else that calls ContactForm::getRecipients().

Proposed resolution

2 options:

  • Override ContactFormListBuilder with a derived class that changes buildRow()
  • Override ContactForm with a derived class that changes getRecipients()

Remaining tasks

User interface changes

API changes

Data model changes

πŸ› Bug report
Status

Active

Version

1.0

Component

Code

Created by

πŸ‡¬πŸ‡§United Kingdom AdamPS

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • 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.

    1. If sites would like to keep everything the same as before then they shouldn't override.
    2. 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

Production build 0.69.0 2024