🇺🇸United States @dww

Thanks @nicxvan for opening this and to @claudiu.cristea for diving in to move it forward. Per Slack (but posting here for better visibility), I think it'd be better to do 1 issue per module whenever possible, instead of multiple (probably conflicting) issues for separate functions in the same .module file.

Exceptions to the above would include things like update.module (😅😬😊) that still have 500 loc, a big mix of different kinds of procedural functions (some already deprecated, many not), including helper methods, stuff related to fetching update data, and a few other odds and ends. In that case, I'd probably open separate issues for consolidating all the data fetching code into the UpdateFetcher service, another issue for UI-related helper methods, and maybe a 3rd for _update_project_status_sort(). Maybe another for update_storage_clear(). 😂 More or less...

But generally, probably only need 1 issue per .module file.

Thanks again!
-Derek

Per Slack discussion, we're going to keep these issues open for 2 weeks of community feedback before RTBC.

Thanks,
-Derek

Per Slack discussion, we're going to keep these issues open for 2 weeks of community feedback before RTBC.

Thanks,
-Derek

Per Slack discussion, we're going to keep these issues open for 2 weeks of community feedback before RTBC.

Thanks,
-Derek

Amazing! Definitely +1 from me. @mstrelan is a brave soul for volunteering to fill this role! 😂 They are extremely careful, thorough, knowledgeable, helpful, and kind. We're lucky they want to contribute in this way!

Huge +1 from me, too! Will hopefully be able to lean on your expertise while trying to keep the lights on in content_moderation ( 📌 Add dww as a maintainer of the Content Moderation subsystem Active ) 😅 🙏

