Problem/Motivation
Email FAPI element was added without support of multiple attribute. See https://www.drupal.org/project/drupal/issues/1174620#comment-4564144.
Currently even if the attribute set directly through #attributes
property Drupal does not accept comma-separated emails.
Steps to reproduce
- Add to any form an email element
$form['email'] = [
'#type' => 'email',
'#title' => $this>t('Email'),
];
'#attributes' => ['multiple' => '']
The email address <em>foo@example.com,bar@example.com</em> is not valid. Use the format user@example.com.
Proposed resolution
Support "multiple" attribute same way as for select lists.
$form['emails'] = [
'#type' => 'email',
'#title' => $this->t('Emails'),
'#multiple' => TRUE,
'#description' => $this->t('Comma-separated email addresses.')
];
- Allow to add multiple attribute via #multiple element property
- Update element validation to support #multiple property
Later, it will be possible to add this option to Email fields as well, but first, an element itself needs to comply with the HTML documentation.
Remaining tasks
Review
Commit
User interface changes
NA
API changes
The API of the Email Render element must be updated.
https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Render%21...
Data model changes
NA
Release notes snippet
Provide multiple attribute support for Email render element.
Comment | File | Size | Author |
---|---|---|---|
#35 | 3296190-nr-bot.txt | 90 bytes | needs-review-queue-bot |
#33 | 3296190-nr-bot.txt | 90 bytes | needs-review-queue-bot |
#27 | 3296190-nr-bot.txt | 90 bytes | needs-review-queue-bot |
Issue fork drupal-3296190
Show commands
Start 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:
Comments
Comment #3
Chi CreditAttribution: Chi commentedComment #8
HitchShockComment #10
HitchShockComment #11
smustgrave CreditAttribution: smustgrave at Mobomo commentedIssue summary seems incomplete, I got it started but if TBD sections can be reviewed and if they don't apply can put NA. But seems like a UI or API change that should be noted.
May need a change record but not 100% there.
Comment #12
HitchShockComment #13
smustgrave CreditAttribution: smustgrave at Mobomo commentedRebased to run test-only feature
Which is good.
Updated the change record some. Think it would be good to get in and then work on conversions in core but lets see.
Rest looks good
Comment #14
rowrowrowrow CreditAttribution: rowrowrowrow as a volunteer commentedThis is a version of the patch provided in #10 but for core version 10.1.5
Comment #15
xjmThe issue summary includes both patches and multiple merge requests. There should be only one canonical patch or merge request listed.
Please close any non-canonical merge request(s) and hide non-canonical patches. If you don't have permission to close merge requests, please hide any non-canonical patches and then document which merge request(s) should be closed in an issue comment and under a separate header in the issue summary. This will allow a committer to close them for you. Thanks!
Comment #16
xjmComment #17
andypostComment #18
HitchShockComment #19
HitchShockSeems like we already have hidden non-canonical patches.
Updated PR from the 11.x branch and returned the previous status.
Comment #20
longwaveAdded some questions/feedback to the MR.
Comment #21
HitchShockFixed two issues from the comments.
Comment #22
smustgrave CreditAttribution: smustgrave at Mobomo commentedSeems additional feedback has been addressed.
Comment #23
longwaveSorry, one more little bit of feedback: we should add docs so users know this is possible.
Comment #24
HitchShockUpdated the element doc and info.
Since the last changes don't have any effect on the element behavior I switch back the RTBC status.
P.S. Ignore the spell-checking error. "Argument list too long" is a Drupal core issue - #3401988: Spell-checking job fails with "Argument list too long" when too many files are changed.
Seems like the last merging of the 11.x caused the error.
Other tests are still passing successfully.
Comment #25
longwaveAdded a few more nits and questions to the MR.
Comment #26
HitchShock@longwave I went over your last comments.
Comment #27
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #28
longwaveResponded to the MR comments.
Comment #29
HitchShockHandled the last issues.
One of them was a really important one, @longwave nice catch!
Comment #30
smustgrave CreditAttribution: smustgrave at Mobomo commentedAppears feedback has been addressed.
Comment #31
quietone CreditAttribution: quietone at PreviousNext commentedI'm triaging RTBC issues. I read the IS and the comments. I didn't find any unanswered questions.
I read the MR and left some suggestions. I also think input is needed from Usability on the new strings. Adding tag for a usability review.
I read the MR and I do suggest a change. When I read "Provide #multiple property for email render element with correct validation." I ask myself why we would provide an element with incorrect validation. I think it could be reworded. I know it is minor.
Setting to NW.
Comment #32
HitchShock@quietone I went through your proposals in MR.
Some of them I've fixed and for some of them I wrote an answer. You can recheck them.
Comment #33
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #34
HitchShockComment #35
needs-review-queue-bot CreditAttribution: needs-review-queue-bot as a volunteer commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #36
HitchShockComment #37
benjifisherUsability review
We discussed this issue at #3440370: Drupal Usability Meeting 2024-04-19. That issue will have a link to a recording of the meeting.
For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @rkoller, @shaal, @simohell, @skaught, and @worldlinemine.
If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.
There was some discussion about whether we should handle multiple email addresses in separate textfields instead of allowing a comma-separated list. We decided that the current approach is the right choice. It is consistent with the email specification, and the Field API (not the Form API) is the right place to handle multiple textfields.
We tested various invalid entries, and we used the Disable HTML5 validation module so that we could see the error messages provided by this issue. The current approach works well, but we would like to make two changes:
An error message should do two things: describe the error state and give information on how to fix it. The current message, "All email addresses must be non-empty.", tries to do both at once. We think it would be clearer to use the same format as the other error messages:
If possible, use the un-trimmed value in the error message so that there is a distinction between
,,
and, ,
.Other argument in favor of (1):
The second point is purely grammatical: when combining independent clauses with "and", there should be a comma after the first one.
Comment #38
HitchShockHi @benjifisher
1. Fixed a small grammatic issue
2. About the empty email error message:
I really liked this idea and implemented it.
But I don't like the idea of making an "empty" message like this
For me, this message is unclear/unreadable/not user-friendly. It is very difficult to correctly display an "empty" value. Using quotation marks for this purpose can only worsen the situation, as the user may start looking for something that is not there. A message like that really can confuse a user.
While the direct text that an empty email address value has been entered is clear and not ambiguous.