volkswagenchick → credited yesct → .
me, https://www.drupal.org/u/javi-er → , https://www.drupal.org/u/rfay → helped mentor Brad. Thanks Brad! ping us later if we can help more!
I don't think a subdomain is necessary.
That is an improvement thanks!
I removed outdated info. I added instructions to get to the 2FA set up link.
We could still add more details for what happens after clicking on Update your username, email address, first and last name, or set up two-factor authentication.
greggles → credited yesct → .
mradcliffe → credited yesct → .
I'm ready. :)
Is this a release blocker? If so, maybe this should be Critical?
I think the next steps here are updating the branch (to fix the merge error, and be up to date with merge target) and then to fix the tests.
This seems like a release blocker to me.
This doesn't seem like a release blocker to me. (Just noting.) Priority normal seems fine to me also.
mradcliffe → credited yesct → .
attended. :) -c
Question: if sites followed https://architecture.lullabot.com/adr/20230929-drupal-build-steps/
where the example build steps begin with
vendor/bin/drush cache:rebuild --yes
vendor/bin/drush updatedb --yes
would that have prevented sites from being impacted by this issue?
I attended the slack meeting and registered. :)
The maintainer might have an opinion?
But if they are user facing I think those fixes could be included in the scope.
1 . https://www.drupal.org/sa-contrib-2025-001 → - CWE-1390: Weak Authentication and CAPEC-114: Authentication Abuse.
why not CAPEC-112: Brute Force ? Just curious.
2 . N/A
3 . :check: seems straight forward.
4 . https://www.drupal.org/sa-contrib-2025-004 → - CWE-862: Missing Authorization and CAPEC-87: Forceful Browsing. ChildOf Meta Attack Pattern 115 Authentication Bypass :check: seems fine to me.
[Didn't check the others. I might, but don't wait on me.]
@larowlan Thanks for making the change record drafts!
Opps. This isn't a child issue, just related, as a follow-up.
opps. this wasn't supposed to be a child issue. It was supposed to be a followup. So I moved the issue number from parent to related.
Also. I think this is a duplicate of ✨ Support adding additional routes for view modes other than 'full' Active
@catch I stubbed follow-up issues for what you mentioned in comment #13.
✨
Expand support for disabling a route to all entities
Active
✨
Replace media's standalone_url: false setting with support for disabling a route
Active
Those issues need more specific details, which I don't know, but at least the issues exist. Anyone who knows more, please edit those issues.
adding parent issue.
yesct → created an issue. See original summary → .
quietone → credited yesct → .
griffynh → credited yesct → .
I fixed some typos in the issue summary.
I added keywords like settings and link.
I also expanded the scope, by suggesting we link to the module config page.
Do folks think linking should be a separate issue?? Maybe it's not dependent on module maintaining writing text. And so linking might get implemented faster?
mradcliffe → credited yesct → .
yesct → created an issue.
I (also) think it would be better to have minimum-stability 'stable' and individually set any projects to lower stability if necessary - this can then be removed as soon as they have stable releases.
Most new site builders don't know how to evaluate a particular beta for use.
Maybe the UI of project browser can try and educate users about the risks of using betas?? But that's still an _individual_ decision. I think the CMS _default_ minimum for all projects should be stable.
I also think project maintainers should make stables more often than they do. If they need to make BC changes to fix bugs, they can make a new major version.
greggles → credited yesct → .
adding a reminder / advice to use the SA in the revision log.
mradcliffe → credited yesct → .
drumm fixed this already. adding credit for https://www.openbugbounty.org/reports/4005224/
Hm. Good to know. We are trying to decide if we want to move from core to 1.x (which is a full release covered by the security policy, we also need to bring some patches with, but still fails some of our caching tests) or to 2.x (which we don't need the patches for, but might have more changes that need more QA). I'm unsure.
I see this is major, and https://www.drupal.org/project/issues/search/book?text=&assigned=&submit... → mentioned being a blocker (and moved to major)... so I'm double checking, is this a blocker also for a full release?
quietone → credited yesct → .
Re Nestle, I'd also like to see it removed from being highlighted on the front page. Nestle is against many of our values.
Exciting new update!
In addition to the color contrast issue on menu already mentioned, Menu hover style has a too low color contrast 🐛 Feedback on Modern Drupal.org Design Active , when I looked on my phone, the text was difficult to read also.
Though that didn't show on the Chrome lighthouse accessibility report. Hm.
The lighthouse report does show some other issues:
Wave also points out some items (some things folks already mentioned). https://wave.webaim.org/
joseph.olstad → credited yesct → .
We are about to run patch 5 from #20.
If you don't want to make this the default, can we add a drupal config to wrap the toolbar to multiple lines?
Thanks for the release!
From the bot's description:
> If this issue is left open (status of Active, Needs review, Needs work or Reviewed and tested by the community) and the "ProjectUpdateBotD10" tag is left on this issue, new patches will be posted periodically if new deprecation fixes are needed.
I think D10 is not likely to get more deprecation fixes at this point. :shrug:
But maybe something to watch for ... for like D11. Maintainers might end up merging in MRs multiple times, and keeping the bot update issue open.
Closed duplicate ✨ add Tugboat config.yml Closed: duplicate from @q0rban .
Seems like the next step here is to get a passing MR.
ps. I was familiar with this issue, from a little work I did on 💬 Umami demo content makes http reponse headers without encoding invalid characters Active
I'll copy some of the issue description to previous existing issue: https://www.drupal.org/project/drupal/issues/3280730 → . Closing this as duplicate. :)
YesCT → created an issue.
Adding template intro.
Saying thanks.
Adding default closing.
I got confused since I could see the compare but not open a PR. I needed to log in.
3 months ago, https://www.drupal.org/project/drupal/issues/2911977#comment-15309703 ✨ Add Media revision UI Fixed went into 10.2
Closer to deprecation??
Can this issue be closed? https://www.drupal.org/project/ctools → already says the current version (4.0.4) is D10 compatible.
Is there a way to have the bot re-run and see if there are still issues it can autofix??
Can this issue be closed? https://www.drupal.org/project/ctools → already says the current version (4.0.4) is D10 compatible.
I added workarounds and the upstream issue to this summary.
Like @mglaman in comment #30 https://www.drupal.org/project/drupal/issues/3405976#comment-15357388 🐛 Transaction autocommit during shutdown relies on unreliable object destruction order Active
we were able to fix the sudden failing of our build step in behat, unit, and functional phpunit tests by updating the image CI was using in our webhead-ci/Dockerfile with this change:
- && pecl install xdebug \
+ && pecl install xdebug-3.2.2 \
Thank you folks for sharing what symptoms you were seeing and your workarounds!!
---
We are running D10. We did try a patch and it helped get our unit tests to pass, but we were still getting different errors with behat and functtional phpunit tests with the patch. Pinning xdebug got all our tests passing.
I think the lenient composer endpoint can help avoid moving the module to custom folder.
https://www.drupal.org/docs/develop/using-composer/using-drupals-lenient... →
Is this "done" since https://www.drupal.org/project/menu_breadcrumb/releases/2.0.0-alpha0 → was released?
This is listed as a blocker for a full release with D10 compatibility.
Is the next step here to help get the MR passing tests?
Is this still an issue with https://www.drupal.org/project/rename_admin_paths/releases/8.x-2.2-beta1 → ?
At Lullabot, we wrote up an Architecture Decision Record (ADR) to deal with a similar situation.
https://architecture.lullabot.com/adr/20210924-drupal-build-steps/
Depends on developers using hook_post_update_NAME() → .
Does that help?