Problem/Motivation
In certain situations where validation fails, Core displays an error message:
* An illegal choice has been detected. Please contact the site administrator.
This message can be confusing to users in particular contexts, because of the use of the word 'illegal'. It implies the user has broken the law, which obviously they have not.
Steps to reproduce
Enable test modules by adding
$settings['extension_discovery_scan_tests'] = TRUE;
to settings.php
. Alternatively, copy core/modules/system/tests/modules/form_test
to modules/
.
- Install
form_test
. - Go to
/form-test/input-forgery
. - Check both boxes and submit the form to see the error.
Proposed resolution
Change the message to read something more descriptive:
The submitted value FORGERY in Checkboxes element is not allowed.
-- See #44
Remaining tasks
- Get RTBC.
API changes
NA
Data model changes
NA
Release notes snippet
Comment | File | Size | Author |
---|---|---|---|
#59 | interdiff_57-59.txt | 1.36 KB | mrinalini9 |
#59 | 3265616-59.patch | 12.29 KB | mrinalini9 |
| |||
#57 | interdiff-51-57.txt | 2.05 KB | jungle |
#57 | 3265616-57.patch | 12.38 KB | jungle |
| |||
#51 | interdiff-51.txt | 552 bytes | xjm |
Issue fork drupal-3265616
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:
- 3265616-re-word-an-illegal changes, plain diff MR !1860
Comments
Comment #3
nicrodgersComment #4
rootworkTagging as novice task to review. This is a good issue to learn how to test that a Merge Request still applies and provide screenshots or other information about what effect the changes have.
Comment #7
smustgrave CreditAttribution: smustgrave at Mobomo commentedTagging for usability review, will slack them also
In the meantime can the MR please be updated for 10.1
Comment #8
kkalashnikov CreditAttribution: kkalashnikov as a volunteer and at Material for Drupal India Association commentedPatch for Drupal version 10.1.x
Comment #9
kkalashnikov CreditAttribution: kkalashnikov as a volunteer and at Material for Drupal India Association commentedComment #10
nicrodgersThanks @kklalashnikov for the re-roll.
I've applied the patch and searched the codebase for the original string. It is still in the following places and needs updating:
Comment #11
lucasscHi!
I removed the remaining ambiguous messages and I took the liberty of include a comma after the word "Please".
I attached an alternative patch with no commas as well.
Please, review.
Comment #12
nicrodgersThanks for updating those remaining strings, lucassc. However, I do not think the comma after "Please" is correct. It reads much better without it. Setting back to NW to revert the comma change.
Comment #14
Akram KhanAdded patch consider #12
Comment #15
nicrodgersThere are unrelated composer changes in the patch in #14
Comment #16
lucasscHi, nicrodgers! Thanks for review.
In #11 I already added an alternative patch without the commas (no_commas-3265616-11.patch) and its interdiff with patch #9 (interdiff_no_commas_9-11.txt).
Please review.
Comment #17
nicrodgersReviewing the file no_commas-3265616-11.patch from #11, it looks good apart from these two lines:
An extra full stop has appeared here.
Comment #18
lucasscops, damn ADHD haha
extra full stops removed.
Comment #19
lucassccould someone please provide before/after screenshots and steps to reproduce in the IS?
Comment #20
smustgrave CreditAttribution: smustgrave at Mobomo commentedUpdated issue summary
Searching repo for "illegal choice" and there are 2 in FormValidator
Think we should log "invalid" also if that's the message we show.
Comment #21
lucasscThanks, @smustgrave. I replaced the remaining 2 "illegal choice" recurrences.
Please review.
Comment #22
longwaveYes, big +1 to this - I've seen users be surprised by the "illegal" message before, and "invalid" is clearer to me.
Comment #23
smustgrave CreditAttribution: smustgrave at Mobomo commentedThanks for making those changes!
Comment #24
xjmThis was still tagged for usability review, which should have blocked RTBC. However, simply replacing "illegal" with "invalid" is a definite improvement.
I reviewed this with
git diff --color-words
.I also checked for outstanding uses of the word "illegal" with:
There are lots, and they should probably all be fixed to use a different word. However, only this one seems directly related to the current FAPI error:
That comment won't make any sense after this change, so we need to update it too as part of this issue.
For what it's worth, the "has been detected" part of the error message has always been confusing to me too. "Detected" how? It took me a very long time in 2006 or whatever to understand that this meant an invalid value was submitted as part of the form data. So I think the message should be changed to "An invalid value was submitted."
Then, there are two further problems with the message. One is the use of the word "Please" -- which we should never use in the UI according to our user interface text standards:
Finally, the bit about contacting the site administrator also could be misleading. I wouldn't necessarily know who the site administrator is or how to contact them, and it could be my fault as a technical end user for submitting a custom
POST
request that had the wrong data types -- or, in the most likely scenario when I'm the developer writing a form, I am the site administrator and it still makes no sense.So, I think the message should be "An invalid form value was submitted." No second sentence. But changing it to that extent would require UX review.
Marking NW at least for updating the Menu UI module inline comment, for the followups to alter other uses of "illegal" in the UI (and possibly deprecating API methods with the word as well), and finally for possibly changing it to "An invalid form value was submitted" and getting UX review of that.
Thanks everyone!
Comment #25
Rishabh Vishwakarma CreditAttribution: Rishabh Vishwakarma at OpenSense Labs for DrupalFit commentedAddressed the requirements as per #24 (Updated the Menu UI module inline comment)
Comment #26
benjifisherI am clarifying the "Steps to reproduce" in the issue summary.
The Novice tag was added in #4 for manual testing and screenshots. The Novice tasks have been done, so I am removing the tag.
Comment #27
xjmTLDR of #24:
Change:
To:
Updating the remaining tasks.
Comment #28
jidrone CreditAttribution: jidrone at Agileana commentedAfter the UX review, we concluded the following:
The errors should be descriptive and actionable, but these errors don't fulfill that guidelines:
The first part "An illegal choice has been detected" is not enough descriptive and the second "Please contact the site administrator" is not actionable.
The "invalid" word could be also associated to people with disabilities, so we should find better options.
We found these errors only apply to some form element types like: checkboxes, tableselect and select. In addition, the code that is triggering those errors is a $form_state->setError() so it is possible to get more context about the issue to show a more descriptive message and it is already flagging the form element that failed.
Updated issue description with suggested error messages on remaining task
Comment #29
xjmI just would like to point out that "invalid" when used as an adjective has a different pronunciation from "invalid" when used as a noun. The adjective is pronounced in-VAL-id, whereas the adjective is pronounced IN-va-lid (as a term used to refer to someone who is too sick to move). So they are different words, pronounced differently, despite the spelling. I certainly think we're not going to be able to eliminate the word "invalid" (as an adjective) from Drupal, so we should not attempt that as followup scope.
That said, I was considering asking for more debugging and left it aside until there had been UX review, so I am glad to see the UX review went in the same direction and I support the improved error messages in the IS. Let's get the patch updated for that behavior. Thanks!
Comment #30
jidrone CreditAttribution: jidrone at Agileana commentedCreated a patch with the new approach, in this case an interdiff makes no sense because the code is going into another direction.
Comment #32
xjmThe followup issue has been filed at #3340978: [meta] Remove other uses of “illegal” from core -- thanks @schlaukopf!
Test fails look related:
Comment #33
jungleFYI, form elements such as actions, form_id, form_build_id do not have #title
Comment #34
smustgrave CreditAttribution: smustgrave at Mobomo commentedIn the issue summary the proposed solution
is included
But one of the remaining tasks is to remove that. So which is it?
Comment #35
jidrone CreditAttribution: jidrone as a volunteer and at Agileana commentedComment #36
jungleShould the HTML be
The submitted value <em class="placeholder">FORGERY</em> in <em class="placeholder">Checkboxes</em> element is not allowed.
?With e.g.
Comment #37
smustgrave CreditAttribution: smustgrave at Mobomo commentedNot sure I see the difference?
Comment #38
jidrone CreditAttribution: jidrone as a volunteer and at Agileana commentedHi smustgrave,
Do you mean the issue description is not clear or it looks like was not updated?
Comment #39
smustgrave CreditAttribution: smustgrave at Mobomo commented#36 the suggestion looks the same as what was implemented or am I wrong?
Comment #40
jungleHi, @smustgrave. They do not look the same.
The rendered HTML in the patch:
The submitted value <strong><em class="placeholder">FORGERY</em></strong> in <em class="placeholder">Checkboxes</em> element is not allowed
The suggestion in IS is the above
It might be renderred into
The submitted value "<em class="placeholder">FORGERY</em>" in <strong><em class="placeholder">Checkboxes</em></strong> element is not allowed
My suggestion:
The submitted value <em class="placeholder">FORGERY</em> in <em class="placeholder">Checkboxes</em> element is not allowed
As
%variable
is in use, do we really need the extra strong markup?Comment #41
smustgrave CreditAttribution: smustgrave at Mobomo commentedI would say no, just my opinion though. But the issue summary proposal and patch should line up so moving back to NW for that.
Comment #42
jungleUpdate the patch to follow the suggestion in IS
Comment #43
jungleComment #44
jidrone CreditAttribution: jidrone as a volunteer and at Agileana commentedAfter viewing the code I think both of you are right, the text in the summary was not the same than the patch and I think the suggestion from @jungle is good, because is not common in Drupal to make them bold or use quotes in those messages.
I suggest to change the description to remove the quotes and the strong tag as follows.
Comment #45
jungle@jidrone did the UX review before, so I think his opinion is good. IS Updated. Attaching the new patch per #44
Comment #46
nicrodgersAs the original creator of this issue, I like the way this has improved since the UX review, however I do question the wording of the new message - it doesn't read very well at the moment. Adding the in makes the whole thing much better:
The submitted value FORGERY in the Checkboxes element is not allowed.
Obviously 'the' shouldn't be in bold, I have highlighted it to make it clearer what I am suggesting should be added.
Comment #47
jungle+1 to #46, thanks!
#46 addressed
Comment #48
jungleMeanwhile, changed 'type' to 'Type'. the first letter of the element title should be in uppercase.
Also here
Comment #49
smustgrave CreditAttribution: smustgrave at Mobomo commentedThanks @jungle for sticking with this one!
Comment #50
xjmIn general, we should avoid using
t()
or any of its variants in tests unless those tests are specifically testing translation or multilingual functionality. And, indeed, line 462 of this test already has an example of how to test the expected placeholder markup (Basically,<em class="placeholder">value</em>
).I already made this change locally just to make sure it would work, so the attached updates the patch to fix it.
Comment #51
xjmForgot to also remove the
use
statement.Comment #52
catchNice to see this one. One of the most unhelpful error messages in all of Drupal, and surprised this issue is only a year old.
Tagging as a 10.1 string change.
Committed/pushed to 10.1.x, thanks!
Comment #54
catchComment #56
catch@longwave pointed out in slack that we're now calling $this->t on a variable, which won't allow potx to pick up the string. Need to remove the variable assignment and duplicate the string I think.
Comment #57
jungleComment #58
longwaveHere it seems simpler to say
Similarly here
Comment #59
mrinalini9 CreditAttribution: mrinalini9 at Material for Drupal India Association commentedUpdated patch #57 by addressing #58, please review it.
Thanks!
Comment #60
jidrone CreditAttribution: jidrone at Agileana commentedMaybe we can also simplify this part to be something like:
What do think @longwave?
Comment #61
jungleIf using
$message_arguments['%name'] = $name;
I prefer
Or it's over-optimized.
#57 was reviewed by @longwave, the tiny change in #59 looks good. #59 is a RTBC to me.
Comment #62
jidrone CreditAttribution: jidrone at Agileana commentedYes, you are right, it looks to go.
Comment #64
longwaveAgree with @jungle for #60/61 - I prefer
$array = []
or$array = ['key' => 'value']
to make it clear you are initialising the array.Committed to 10.1.x, thanks!
Comment #65
benjifisherFor the record: the usability meeting mentioned in Comment #28 was #3338999: Drupal Usability Meeting 2023-02-10. The attendees were @AaronMcHale, @benjifisher, @jidrone, @rkoller, @schlaukopf, and @simohell. That issue will have a link to the recording.
At the meeting, I made the same point about the two different words spelled "invalid" that @xjm made in #29. I do not have a link, but @rkoller had a reference that suggested avoiding the word. The distinction is clear to those of us who know English well, but perhaps it is more likely to cause confusion for readers who primarily speak a different language.