Drupal 11 readiness meeting / 7 October 2024 [#3479217]

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: `https://www.drupal.org/project/drupal/issues/3479217`
➤ *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

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

smustgrave	Hello
hestenet (he/him)	Tim from teh DA, just following along 🙂
Fathima Asmat	Fathima :wave:
japerry	hihi
kimb0	Kim :wave::skin-tone-2:
Björn Brala (bbrala)	❤️ (edited)

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

smustgrave	Not sure worth a full thread. But have been bit by this issue where I made a release for D10 & D11, while fixing phpstan issues I may have (my mistake) replaced services that broke D10.1, for example. I think the recommendation should be for new major releases to have new releases like D10.3 & D11.
smustgrave	Thanks much better title

2️⃣ Celebrations :tada: (edited)

smustgrave	Have all but 2-3 of my modules with a D11 release
Fathima Asmat	https://www.drupal.org/project/author_bulk_assignment/releases/2.0.0

3️⃣ How to avoid mistakes with removing Drupal 10 support in a contrib update

Gábor Hojtsy (he/him)	@smustgrave raised thisNot sure worth a full thread. But have been bit by this issue where I made a release for D10 & D11, while fixing phpstan issues I may have (my mistake) replaced services that broke D10.1, for example. I think the recommendation should be for new major releases to have new releases like D10.3 & D11.
Gábor Hojtsy (he/him)	I believe the best way to release a Drupal 10 and 11 compatible release, not separate ones 🙂
smustgrave	Sorry I meant a new branch for “^10.3 \|\| ^11” vs “^10 \|\| ^11"
cmlara	The other side of this is to make sure you run a manual test back and test your minimum version listed.Better yet: set a default job in your GitLabCi that tests against your oldest supported release.Obviously this requires you have tests in place that execute the code in question which I struggle with in some projects, however witn time it gets better.
smustgrave	The most recent module I had this happen on I had it check previous. But that was 10.2 not 10.1 so it got missed
cmlara	That’s part of the reason I’m not a fan of the previous job, a minimums jobs would provide a lot more testing coverage IMHO. Also separating out the PHP syntax verification job into a minimum test job can probaly help to avoid breaching PHP version syntax. quasar_phplint is pretty ease to add and set to your oldest PHP version and unlike the gitlab_templates doesn’t use a full composer pipeline. Note: still in very early dev, it is part of my personal process to move away from gitlab_templates to a slightly different but very similar design.
moshe	FWIW, I agree that max/min testing makes more sense than the previous/next approach of gitlab_templates
smustgrave	That would be nice
cmlara	Another option is if you don’t want to do min/max on every commit, at least setup a job that on tag push runs every variant and a min max[#3442279] would be an even further extension in that you could make the tests a prerequisite for publishing the release.
japerry	I agree that having a min/max is probably more efficient and does a better job at ensuring your release isn't breaking code.With the gitlab_templates process moving to automatic D11 inclusion, its likely I'll too fork into another branch or project. Honestly, it'd be nice if gitlab_templates parsed info.yml for min and max to setup tests, with an optional 'next major' when the module under test doesn't currently support it.
japerry	and I'll likely fork it because of the dropping of Drupal 9.5 support.
japerry	With nearly 20% of D8+ sites still using Drupal 9.5, and nearly 60% of them using a version of Drupal less than 10.3, IMHO its not a good idea to only support Drupal 10.3 and above.
cmlara	Fwiw I’m trying to make (and keep) the quasar components at 8.8+ (at least untill I get to a point that I need a new major branch than I might consider a change but for now I want some much older stable support)I do belive I have 9.5 working already, but ran into a few issues around 9.2 I haven’t decided how to solve yet. I probaly should post the code as is at least so it can be used for testing. I have the lint jobs up already.
Björn Brala (bbrala)	Pinging @fjgarlin since this discussion is kinda relevant to him.
fjgarlin	Note that forking the gitlab_templates (or just copy/pasting and then adapting) is a totally valid option, and perhaps even recommended for when the default templates do not fit certain module’s needs.You can easily grab a release that works/worked well for your module, copy the templates into your own module, and start changing things as needed. we are not limiting GitLab CI configurations, so it’s not “use ours or nothing”, it’s more “use ours if it’s good for you, otherwise feel free to adapt”
fjgarlin	note that even getting the templates to work with D8 or D9 would still be possible, just by tweaking a few variables (see D9 example in https://project.pages.drupalcode.org/gitlab_templates/info/variants/#cre...), but again, you can totally fork and adapt as needed.

4️⃣ Twig 3.12 issues reported by Upgrade Status

Gábor Hojtsy (he/him)	Upgrade Status has been reporting various Twig 3.12 issues:#3473440: [meta] Fix Twig 3 deprecations
Gábor Hojtsy (he/him)	Most of these were resolved with the core release last week in https://www.drupal.org/project/drupal/releases/10.3.6
Gábor Hojtsy (he/him)	https://www.drupal.org/project/drupal/issues/3477375 is the one that remains
lleber	re: #3477375 - is there a good reason to introduce b/c problems with drupal_spaceless as a filter versus simply polyfilling, for lack of a better term, spaceless? (edited)
Gábor Hojtsy (he/him)	@finnsky, @Björn Brala (bbrala) and others are working on this :)
finnsky	Twig replaced spaceless as is. all that we have whitespace control with - and ~https://twig.symfony.com/doc/3.x/templates.html#templates-whitespace-con... this is enough. but works different.
Björn Brala (bbrala)	Unfortunately it is not. Seems a lot of extra whitespace is getting added and breaking stuff. Especially when using twig debug.A polyfill might work, but I'm not sure how yet since the errors are at compile time. So cannot replace the filter in twig. It would need to be done outside twig.
finnsky	i’ve found yet another problem
finnsky	different output in default and twig debug mode was before that fix.
finnsky	i think we just need to fix regressions here (manual testing)
finnsky	here separated link with/without twig debug BEFORE fixhttps://gyazo.com/edc2f9199852857462b66a67d0254b16https://gyazo.com/4172...
finnsky	Both are not good
finnsky	after fix all fine in both modes(real spaceless)https://gyazo.com/416307bfb6c5fd346325f63f005858a7but visual regression ;)
finnsky	Problem not inAfter fix we break somethingbut inIt was not correct before:)
Björn Brala (bbrala)	Yeah nod notices the same.
Björn Brala (bbrala)	I posted in the issue, an option might be to override the TwigFilter class, but that feels rather invasive. I'd like the opinion of a core committer on that one.
finnsky	Let's see. I moving through all templates now and fixing regressions
finnsky	Fixed all regressions. Please review