Switch our base to Drupal 11

Replace login_emailusername with mail_login

How was the mail_login module selected to be the chosen one? I am just curious, because there are similar modules, some with a higher usage (like the email_registration → ).

How was the mail_login module selected to be the chosen one? I am just curious, because there are similar modules, some with a higher usage (like the email_registration).

Yes is there documentation for any of this? And are these from the prototype or newly added/confirmed by work tracks? I had a similar reaction to quick node clone.

Quick Node Clone came from the prototype and was added by personal fiat.

The ability to log in with your email address was based more on actual data (the Starshot survey that Technocrat ran had this pop up many times, and Pam was strongly in support of it, as was I). The choice of module to specifically implement that was more or less arbitrary.

https://www.drupal.org/project/email_registration → is also Drupal-11 ready and has six maintainers including at least two security team members.

I am personally agnostic about which one we choose. The decision probably lies with @pameeela.

Either way, I'd suggest we open another issue; in the meantime, to unblock D11 support we should probably remove login_emailusername from the base recipe in this issue.

I think this brings us back to something like was mentioned here: https://drupal.slack.com/archives/C072BF486FN/p1724411659489389 - make a list of modules used by Drupal CMS/Starshot.

We can mention all modules - some with a note that are still from the prototype and then others officially added by specific tracks.

No need to update it daily I think, but this list will be probably very helpful - for maintainers and for the community, so that the focus can be oriented to these modules.

I can create an issue for this, if it is not already created.

I'll create an issue for the email login module decision because I don't want to hijack the thread.

FYI #3474596: Support logging in with email address →

OK, so -- what I'm aiming for, right now, is to get the MR branch to green. I'm accomplishing this by patching the holdout dependencies, and using @mglaman's drupal-composer-lenient plugin to get around the version constraints.

We should NOT merge it in this state -- we should only merge this when the dependencies are either removed, or have committed compatibility patches. We definitely should be shipping the lenient plugin.

But this at least is a good way to track and confirm our Drupal 11 readiness.

So, I have the project building on Drupal 11 on CI -- that's huge!

Here are the current blockers to merging this:

• Token Or needs to merge 📌 Automated Drupal 11 compatibility fixes for token_or Needs review , or the dependency has to be removed (which would break the SEO Tools recipe)
• Quick Node Clone needs to merge 📌 Automated Drupal 11 compatibility fixes for quick_node_clone Active , or be removed
• Login with Email or Username needs to merge 📌 Automated Drupal 11 compatibility fixes for login_emailusername Needs review or be removed/replaced by something else
• Coffee needs to merge 📌 Automated Drupal 11 compatibility fixes for coffee RTBC or be removed
• The WebAssembly runtime must update its embedded version of SQLite (I think -- this is just a guess about why the trial tests are failing; @mglaman can probably provide more insight)

Marking this postponed on the basis of the blockers listed in the description.

Is there a deadline until when this needs to be decided? I mean the date when the blocking modules will be removed, in case they will have no D11 supported release. Thanks!

Can the blockers in the issue description have individual issues to track against? e.g. remove x module by x date if it does not have 11.x compatibility? For me personally I would remove the modules then add them back when they're ready or a different one if that's appropriate - coffee for example seems like not a good thing to hold this issue up on.

We discussed a D11 deadline of the beta release so Nov 20. We'd still have almost two months to add them back before the initial release.

coffee for example seems like not a good thing to hold this issue up on.

Agreed, and it won't. I would be comfortable saying any module not ready by Nov 13 is out for beta and can be reassessed later. However, that is just my opinion, it is not an official policy!

The SQLite extension was updated for Wasm, so removing 📌 Bump php-wasm and php-cgi-wasm to 0.0.9-alpha-21 Active from the blocker list.

Token Or merged their compatibility patch, so another one bites the dust!

quick_node_clone can be removed 📌 Create recipe to clone entities with ECA Active .

If coffee was also removed, which should be easy since it's standalone and not a dependency of anything, that would leave only login with email or username.

No objection to removing login with email or username also, it's zero config so we can just add it back when it's ready.

Yes that sounds like a good idea to me, then if a module isn't Drupal 11 ready and needs to be added, it's easy to track what those are and try to push compatibility issues through, but they won't hold up anything else that's depending on things in 11.1..

login_emailusername is updated with an RC release → .

If it's only coffee left, then I think it should be fine to go ahead and remove it and actually switch the base now?

Going to be hopeful and switch the status to needs work for that.

Agreed - let's remove Coffee.

Ready for review.

There's one core patch which looks like it should be implemented in dashboard module instead of a core patch, but that patch is already applied so shouldn't block this issue. Looks great otherwise.

Thanks @phenaproxima looks good, will be great to get this done!

Went ahead and opened 📌 Support navigation module Active

Thanks for the RTBCs. For some reason parts are falling off in CI, all of a sudden - probably it realized I was about to accomplish something big, so it crapped out. I'll deal with it tomorrow.

✅

Automatically closed - issue fixed for 2 weeks with no activity.