+1! @smustgrave is extremely dedicated to core development (via both the #needs-review-queue-initiative and #bugsmash), active in Slack, always trying to help move things along. He's also kind, thorough, and detail-oriented. Thanks for volunteering for the role! We're lucky to have you so involved and willing.

+1! Heartily agree that @penyaskito is a joy to collaborate with, extremely knowledgable about this subsystem, and very kind. We're lucky to have them volunteer for the role!

+1! Heartily agree that @penyaskito is a joy to collaborate with, extremely knowledgable about this subsystem, and very kind. We're lucky to have them volunteer for the role!

Sweet, thanks!

Noticed that the title and summary don't agree. Also, we don't need a topic about a coordinator, right? Sounds like this is about a 'Dependency' topic. Can we update the title and summary accordingly?

I believe "Define" is done, right? There was a closing </del> but no opening, so I added that.
Also, a link for 📌 Define core gate for 'dependency coordinator' topic Active which is already open.

Haven't tested this at all, but it looks like it's from the group permission called "Receive email notifications". So it's a per-group permission, not a site-wide thing.

I don't believe so. It's already been ported. Now the release managers need to review and decide what to do with the open MRs. Maybe RTBC is more appropriate?

Thanks for the kind words! I can't endorse the claim I'm always patient, willing to help, or easy to communicate with... but I try. 😂

p.s. The previous link was broken:

https://www.drupal.org/about/core/policies/maintainers/add-or-remove-a-s... →

As part of crossing that off, I fixed the link to point here:

https://www.drupal.org/about/core/policies/maintainers/add-or-remove-a-s... →

Perhaps needs updating in the other sibling issues...

As I wrote at the parent issue:

Tentatively willing to raise my hand for content_moderation. Used it on a few sites and submitted some fixes. About to adopt it for another regular client, so I’ll have at least some paid time to work on fixes and changes that site might need.

Currently the only active maintainer for update.module, and unofficial co-maintainer for a bunch of other parts of core (views, date*, etc).

If anyone else is in a better position, happy to let them take it. But willing to put my name in, since I believe an over-committed and intermittently available human is better than a ? 😂

I'm already formally the subsys maintainer for update.module (Update Status). I'm familiar with and agree to:

• The definition of core subsys maintainers
• Core subsys responsibilities
• Issue etiquette and being constructive

Thanks!
-Derek

dww → made their first commit to this issue’s fork.

Re: #33: that’s handy, thanks. But we’d still need the manual effort of rebasing the issue forks, etc. I’m not sure how useful bulk updating the MR metadata is without also getting the branches in Git right at the same time.

Cool, thanks. Updating summary to match current reality.

Re: #20: that might all be true. However, this is only the dev dependency in the core composer.lock, not whatever version of composer might be in the PATH or otherwise in use by humans at the CLI, CI, deployment pipelines, etc.

So we have it if we want it, opened an MR for 10.5.x, too.

@drumm re: #30: Fantastic, thanks!

The 11.2.x MR is basically working now. Moving to NR for release manager review / sign-off / direction.

Thanks!
-Derek

Minimum changes to get composer/composer to 2.9.3 on 11.2.x:

composer require --dev 'composer/composer:^2.9' 'justinrainbow/json-schema:^6.5' 'react/promise:^3.3'

Resulted in a few more changes than I really wanted. I manually removed the react/promise line from the resulting composer.json so that we still just have it in the require section from composer/composer instead of a new root dependency.

Pushed the results to the 3565943-update-composer-2_9_3-D11_2 branch -- see https://git.drupalcode.org/project/drupal/-/merge_requests/14238.

One thing, not sure if it's for here or a new drupalorg issue, is that I don't know what project_release is going to do with all its version fields if you try to create a release node pointing to a branch called 'main'. Way, way, way back, we actually had release nodes that pointed to "HEAD". See https://www.drupal.org/node/86863 → for some gory details circa 20 years ago. 😂 Lots has changed, but not everything. We might need some changes to drupalorg_project* somewhere to special case 'main' and do something creative with the underlying version_* fields so that once main exists, we can create a release node for d.o so that issues can target that version.

Or, we hurry up and migrate core to GitLab issues. 😬 But I think this ship is probably going to sail before that happens, so we're still going to have to work around the project_issue vs. project_release stuff.

Thanks! Closed 14236, and made a few more updates to the summary for remaining tasks.

Updating summary with links to MRs for each branch.
Remaining tasks including deciding what to do with 11.2.x and 10.5.x.

Thanks for the review!

I opened MR 14237 for the 10.6.x backport: https://git.drupalcode.org/project/drupal/-/merge_requests/14237

I opened a branch for the 11.2.x backport, but composer is pinned to 2.8.9 there. Not sure what's happening in that branch, and if we update dependencies like this or not. Tagging for RM review to confirm if/where we want this change backported.

Opened https://git.drupalcode.org/project/drupal/-/merge_requests/14236 with the trivial results of composer update composer/composer. Let's see what the bot thinks...

Thanks for the commits!

Opened 📌 [security hardening] Update composer to 2.9.3 Active for #63. .

dww → created an issue.

Cool, thanks. Changes look good again. Valid examples with more semver than bespoke-ver.

dww → created an issue.

Although the infra problem is resolved, I think it’s a major bug that package_manager will fatal error in this situation instead of gracefully providing an error that callers (in this case, automatic_updates) can notice and provide useful feedback.

Adding some duplicate issues from the core queue as related.

🐛 release-history/drupal/current endpoint returns "No release history" error (December 2025) Active

The composer support request here is resolved. The rest of this is probably now duplicate with that infra issue…

Thanks for the report. There was a major Drupal.org outage a few days ago (disk failure on an NFS server). I suspect some error responses might have been cached. The endpoint is working fine for me, but maybe I’m hitting a different cache or something.

Moving this to the infra queue since it’s more an infrastructure thing than Drupal.org content or customizations. Hopefully the right folks with the power to purge the caches will see it sooner this way.

p.s. Re: #5 and composer...

if you *want* composer.json to reflect this change, you can do:

composer require 'drupal/core-recommended:^11.3' -W

and it should update both composer.json and composer.lock.

But there's no harm in composer.json saying you're requiring at least 11.2 (which is what ^11.2 means) but composer.lock saying you're on 11.3 (which satisfies the constraints).

Not sure about the "No editions found" text. That screenshot looks nothing like the "Available updates" report I know from the update.module (Update Status) from Drupal Core. Something is seriously altering that report in that screenshot. Core doesn't talk about "skins" like that. So I'd need to know what's taking over the Available Updates report on your site to be able to provide any feedback or support about that error message.

Meanwhile, to answer your question about composer.json -- that's expected. Unless you're bumping the major version, composer.json won't change for an update like this, only composer.lock does.

Okay, here's some progress to report. Reading through the core scheduled pipelines, looks like 10.6.x daily job is consistently failing with the PHP 8.4 configuration:

https://git.drupalcode.org/project/drupal/-/pipelines/693649
- PHP 8.4: https://git.drupalcode.org/project/drupal/-/pipelines/693679
- Build failure: https://git.drupalcode.org/project/drupal/-/jobs/7767121

So, I launched that same pipeline here:
https://git.drupalcode.org/issue/drupal-3557585/-/pipelines/694128
And the "Build" test is now passing:
https://git.drupalcode.org/issue/drupal-3557585/-/jobs/7773059

Therefore, even without resolving the "updated deps" vs. phpstan woes I mentioned in #46, I think it's safe to call this RTBC and commit the backport...

Hrm. The default pipeline passed, so I didn't break ComponentsTaggedReleaseTest. But it looks like the daily 10.6.x job only fails in here with the updated dependencies thing, since we're pinned to an earlier composer (I think). So I tried running the updated deps job manually. However, it fails with phpstan complaining about deprecated stuff from Twig and OpenTelemetry. It doesn't seem there's any way to move forward and have the actual tests run in this case. Seems fairly expected that phpstan will hit deprecation errors with updated dependencies. Can we change the phpstan job inside the updated deps part of the pipeline to allow failure and only warn on problems but not halt the entire pipeline?

Drupal CMS enables automatic_updates → (from contrib) by default. That's what's injecting the 'update' link on admin/extend. Tempted to move this issue over there, but sure, we can call it a package_manager.module bug for now. Regardless, update.module (Update Status) is not involved here, so thanks for moving the component.

Opened an MR for 10.6.x: https://git.drupalcode.org/project/drupal/-/merge_requests/14168
core/modules/package_manager/tests/src/Kernel/PhpTufValidatorTest.php only exists in 11.x.
But the fix for core/tests/Drupal/BuildTests/Composer/Component/ComponentsTaggedReleaseTest.php applied cleanly.
Let's see what the bot thinks at https://git.drupalcode.org/issue/drupal-3557585/-/pipelines/694106

dww → made their first commit to this issue’s fork.

Note: latest pipelines are failing. If you rebase against 11.x, you'll get various fixes, including:

#3551373: [random test failure] ManageDisplayTest testFormatterUI() and testWidgetUI() →
📌 Tests using Composer (version 2.9.0-RC1) are failing Active

That will hopefully get us green pipelines again in here.

Needed a rebase for 📌 Tests using Composer (version 2.9.0-RC1) are failing Active

I realized the sequence of events described in #26 means we also lost commit 1f657dc5 from comment #21. Just cherry-picked that and pushed.

I just re-reviewed the current MR changes. I think we're RTBC, but I'm not qualified to formally move the status now that I've been so involved in the code. 😅

Added suggestion with link to 🌱 [12.x] [meta] Release Drupal 12 in 2026 Active instead of a TBD

FWIW, this randomly failed again at https://git.drupalcode.org/issue/drupal-3560560/-/jobs/7723586

Re: #25: Totally agree. The version of that merge conflict I had pushed to the MR removed the quotes:

https://git.drupalcode.org/project/drupal/-/merge_requests/14066/diffs?c...

Apparently, @quietone didn't pull my changes when they worked on #23, re-resolved the conflict themselves, and re-added the quotes:

https://git.drupalcode.org/project/drupal/-/merge_requests/14066/diffs?c...

Then they added https://git.drupalcode.org/project/drupal/-/merge_requests/14066/diffs?c...

They didn't mention any of this in their comments, and I didn't think to re-check the merge conflict I had already resolved, and only noticed some concerns with 179b8f29f6 and pushed https://git.drupalcode.org/project/drupal/-/merge_requests/14066/diffs?c... to address those.

Regardless, thanks for catching the error! It would have been really sad had we committed this and re-broken 🐛 TypeError: trigger_error(): Argument #2 ($error_level) must be of type int, string given in trigger_error() Active .

Generally, I'm glad we no longer require "deprecation tests" that only trigger deprecations, but at this point, I'm sort of wishing we had a test that was calling getCountNewComments() and expecting a deprecation, not a fatal error. 😅

This fell way off my radar. The docs in #9 seem great. Thanks for putting those together! I think the Why column text is excellent, and helps people understand when this is a good idea, and when it isn't.

All 5 of us who have participated so far support this policy change, and no one has yet registered any opposition. That said, 5 people isn't exactly a huge sample size. 😅 But generally, the sense I get from being on the coding standards committee and following Drupal Slack + issues is that folks are revolting against boilerplate (rightfully), and this is a step in the right direction to being able to freely remove things that aren't adding value to our codebase. So I'm going to be bold and move this to RTBC, to see whatever other governance steps have to be taken to make this official.

More links to repeat jobs and results.

Also, there are random fails in both testFormatterUI() and testWidgetUI(), widening scope of issue title.

Re: #23 - okay, cool. Glad we can just fix that here as part of cleaning all these up. I pushed another commit to reword the message to be more like the original message, just including the ::_constructor() stuff I was talking about. Hope that's agreeable. 😅

Should we move the "11.3.0 release target" tag?

Repeat class job for the "baseline" MR (the test code in the current 11.x branch) is here:

https://git.drupalcode.org/issue/drupal-3551373/-/jobs/7718440 (Repeated 500 times, failed once).

The repeat class job in the actual MR is here:

https://git.drupalcode.org/issue/drupal-3551373/-/jobs/7717822 (All green).

Adding links to relevant MRs and pipeline jobs to the summary.

This needs to be converted into a merge request against the 11.x branch before it can move forward.

Thanks!
-Derek

Ran into this at https://git.drupalcode.org/issue/drupal-3560560/-/jobs/7717584 so I decided to take a look and try to smash this one.

Launched the Repeat Class test here: https://git.drupalcode.org/issue/drupal-3551373/-/jobs/7717822

Latest pipeline hit this random fail: #3551373: [random test failure] ManageDisplayTest::testFormatterUI → Re-running that test (and will be opening an MR in that issue to fix the random fail).

dww → made their first commit to this issue’s fork.

I re-confirmed that everything I listed in #15 is indeed in the IS and that none of those issues have CRs. So that's all cool.

Pushed commit 1f657dc5 to change the deprecation messages in LanguageConfigFactoryOverride to say the new constructor params will be required in D12, not removed.

The only other minor nit in the messages touched by this issue is here:

core/modules/user/src/Theme/AdminNegotiator.php:61:      @trigger_error("Passing the $deprecated_service_name (entity_type.manager service) to AdminNegotiator is deprecated in drupal:11.2.0 and will be removed in drupal:12.0.0. There is no replacement for this service, as it is not used. See https://www.drupal.org/project/drupal/issues/3501727", E_USER_DEPRECATED);

I had to open up AdminNegotiator.php to see that $deprecated_service_name is a real variable holding a real class name, so that message should print out something real. 😅 However, we're passing the service to the AdminNegotiator class's __construct() method. Generally, we say something like:

Calling ' . __CLASS__ . ' constructor ...

Should we do the same here?

Merge conflicts from 🐛 TypeError: trigger_error(): Argument #2 ($error_level) must be of type int, string given in trigger_error() Active . Resolved locally and pushed.

Also, marked 🐛 Broken link in trigger_error() Active as duplicate.

This is probably RTBC.

Cool, thanks.

Yeah, I’ve run into this myself. Thanks for opening an issue about it. I agree the messaging can be improved.

Some history: when all this code was written, there was no such thing as a Drupal contrib module compatible with multiple major versions of core. The changes to core, semver for contrib, and the whole notion of conditional compatibility all evolved and were basically bolted onto update status. But we haven’t fully reworked the whole system with those new assumptions / starting points as a basis.

That said, improving the wording for this case doesn’t necessarily require a complete rewrite. I’m only providing some context for how we got here.

Duplicate with 📌 Fix deprecated messages that reference issue instead of change record. Active ? We’re fixing like 20 such links at once.

Thanks for addressing all my feedback!

I resolved nearly all of my own threads. I left 3 open that might still be viable.

The other threads are from lauriii and I don't feel comfortable resolving those.

I'm not going to formally RTBC this with 12 open threads. But it's definitely very close!

dww → created an issue.

dww → created an issue.

dww → created an issue.

Overall, looks great. Didn't super closely review every line, but a look through the MR changes seems really solid. Good test coverage. The changes all make sense.

1 concern: should we be adding CSS to stable9 for this? That gives me pause.

Otherwise, I think this is ready, or very close to it.

Thanks!
-Derek

My suggestions have all been applied. I see nothing else to improve. Pipeline is still all green. Still RTBC.

Thanks!
-Derek

In 4 years, no one has come up with a compelling reason to consider this a bug. If you opt-in to using the static ::load() method on one of your bundle classes, it's up to you to filter your IDs to match that bundle if that's the behavior you want. But changing the behavior just because some developers had magical thinking around this issue doesn't seem wise.

Mostly looks great, thanks! Tagging to be smashed.

Left a few nit suggestions on the MR, but it's RTBC either way.

I ran the test-only job, and it failed as expected:
https://git.drupalcode.org/issue/drupal-3562753/-/jobs/7699055

There was 1 error:
1) Drupal\Tests\history\Unit\HistoryTokensHooksTest::testTokenInfoWithoutCommentModuleInstalled
Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException: You have requested a non-existent service "comment.manager".

