Hello and welcome to this Drupal 11 readiness meeting!This meeting:➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 11 upgrade of their sites are also welcome.➤ Happens every other Monday at 20:00 CEST (currently 18:00 UTC).➤ Is done over chat.➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!➤ Has a public agenda anyone can add to:#3482257: Drupal 11 readiness meeting / 21 October 2024➤ Transcript will be exported and posted to the agenda issue. For anonymous comments, start with a 👤 emoji. To take a comment or thread off the record, start with a 🚫 emoji.

0️⃣ Who is here today? Comment in the thread below to introduce yourself.

hestenet (he/him) Tim from the DA :wave::skin-tone-3:
Eric (sikofitt) Eric from Stanford University
bbrala Bjorn from SWIS 🙂
bbrala And i didnt reconize you @Gábor Hojtsy (he/him), new photo :P
Gábor Hojtsy (he/him) Haha, according to Kuoni I can nail the same face for each photo somehow :smile:
finnsky Hello! Ivan (edited)
James Shields Hi! James from Ireland (lostcarpark on d.o.)
lleber Luke from PSU world campus - trying to figure out how to best spend scarce backlog/non-billable hours to optimize contributions that align goals.
VladimirAus VladimirAus :kangaroo:

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

Eric (sikofitt) I haven't tried yet, but I was curious if anybody knows off hand if this module - https://github.com/mglaman/composer-drupal-lenient will work with Drupal 11?I've noticed that a lot of Drupal 10 modules work with 11, but the requirements are still set at 10.
berdir not sure in how many channels it was published already, but might worth mentioning the GitlabCI changes, it defaults now to 11.0 as the current/default branch and to run tests on D10 still, you need to opt in to previous major.
finnsky Step by step moving to jQuery dialog deprecation[#3460979]
James Shields I've been loving the new experimental Navigation, but have been missing the "Admin Toolbar Extra Tools" module for things like clearing cache and running cron. I've created a simple module to add that functionality to Navigation: Navigation Extra Tools.Might be of interest for D11 readiness!

2️⃣ Celebrations :tada:

3️⃣ Use of drupal-lenient Composer plugin with Drupal 11

Gábor Hojtsy (he/him) @Eric (sikofitt) raised this
Gábor Hojtsy (he/him) I believe https://github.com/mglaman/composer-drupal-lenient should work fine yes on Drupal 11
Gábor Hojtsy (he/him) To require projects that are compatible with Drupal 11 with patching. You should then use https://github.com/cweagans/composer-patches to apply the patches
Eric (sikofitt) The problem (I think) with composer-patches is requirements need to be patched before.  I have used a number of patches for Drupal 11, but when trying to upgrade to 11 it still fails the requirements because they are patched after downloading.
Gábor Hojtsy (he/him) Yes that is what https://github.com/mglaman/composer-drupal-lenient is for 🙂
Eric (sikofitt) Okay, got it.  I'll test this out today with 11 🙂 (edited)
Eric (sikofitt) Oops, totally missed this. It's supported 11 since last year :smile:https://github.com/mglaman/composer-drupal-lenient/commit/6f9e03f238403b...
Nick Dickinson-Wilde It actually supports Drupal 12 now (as of last week I think) (edited)

4️⃣ Twig 3.12 errors are resolved for now

Gábor Hojtsy (he/him) Last meeting we discussed[#3473440], all but one of those got committed and released in Drupal 11.
Gábor Hojtsy (he/him) https://www.drupal.org/project/drupal/issues/3477375 is outstanding still
Gábor Hojtsy (he/him) We added a rule to Upgrade Status to categorize these issues as "ignore", which should help with running on older versions of Drupal 11.
Gábor Hojtsy (he/him) Despite the spaceless issue not committed to core yet, Upgrade Status' test suite is not producing it anymore, so I think project update bot can (or already did?) continue operation. cc @bbrala who would know more.
bbrala I will get to projectbot again soon.
bbrala I saw your commits, so that triggered me. 🙂
Gábor Hojtsy (he/him) Thanks @bbrala for the attempts at fixing tests, even though thankfully core fixed earlier than us powering through those :see_no_evil:
bbrala haha, yeah, i kinda gave up on those and started helping on the core side back then.Spaceless seems close also. @nod_ was quite helpfull there, hopefully he can come back and verify the progress by the other contributors.
finnsky For spaceless i’ve fixed visual regressions. And also added suggestion to port that drupal_spaceless to contributed module[#3477375]#comment-15805368
bbrala Seems someone even got the option to fix it on core working. Which confuses me a lot :sweat_smile:
finnsky not sure exactly how it should happens in deprecation style. but core not need that new filter globally.

5️⃣ GitlabCI defaults changed: Defaults now to 11.0 as the current/default branch and to run tests on Drupal 10 still, you need to opt in to previous major

Gábor Hojtsy (he/him) Suggested by @berdir 🙂
Gábor Hojtsy (he/him) Any docs we should link? 🙂
berdir https://www.drupal.org/drupalorg/blog/gitlab-ci-templates-will-make-drup... I guess
berdir result is that you might see tests fail on merge requests you create/updated in projects that aren't compatible yet. Or, if projects needed workarounds to get D11 tests to run like using lenient/patches for dev dependencies, that needs to be updated and applied to the default composer version now
lleber What's the next major run on now?
berdir nothing
berdir automatically skipped until 12.x branch is created
berdir previous minor is also skipped at the moment, will run again as soon as 11.1.0 is out, so you can keep that enabled and it won't break
berdir and current is now actually 11.0.latest, not 11.x (11.1) development branch, so more stable than next major was before
lleber Ah nice...so running tests on previous and next will have the versions automagically managed by the DA moving forward?
berdir yes. it was always automatically managed, but now they're also automatically disabled if there's no matching branch for a certain next/previous setting
James Shields I've verified that next major and previous minor are being skipped.
James Shields I feel that since 10.2 and 10.3 are both supported at present, it would be nice to have an easy way to run tests against both. At present, previous minor tests on 10.3, but I think unless you set up an explicit test for 10.2, it's left out in the cold.
lleber I kinda agree there.  Having spent the time customizing all but 3 of my contrib modules' .gitlab-ci.yml files to test on current + next, it seems to have been just in time to have to refactor them again to run against "all currently supported core versions" :confused:
James Shields Actually a single OPT_IN_TEST_ALL_SUPPORTED flag that ran against all the current supported versions might be a neat way to do it.
Obviously we're not counting 7.x as a supported version for this!
fjgarlin Creating variants is very easy https://project.pages.drupalcode.org/gitlab_templates/info/variants/#cre...
lleber Individually, sure, but the time suck really adds up if you have to configure dozens of projects + cut releases :confused:
fjgarlin “Testing all” could be a big costly pipeline that we might not want to encourage or allow easily. Tho remember that each maintainer can fully customize the gitlab ci file to the project needs
lleber Not sure if there's an equivalent, but this is what we do with our github hosted modules: https://github.com/PSU-OOE/drupal-module-qa-action/blob/main/action.yml
fjgarlin You can have a centralized file and then reference that file from those dozens of projects too 🙂
lleber It's an interesting note that the cost to test a contrib module against all supported core versions can be a factor.  Suppose it's always a balance between stability, cost, and actual support ranges.I'm of the mind that if tests aren't running against a particular version, it's worse than unsupported, because it's advertised to work, but nothing is checking to make sure it actually does.
fjgarlin We have up to 5 variants (not all run by default but all of them are easy to customize) that help cover a good deal of versions out of the box
lleber Presently, 10.2, 10.3, and 11.0 are the only supported core versions, right?
lleber Given Drupal's support model, it's usually a max of 3 supported minors at any given point in time..?
lleber Ah, nevermind -- seems like it'd be up to 6.10.x-security, 10.x-active, 10.x-dev, 11.x-security, 11.x-active, and 11.x-dev
James Shields “Testing all” could be a big costly pipeline that we might not want to encourage or allow easily.I think it's potentially one more than enabling all the current opt-in variable.We've gone from enabling everything testing against 5 versions, to 3 versions, so if there's a time to implement with minimum impact, this would seem to be it.But if you think that's making things too easy to use a lot of resources, I still think defining a variable called something like "OPT_IN_TEST_PREVIOUS_SECURITY" or something like that to pick up the security release of the previous major version.
lleber I think another* stance here is that a more opinionated direction for contrib could be really beneficial to the cause.  Instead of every contrib maintainer individually "figuring it out" for their projects, is there an option to just give the reigns to the DA and never have to worry about it again? (edited)
lleber Presently, contrib has to commit a file manually to enroll into testing, even if it's the default template (at the exact time they commit it).
James Shields I do think tests need to be "opt in". For one thing there are a lot of abandoned or unmaintained modules that would suddenly opt in - though I guess they wouldn't be tested unless people were opening merge requests.
James Shields But I think an easier way to opt in to "best practice" tests would be beneficial.
lleber Automatically marking unsupported if tests haven't been passing in N majors seems a more honest approach.

6️⃣ jQuery Dialog deprecation making progress for Drupal 12 (edited) 

Gábor Hojtsy (he/him) @finnsky raised this, see[#3460979]
finnsky yeah, parent task cannot be resolved in one commit
finnsky even work in contributed module partially blocked by amount of old jQuery. https://www.drupal.org/project/dialog_native

7️⃣ Drupal 11.1 will come with native support for OOP hooks!

Gábor Hojtsy (he/him) See https://drupal.community/@dropismoving/113329878372126989 🙂
Gábor Hojtsy (he/him) There is guidance to implement new OOP hooks in a way that is backward compatible with Drupal 10 too there.
Gábor Hojtsy (he/him) (Not as nifty to screenshot though :D)
bbrala Was happy to see DeprecateionHelper in the CR here.
bbrala And  EXTREMELY happy we can stop with magic functions :stuck_out_tongue: (edited)
lleber What exactly does the long-term future for hooks look like?  Can we expect Drupal majors to start dropping support for procedural hooks, or will both remain in tandem for the foreseeable future?
lleber In other words, what B/C ROI can be expected?  Why should clients pay to have hooks OOP'd? (edited)
moshe The CR states that hooks are being deprecated and will be removed eventually
moshe There is a rector that will OOP existing implementations. Its a small level of effort, even on a big site.
lleber I see now.  Missed that.In a later Drupal version (Drupal 12 at the earliest), we expect that support for procedural hooks will be removed, at which time these services and the LegacyHook shims will need to be removed as well.So 2026 is the rough earliest possible end of procedural hooks.
Gábor Hojtsy (he/him) Yeah minor releases can't remove hooks or support for them.
pingwin4eg Hello. @fabianx raised a good question regarding arbitrary namespace for a service class with hook attributes in[#3442009]#comment-15568818.I wanted to ask if there is a follow-up issue yet. Or can we discuss it here?

8️⃣ Catching up with meeting log backlog

Gábor Hojtsy (he/him) I attempted to save prior meetings, but the parser breaks on some meetings in July and one in August. I'll need to debug the JS / DOM and then I can save those too.
Gábor Hojtsy (he/him) Surprised more initiatives did not notice this yet.
Gábor Hojtsy (he/him) It seems to happen on messages with an image only.
Gábor Hojtsy (he/him) (At least)

9️⃣ Thanks all for coming, keep discussing in the threads and see you in two weeks! 🙂

Participants:

Eric (sikofitt), Berdir, finnsky, James Shields, Gábor Hojtsy, Nick Dickinson-Wilde, bbrala, Luke.Leber, , fjgarlin, moshe, pingwin4eg

Comments

gábor hojtsy created an issue. See original summary.

gábor hojtsy’s picture

Issue summary: View changes
smustgrave’s picture

Missing a few threads.

smustgrave credited bbrala.

smustgrave credited berdir.

smustgrave credited moshe.

smustgrave’s picture

Issue summary: View changes
Status: Active » Needs review
smustgrave’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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