At /admin/config/people/accounts, it is not documented anywhere in the UI that clearing the body field of any account email template will disable that email from being sent entirely. This is a useful feature, but it is invisible to administrators who may either accidentally suppress emails or never discover the capability exists.
/admin/config/people/accounts.Add a #description to the $form['email'] vertical tabs container in AccountSettingsForm::buildForm() to inform administrators of this behavior:
$form['email'] = [ '#type' => 'vertical_tabs', '#title' => $this->t('Emails'), '#description' => $this->t('Removing all text from the body of an email will disable that email from being sent.'), ];
A single line of descriptive text is added beneath the Emails vertical tabs heading on /admin/config/people/accounts. No other UI elements are added, removed, or changed.
None.
None.
None.
The account email settings page (/admin/config/people/accounts) now displays a note informing administrators that removing all text from an email body field will disable that email from being sent.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | Password recovery.png | 323.13 KB | chris matthews |
| #12 | Account canceled.png | 249.66 KB | chris matthews |
| #12 | Account cancellation confirmation.png | 241.72 KB | chris matthews |
| #12 | Account blocked.png | 253.34 KB | chris matthews |
| #12 | Account activation.png | 387.07 KB | chris matthews |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
chris matthews commentedComment #4
nicxvan commentedI think a screenshot would help and I bet the ux team will have some feedback.
I think it's a great idea!
Comment #5
chris matthews commentedComment #6
mtiftCode looks good to me. The message text makes sense.
Comment #7
rkolleri think the MR needs to be against the main branch (currently equal to 12.x) and the changes get then be cherry picked against previous versions.
Comment #8
nicxvan commentedYes and we need a screenshot for interface changes
Comment #9
nicxvan commentedComment #10
rkollerand i can put the issue on the short list for the meetings on fridays. not 100% sure we will get to it already this friday cuz the issue we've discussed the last two weeks is not completely finished but this issue is rather brief so odds are high that we will be able to discuss it either already this friday or otherwise friday next week.
Comment #11
rkollerUsability review
We discussed this issue for the first time at #3581812: Drupal Usability Meeting 2026-04-03. The link to the recording: https://youtu.be/LyBy7cDksSc?t=1400&si=Ixk35BW5CIYs_v1P . The attendees at the usability meeting were @nicxvan, @rkoller, @simohell, and @worldlinemine.
Our discussion was based on the latest state of MR15168. In general adding the information contained in the description is a good thing, we've only noticed a few noteworthy details:
Visually there is a disconnect between the description and the body field it refers to. Instead of being left aligned to the body field within the content area of the active vertical tab the description is left aligned to the vertical tabs itself - through that shift to the left underneath the block of vertical tabs it is not necessarily clear to what the description refers / belongs to or if the description is getting noticed at all. Plus, depending on the availability and height of the body field within the content area of the active vertical tab, there could also be a rather large gap between the last vertical tab and the description:
Or the description is shown in close proximity even when there is no enabled visible body field available for the active vertical tab.
So in case the user notices the description underneath and considers it relevant in the context of the vertical tabs and or body field it is a cognitively/visually demanding task switching the focus back and forth from the body field within the content area of the active vertical tab to the description underneath.
Programmatically, there is also no association of the description to the body field which poses a problem for screenreader users. No one explores the entire page thoroughly, so with the description after the block of vertical tabs, the description could go unnoticed without the programmatic association most likely.
Aside those points there is also one question in regard to multilingual sites. For a site with fro example two languages, what happens if there is a translation in one language but the site is missing a translation for the other language (no translation was added/created). Will the email still be sent but just in the other existing language or will no email be sent if the translation is missing? The group considered that question a relevant detail to decide which measure to recommend - some options that came to mind would be either a warning message or should the description be expanded to inform the user about the constraints in the context of multilingual sites?
There was a clear consensus in the group to move the description into the content area of the vertical tab and display it right underneath the body field, but only when the body field is enabled and visible. The description should also be programmatically associated with the body field by the aria-describedby attribute.
If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.
Comment #12
chris matthews commentedComment #13
smustgrave commentedBased on the screenshots seems straight forward enoguh.