The actual fix is small, clean, and expected. The Unit test looks good, and works as advertised.

Thanks again!
-Derek

Tagged https://www.drupal.org/project/static_page/releases/8.x-1.0-rc1 → with D11 support (and other recent fixes).

Thanks for testing! Merged to 8.x-1.x.

Rebased and fixed .gitlab-ci.yml. Let's see what the bot thinks...

The blockers are all merged. This is ready to move forward again.

Merged. Thanks!

Rebased after recent merges. Fixed StaticPageSettingsForm.

I merged 📌 Fix SchemaIncompleteException in tests Active . Rebased in here to remove the schema changes that are now in 8.x-1.x. Pipeline is happy. Merged to 8.x-1.x.

Thanks, everyone!

Merged to 8.x-1.x. Thanks again!

Oh, gotcha. Sure, we can fix both in here. Thanks!

p.s. Yeah, sequence is the right approach here. That's what I was gonna do when I first saw the test failure, before I had opened your MR.

Thanks for opening this issue and providing the fix! Title that more directly describes the actual bug (the fact tests fail because of it is a side effect). I also realized we're not shipping a default config for this module, either. That's probably a good idea. Pushed commit for that. Also added a Kernel test that fails locally if I revert the schema fix.

If the pipeline is green, I'll merge this.

