I am seeing the same Error executable_php, access was denied to the file. error message, both when I run security review in the browser or via drush (and I do have a drush file with the site URI specified); the difference is that I actually see the security review results in the browser (in addition to the error message), whereas via drush there is no review output.
Just wondering if there is a plan for how to target the element to style it? I am needing to style the new button, and I'm not seeing anything very targetable; I also tried a theme preprocess but it's pretty messy because of the template preprocessing that's done on the form that puts it into a table and the buttons are in individual rows in cells that do not have an identifier either. Is a separate issue needed to add some targetable CSS to the markup (I searched but wasn't able to find one)?
I agree, a change record or at least having it listed in whichever 10.2.x release it actually landed in would have been super helpful. This change was unexpected, and I do (and did) read the release pages to look for new features and other items of interest. After finding the problem in my app (as someone else suggested, there was a custom solution in place), I literally searched every 10.2.x release page (all 10 of them, at time of writing) for "remove", "multi", and (once I found it) this issue number "1038316" - and there were no references to this change that I could see. I only found this issue by searching core code for part of the resulting HTML, googling based on what I found, and following a link in a contrib issue (for a module I'm not using) that was in the search results. Can/should this issue be retroactively added to whichever 10.2.x release page it belongs to?
I'm not sure why there aren't any messages above about it, but this was committed and I'm seeing the permission in the 3.0.0 release (it looks like it was released in 8.x-2.7). I think this can be marked as fixed.
https://git.drupalcode.org/project/redirect_after_login/-/commit/debd493...
I can't say I looked to understand the implication of the tag attribute name not being set, but #3 works for me to get rid of the warnings.
It looks like #62 has a few more changes than #61, both are applying cleanly to 2.0.0-rc4 for me though I chose #62 since it seems more up-to-date with the merge request at quick glance. Thanks!