Problem/Motivation
The documentation on the Drupal\Core\Render\Element\Select element doesn't warns that using #empty_value could lead to overwriting a value in #options.
See #1936636: Fix the documentation for #empty_value for more details.
Steps to reproduce
N/A
Proposed resolution
Add a warning in the comments about this situation.
Remaining tasks
User interface changes
API changes
None.
Data model changes
None.
Release notes snippet
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #33 | 3361695-nr-bot.txt | 1.22 KB | needs-review-queue-bot |
Issue fork drupal-3361695
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:
- 10.1.x
compare
- 3361695-fix-the-documentation
changes, plain diff MR !4023
Comments
Comment #3
tunicPlease ignore the 10.1.x, I pushed there by mistake. The same fix is in the 3361695-fix-the-documentation branch.
Comment #4
tunicComment #5
tunicAdditionally, should the Form API or render system detect this problem and raise a waring? Some kind of render/form API array structure validation
Comment #6
borisson_Should be
overriddeninstead.Comment #7
tunicThanks for the review, typo fixed and branch rebased so it's mergeable again.
Comment #8
smustgrave commentedSeems there are out of scope indent changes happening.
Comment #9
tunicOuch! I'm trying a new IDE and I've discovered it is not configured for Drupal coding standards. Sorry for the noise.
Comment #10
smustgrave commentedText appears to match the issue described in the issue summary and no issues in the tests.
LGTM.
Comment #12
lauriiiI think adding an assert (as proposed in #5) for this condition would be a great DX improvement since this would be a real DrupalWTF to deal with.
Comment #13
tunic#12, I think it is interesting to automatically check that the issue is not happening (aka #options value overriden by #empty_value if #empty_option is present in #options), but I'm not sure how to do it.
Using assert will only work when assertions are enabled. This can be the case for automatic testing but it is not on production environments. Given the dynamic nature of forms, it is possible that the case where #options is overriden only happens on certain situations. This would not be detected by testing. And having a fatal error can be too drastic, I guess.
I would check the condition and raise a warning. This way Drupal is able to continue running, even though there's probably a problem. Any devs checking the logs or debugging a weird behavior on a form will see error.
But this discussion can ne longer, and the initial issue is about documentation. I think we should focus this issue on the documentation and open a new one for the warning where we can discuss how to do it.
Comment #14
smustgrave commentedMaybe open a follow up for #12?
Comment #15
tunicFollow up added: #3375072: Add an exception/warning/assert/other when a #options value is overriden because #empty_options.
Comment #16
quietone commentedI am doing triage on the core RTBC queue.
The issue summary is short and clear. And looking at the MR it is fixing the problem stated there. I read the comments and see that a suggestion was moved to another issue. That looks like a good choice here.
On reading the MR I though the sentence could be improved and made a suggestion on the MR. Setting back to NR for that.
Then, I realized I should have read the code. It appears this is working as designed, therefor I am not convinced that the doc change should include 'Warning'. Right now I am thinking the sentence should begin with 'Note that' instead of 'Warning:'
Comment #17
smustgrave commentedFor the update mentioned in 16
Comment #18
tunic#16, it may work as designed, but the behavior doesn't seem right, hence the warning. See https://www.drupal.org/project/documentation/issues/1936636#comment-1505... for an example.
However, I think 'Note' would work. If it is preferred I won't complain, but I would like to have a decision soon so we can fix the MR with the agreed value.
Comment #19
smustgrave commentedSearching core found examples of using both Warning: and Note: so seems like a coin toss. Going to mark it though as the sentence has been updated.
Comment #20
lauriii+1 that "note that" would read better here. It's definitely more in line with our pre-existing comments.
Comment #21
tunicComment #22
tunicComment #23
tunicChanged "Warning: " by "Note that" (with an intermediate commit where I wrongly used "Note: ")
Comment #24
smustgrave commentedSeemed to cause CC failure.
Comment #25
tunicPHPStan step has been executed successfully.
Comment #26
smustgrave commentedThanks for the quick fix. Going to go ahead and mark it as I doubt this will cause test failures.
Comment #27
quietone commentedI'm triaging RTBC issues. I read the IS and the comments since my last comment. I didn't find any unanswered questions or other work to do.
Leaving at RTBC.
Comment #28
lauriiiI've probably come to lurk on this issue more than 3 times by now and I've always gotten stuck at trying to remember what does it mean that the #empty_option overrides a value from the #options. I remember this made sense after stepping through this with a debugger but maybe we need to improve the docs so that that wouldn't be required? 😅
Comment #29
tunic@laurii I guess you mean more details in the sentence are required on the proposed sentence.
This is the current sentence:
Would it be clear with this?
Also, I guess the status should be "Needs work" instead of "Needs review", right?
Comment #30
smustgrave commentedDoes sound like NW is the correct status.
Comment #31
tunicI stumbled upon this issue again. I've tried to better explain the situation to address #28:
If this is not enough, please point out what is missing or what would be a better approach to this. The issue is complex and it is hard to understand without a little bit of context or checking all the comments in the class' header.
Comment #32
smustgrave commentedTook another look and believe this one is good.
Comment #33
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. 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
tunicComment #37
nod_Committed e2774eb and pushed to 11.x. Thanks!