dww → made their first commit to this issue’s fork.

Re: #4: Slightly confused, I don't see any \Drupal:: in StaticPageSettingsForm. What else needs DI in there?

Moved the DI changes to 📌 Use dependency injection in StaticPageSubscriber Active . Rebased to latest 8.x-1.x. There's now test coverage here, removing that tag, too.

Let's see what the bot says now.

Moved the DI changes from 🐛 Revision object is returned instead of revision id due to core type upcasting change. Needs review to here. However, this is still gonna conflict with #3386719, so let's resolve that, first. Also, still need to remove the DI stuff from the phpstan baseline.

Never heard back. Closing.

Thanks for moving this forward.

1. Needs a rebase now that 📌 Enable GitLab CI for static_page Active is done and merged.
2. Needs to update the versions in .gitlab-ci.yml now that we're supporting D11. I'd make D11 the default, and move the D10 config to another manual build/test combo.
3. Will conflict with 📌 Use dependency injection in StaticPageSubscriber Active and/or 🐛 Revision object is returned instead of revision id due to core type upcasting change. Needs review , so probably best to wait for both of those to land before we do this. So for now, marking postponed.

Personally, I'd rather just fix the bug here, and do all the DI stuff at 📌 Use dependency injection in StaticPageSubscriber Active . Hopefully fairly easy to move those commits/changes to another branch.

Meanwhile, I opened 📌 Enable GitLab CI for static_page Active to add the .gitlab-ci.yml file and fix the pipelines. That's now merged. So this needs a rebase to remove that from here.

Thanks again for working on this!
-Derek

dww → created an issue.

Merged to 8.x-1.x

https://git.drupalcode.org/project/static_page/-/merge_requests/4