Drupal 10 readiness meeting / 11 April 2022 [#3274641]

Meeting will happen in #d10readiness on drupal.slack.com.

Hello and welcome to this Drupal 10 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 10 upgrade of their sites are also welcome.
➤ Now happens every Monday at 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/3274641`
➤ *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.

lauriii	hello :wave:
Björn Brala (bbrala)	Hi! On mobile ;)
mherchel	:wave:
mikelutz (he/him)	Hello all.
neclimdul	I guess I am :laughing:. Hi everyone.
larowlan	Hi
xjm	xjm, joining late. Naps++.
andypost	Andy, late
neclimdul	Hey! good to see you andy.
catch	Nat - was here but forgot to post..
shaal	Hello! (super late)
quietone	Hi
kimb0	Hello :wave:
Ilcho Vuchkov (vuil)	Ilcho, Bulgaria (EU)

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

larowlan	Can anyone shed some light on why composer isn't installing dependencies for aggregator on testbot now it's in contrib
andypost	Color module deprecation and actions module rename, how it fits in beta1?
andypost	#2083649: Rename action module to action_ui unblocked

2️⃣ Lots of CKEditor testing happened last week at DevDays!

Gábor Hojtsy (he/him)	Thanks all who came :slightly_smiling_face:
Gábor Hojtsy (he/him)	@wimleers (he/him) and @lauriii were mentoring a dozen+ folks throughout the week, who were actively participating.
Gábor Hojtsy (he/him)	Wim wrote a detailed report at https://wimleers.com/blog/ddd-ghent-2022
Gábor Hojtsy (he/him)	Mentioned there but want to highlight here the live accessibility testing https://twitter.com/gaborhojtsy/status/1512059083129593858?ref_src=twsrc...…]_c10&ref_url=https%3A%2F%2Fwimleers.com%2Fblog%2Fddd-ghent-2022
Gábor Hojtsy (he/him)	Its proven now that the CK5 admin UI built in Drupal is quite accessible :clap:
mglaman	If working on a new module, is it safe enough to start working on the CKE5 integration or worth waiting a month? Especially around media
Gábor Hojtsy (he/him)	@lauriii or @wimleers (he/him) could tell, I think it should be safe given it is beta experimental so should have a backwards compatible API
lauriii	I think it depends on more specifically what you are planning on doing. Regardless of that, I don’t think we are expecting any big API refactorings so even if we ended up changing some things, it should not be too difficult to catch up.
mglaman	I guess the question is if media integration is “80% stable and present”
mglaman	But maybe it won’t be a problem since the embed form modal is gone, right? So it’s completely different
lauriii	The experience of integrating is very different. I’m curious on what is the use case that you are planning to implement because most of the media integration is marked as internal and I’m wondering if we should start planning on exposing some of that as API
mglaman	We hijack the need to setup 5-8 display modes and hijack the rendering via a custom data attribute. Which we altered the embed code form for before.
lauriii	So you are essentially overriding the built in functionality for choosing the view mode?
mglaman	correct, but only for our media source types (edited)
lauriii	we are working on the built in view mode support but we should be able to get it to RTBC later this week
lauriii	do you need to do something fancy on the UI or is it using a select?
mglaman	it’s a select list, so nothing fancy (edited)
mglaman	I could help RTBC that patch, as I need to upload it in my brain for our own CKE5 compatibility
lauriii	I think you might be able to use some of the underlying API
mglaman	should have pushed this as a reason for last minute DDD attendance :wink: (edited)
lauriii	we might have to add a new event for when is inserted from Media Library so that you can handle that use case
mglaman	Actually that’d be amazing. But we may need our own new selector. What if there’s only one display mode because you don’t need 6 of them?
mglaman	by selector, I mean integration plugin.
lauriii	happy to walk you through in more detail any of the bits where you think that would be helpful.. The API there is pretty complex because it has been written as something pretty generic
lauriii	Do you mean there’s default view mode + one extra view mode?
mglaman	I mean what if there is only Default allowed. Would the embed code settings even appear? CKE4 shows “Edit media” but it’s an empty form, explaining there is nothing to do
lauriii	If only default is allowed, I don’t think it would appear in the UI
mglaman	That’s where we may need to provide our own plugin to allow accessing our settings, I think
lauriii	the API is built so that you might be able to integrate from multiple modules relatively easily

3️⃣ More and more people are running into Guzzle’s deprecation problems

Gábor Hojtsy (he/him)	Most recently @neclimdul ran into #3225966: Consider loosening our constraint to allow sites to install Guzzle 6 or 7, or otherwise handle PHP 8.1 deprecations for Guzzle 6 with upgrade status
Gábor Hojtsy (he/him)	With upgrade status this causes a loop where even deprecation checking exposes the deprecations :confused:
Gábor Hojtsy (he/him)	We could try to detect Guzzle 6 in upgrade status and not do the HTTP request I guess as a stop-gap(?). That could be a bit dangerous, but since we are still exec-ing phpstan, it is not necessarily fatal in most cases.
neclimdul	on top of documenting the core issue i did open a related issue in the upgrade_status queue in case there was some sort of clever work around.
Gábor Hojtsy (he/him)	yeah I don’t know if that is clever :smile: it is removing one safeguard from failure to avoid this failure :smile:
Gábor Hojtsy (he/him)	Is there an easy way to fingerprint Guzzle 6?
neclimdul	looking at the diff there are a few new methods and classes you could use. Largely its just native type hints and internal language updates.https://github.com/guzzle/guzzle/compare/6.5.5...7.4.2
neclimdul	like GuzzleHttp\Handler\HeaderProcessor is new
Gábor Hojtsy (he/him)	hm, nice
xjm	Doesn't Composer have APIs we could use to check the installed version?
xjm	Upgrade Status is a module running on the same site so should have access to the codebase no?
Gábor Hojtsy (he/him)	Composer API within Drupal? (edited)
xjm	Yeah, you just need to add a direct dependency on composer/composer like auto updates does probably. Adam H or Ted might be able to help.
xjm	It is already a development dependency for core
xjm	Stuff in the composer directory of core uses composers APIs for template and metapackage update stuff (edited)
neclimdul	looking at the code, i wonder how far we could get just providing compatible classes. like "write" our own CookieJar that's compatibile with everything.
neclimdul	because the code is new CookieJar() and it has an interface.
kingdutch	Here's how to get a package version with Composer 2: https://getcomposer.org/doc/07-runtime.md#installed-versions :slightly_smiling_face:In general, depending on composer-plugin-api or composer-runtime-api is always recommended over depending on concrete Composer versions with the composer platform package.

4️⃣ Composer isn’t installing dependencies for aggregator on testbot in contrib

Gábor Hojtsy (he/him)	Raised by @larowlan
Gábor Hojtsy (he/him)	fails such as https://www.drupal.org/pift-ci-job/2355742
Gábor Hojtsy (he/him)	It visibly does not install any dependencies
Gábor Hojtsy (he/him)	05:14:34 sudo -u www-data /usr/local/bin/composer require drupal/aggregator-aggregator 1.x-dev --prefer-stable --no-progress --no-suggest --no-interaction --working-dir /var/www/html 05:14:34 You are using the deprecated option "--no-suggest". It has no effect and will break in Composer 3. 05:14:35 ./composer.json has been updated 05:14:35 Running composer update drupal/aggregator-aggregator 05:14:35 > Drupal\Composer\Composer::ensureComposerVersion 05:14:35 Loading composer repositories with package information 05:14:35 Updating dependencies 05:14:35 Lock file operations: 1 install, 0 updates, 0 removals 05:14:35 - Locking drupal/aggregator-aggregator (dev-1.x fea79c7) 05:14:35 Writing lock file 05:14:35 Installing dependencies from lock file (including require-dev) 05:14:35 Package operations: 1 install, 0 updates, 0 removals 05:14:35 - Syncing drupal/aggregator-aggregator (dev-1.x fea79c7) into cache 05:14:36 - Installing drupal/aggregator-aggregator (dev-1.x fea79c7): Cloning fea79c7142 from cache 05:14:36 Generating autoload files
Gábor Hojtsy (he/him)	despite https://git.drupalcode.org/project/aggregator/-/blob/1.x/composer.json
Gábor Hojtsy (he/him)	@larowlan when I try to composer require it into a fresh 9.3.x project I get this:Problem 1 - Root composer.json requires drupal/aggregator-aggregator ^1.0 -> satisfiable by drupal/aggregator-aggregator[1.0.0]. - drupal/aggregator-aggregator 1.0.0 requires drupal/core ~8.0 -> found drupal/core[8.0.0, ..., 8.9.20] but the package is fixed to 9.3.9 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command. Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
Gábor Hojtsy (he/him)	ah that was for 1.0, if I specify the dev, it wants Drupal 9.4 of course, which I also don’t have in this :smile:
Gábor Hojtsy (he/him)	Possibly @mixologic can take a look? :slightly_smiling_face:
Gábor Hojtsy (he/him)	I don’t know how to retrieve the composer metadata itself and check there
larowlan	Thanks that confirms my findings too
mixologic	Composer -vvv show -a drupal/aggregator-aggregator should show you the file it downloads, and where it ends up in your cache locally.
mixologic	I can look into this a little later, we got snow today, and schools got closed
larowlan	Thanks
xjm	Whoa school closure in April
xjm	I guess it's because the PNE has like no infrastructure for snow or something?
xjm	Is this because we haven't updated the namespaced version yet?
xjm	Like the name should just be drupal/aggregator once we fix the façade, right?
xjm	Did we manually test HAL? (edited)
xjm	It would be good to know if it's just aggregator or we're having the problem across the deprecated modules
xjm	Like is it because of Laminas Feed as a composer dep for aggregator etc.
xjm	I think we need manual testing of upgrading from the core module to the contrib one as a step for the module deprecation process /cc @quietone
Gábor Hojtsy (he/him)	I checked out composer -vvv show -a drupal/aggregator-aggregator but it does not seem to show anything that I can usefully understand…
larowlan	{ "packages": { "drupal/aggregator-aggregator": [ { "keywords": "Actively maintained,Syndication", "homepage": "https://www.drupal.org/project/aggregator", "version": "dev-2.x", "version_normalized": "dev-2.x", "license": "GPL-2.0-or-later", "authors": [ { "name": "larowlan", "homepage": "https://www.drupal.org/user/395439" } ], "support": { "source": "https://git.drupalcode.org/project/aggregator" }, "source": { "type": "git", "url": "https://git.drupalcode.org/project/aggregator.git", "reference": "c515223f4421eb8588edcd87071a75cccca29ac3" }, "type": "drupal-module", "uid": "aggregator-aggregator-3272814", "name": "drupal/aggregator-aggregator", "extra": { "branch-alias": { "dev-2.x": "2.x-dev" }, "drupal": { "version": "2.x-dev", "datestamp": "1648771938", "security-coverage": { "status": "not-covered", "message": "Dev releases are not covered by Drupal security advisories." } } }, "require": { "drupal/core": ">=10.0" } }, { "version": "dev-1.x", "version_normalized": "dev-1.x", "source": { "type": "git", "url": "https://git.drupalcode.org/project/aggregator.git", "reference": "fea79c71421c6409dc3befa34126abd74ad248c9" }, "uid": "aggregator-aggregator-3272612", "extra": { "branch-alias": { "dev-1.x": "1.x-dev" }, "drupal": { "version": "1.x-dev", "datestamp": "1648688613", "security-coverage": { "status": "not-covered", "message": "Dev releases are not covered by Drupal security advisories." } } }, "require": { "drupal/core": ">=9.4" } } ] }, "minified": "composer/2.0", "last-modified": "Fri, 01 Apr 2022 20:58:14 GMT" }
larowlan	both of them (1x, 2x) have chopped the laminas/feed-reader dep
larowlan	I'll dig into the project-composer code
cmlara	One thing I notice, the project doesn't list a core version in its composer require section.I know there is code on the package server side that adds the core version in from the module info if you don't list it.Wonder if that is overwriting the entire section not just appending? Quick test is to add that into the composer.json of aggregator?
cmlara	Using the gitlab search found another contrib 'open_project' has a dependency in its composer.json for third party but no core version listed. Looking at the json on the package server it also stripped out their dependency and only lists core.I think that is going to be the culprit code on the package server side.
larowlan	will try that
larowlan	doesn't look to have made a difference
cmlara	Interestingly the datestamp for the release times hasn't changed in the json. That is suppose to get updated at each commit isn't it? Package server perhaps hasn't executed yet or a cache issue? (I'm looking at another package and the datestamp doesn't show a commit I did last night but did update the datestamp for a commit I did 4 days ago)
larowlan	feels like this is definitely going to be the disconnect between project = aggregator and composer name = aggregator-aggregator
cmlara	Just looked at HAL, the Feb 24th change to the module supported version (in the module file) didn't make it into into the package server json, it is frozen to the specs for when they tagged the dev release a few days prior. So does seem to look like these modules with different project vs composer name are not triggering updates after the release is tagged
quietone	Just added a step to manually test upgrade from core to contrib to the module deprecation process /cc @xjm
xjm	#3266395: Ensure that hal do not get special core treatment is still open and I do not see a similar issue for Aggregator at all /cc @mixologic @larowlan That is for sure already in the module deprecation instructions, but we should check to make sure it's listed in the other metas' ISes as well
xjm	Oh ah, here is the aggregator one; just wasn't listed where I was looking (was looking at the wrong meta) #3272246: Ensure that aggregator doesn't get special core treatment @mixologic (edited)
larowlan	@mixologic can you put this one on your list - thanks :pray:

5️⃣ Color module deprecation

Gábor Hojtsy (he/him)	Raised by @andypost
mherchel	cc @andy-blum

6️⃣ Actions module rename

Gábor Hojtsy (he/him)	Also raised by @andypost
catch	I think we might end up removing actions module (leaving actions support itself in system module) rather than renaming it?
xjm	Yeah, that seems like the course of action that is most likely
andypost	Maybe instead we can move action config entity into core and only admin ui could live in system
xjm	We are not sure the UI is an 80% usecase
xjm	In #3158669: [Policy] By default deprecate non-experimental modules that are used by less 5% of sites before the next major version it's 8% usage, just above all the modules that are already marked for removal
xjm	It makes sense to have the actions themselves in core (they already are a subsystem) but the UI is for more specific usecases
andypost	Yes, that's why we wanna rename the module in UI at least, but moving entity to core out of system module looks next step to finish, after moving all actions already (edited)