Closed (fixed)
Project:
Drupal core
Version:
10.1.x-dev
Component:
base system
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
16 Sep 2019 at 23:45 UTC
Updated:
26 Jul 2023 at 15:38 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #5
richardbporter commentedComment #7
quietone commentedMake it easier to read the list of files in the IS.
Comment #8
mallezieThe one in core/lib/Drupal/Core/Render/HtmlResponseAttachmentsProcessor.php is already done.
The ones in the Renderer class are being tackled in https://www.drupal.org/project/drupal/issues/3192839
I rebased the branch, and added changes for the other 3 to see if we do them in one go.
Comment #9
mallezieComment #11
mallezieComment #15
smustgrave commentedThis issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.
At this time we will need a D10 MR of this issue. Would recommend starting a new one as I've experienced issues with updating an MR from 9.x to 10.
Comment #18
spokjeThanks @smustgrave and The Kind Folks @#needs-review-queue-initiative
Rerolled in a new MR against 10.1.x.
Comment #20
mallezieThanks! Totally forgot about this one.
Just checked the new MR, and seems the same to the original. (Which i did, so probably i'm not the one allowed to put it in RTBC).
Closed the old merge request.
Comment #21
smustgrave commentedThanks for the turnaround
ON Drupal 10.1.x
Did a quick search for https://www.drupal.org/node/2408013 and found 4 instances
Applied the MR and they were addressed.
Comment #22
xjmTagging for framework manager review since this caused its share of debate back in the day.
Comment #23
spokjeAm I just unlucky, or is every issue I worked on lately needing policy updates/[Important-People] review?
Comment #24
xjm@Spokje I think that means you are working on important things. :)
Comment #26
catchfwiw these all look like good changes to me - they're notifying of developer errors, which is the right place for an assert.
The only one that had me scratching my head was saving an entity without validation, since the exception potentially prevents bad data being saved, but that also looks like a situation you can only get into via developer error so the assertion should still catch it before it actually happens on production anywhere.
Comment #27
spokjeTo
boldly gostupidly stumble where no person has gone before!Comment #28
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #29
spokje_Very_ unsure if this is allowed, but since this was a reroll and not done by myself, I'm going t put this back to RTBC per #21
Comment #30
catchAgreed we should do this, there are probably more examples but we can gradually open issues for those when we spot them. Untagging for framework manager review.
Also to confirm you're definitely allowed to re-RTBC something that's only been re-rolled since it was last RTBC.
Committed e434d61 and pushed to 10.1.x. Thanks!
Comment #32
catchComment #33
spokjeThanks @catch, there's probably a very clear policy out there, but my search-fu failed me on this one.
Very handy to know for the future.
Comment #36
bnjmnmAdjusting issue credit as credit is not provided for button-click rebases without additional contribution.
Comment #37
andypostThis fix caused issue with PHP 8.3 compatibility #3375693-14: Fix deprecated assert_options() function usage for PHP 8.3
Let's polish assertions there