Add Alpha level Experimental Automatic Updates module

The Needs Review Queue Bot → tested this issue. It either no longer applies to Drupal core, or fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Because Automatic Updates needs a comprehensive review, including a security review. But that means drupal.org's PHP-TUF support needs to be deployed, otherwise core committers would need to do multiple security review rounds: once for the Automatic Updates module, once for the d.o PHP-TUF support.

Follow 📌 Add a validator to check that PHP-TUF's Composer integration is present and configured correctly Fixed if you want to be notified of when that is ready.

This is why the decision was made to aim to first land Package Manager (which provides the necessary infrastructure for Automatic Updates) as alpha-experimental in ✨ Add Alpha level Experimental Package Manager module Needs review .

📌 Add a validator to check that PHP-TUF's Composer integration is present and configured correctly Fixed landed, so this now has only one blocker, ✨ Add Alpha level Experimental Package Manager module Needs review , though that issue has several (see the top section of 🌱 Drupal 10 Core Roadmap for Automatic Updates Active for details).

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The current merge request is not up-to-date with the work in the contrib module

There is automated script to convert module it but it is still a fair amount of work. For this reason and because we aren't actually getting reviews, nobody outside of the team working on the contrib module has commented since February, I am going stop running conversions.

If you want to review the code I would suggest reviewing the contrib module which the MR here has always been a automated conversion of. https://www.drupal.org/project/automatic_updates →

When core reviewers have time especially the product, release and framework managers and if you would like to review the module here instead of the contrib module please contact me or comment here and I can run the conversion again.

I tempted to postpone but I won't for now

It's hard to tell from the issue summary what work is remaining before AU is ready for alpha commit.

🌱 Drupal 10 Core Roadmap for Automatic Updates Active is now linked from the issue summary (it wasn't before), but it's not very scannable to see e.g. that 🐛 Exceptions in batch no longer are shown on the page when Javascript is disabled Needs work is blocking - I think it would be help to link those issues directly here - especially ones that will require changes to AU code but also any core bugs that aren't specific to AU.

The MR is green again, should this be needs review? If not, what is blocking a review here?

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

Pushing up the new conversion.

I do expect \Drupal\Tests\package_manager\Kernel\StageBaseTest::testDestroyDuringApply to fail. There is some serialization problem that is not happening the contrib module against 11.x. Not sure why

But I think it is still reviewable

Added screenshots

Removing "[PP-1] " not postponed as far as reviewing. ✨ Add Alpha level Experimental Package Manager module Needs review still needs to be committed first

Issue summary clean-up

1. Change 3.0.x to 3.1.x
2. Mention 🌱 [policy, no patch] Drop support for Windows in production Needs review as reason not support background updates on Windows

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

✨ Add Alpha level Experimental Package Manager module Needs review is in.

At and after DrupalCon Barcelona, we discussed that instead of renaming 'Automatic updates' to 'auto_updates' for core, we should instead rename it to 'Update Manager'. The main reason for this was that a lot of experienced developers are sceptical about 'automatic updates' in the sense of unattended, and might not even look at this if they assume all it does. But the module also does 'attended updates' which will run the various composer commands locally, and then developers can commit composer.lock changes and deploy from their without anything automatic happening on production. Update manager is more neutral from that standpoint.

Update manager+++

Update Manager sounds good and is in line with the rest of the core and contrib features in this area. Also with Package Manager.

+1 to not calling the new thing “auto”. Side note, +1 to make it so it can be configured to only update when a human says so, and never “automatically”.

However, for what it’s worth, “Update Manager” is already the human name for update.module in core. Once upon it time (D5 contrib) it was called “Update status”. When moved into core in D6, Dries wanted it called “Update Manager” since he had dreams of it actually updating your site. Those dreams were (partially) realized in D7 when we added all the authorize.php stuff and contrib updating. The machine name is still only update, but help text, .info.yml name, and reams of documentation and countless issues & comments all call it “Update manager”.

So, if we go forward calling the renamed auto_updates “Update manager”, we have to pick from:

1. We’re okay calling two different modules with different responsibilities the same thing. 😬
2. We should rename update.module back to “Update status” in UI text and documentation (#NeedsFollowup). Once this lands, and we finish ripping out the authorize.php parts, providing “status” is all update.module will be responsible for again.
3. Or we pick a different new name for auto-updates.

To vote on my own poll from the previous comment, I’m totally fine with option #2 and changing the human readable name of update.module back to “Update status”, add CR and release notes, fix documentation, and hope for the best that it won’t be too confusing. But I don’t personally have time or any funding to do all that work myself. so if y’all decide that’s best, I’d appreciate some help getting it all done. Thanks!

Indeed, good point! I think renaming the existing one's human readable name back to Update Status is a good way forward. Internally it reflects that naming already.

Option #2 sounds good. I know the authorize.php-related stuff was called update manager, but completely missed that was the human readable module name too.

https://git.drupalcode.org/project/drupal/-/blob/11.x/core/modules/updat...

name: 'Update Manager'
type: module
description: 'Checks for updates and allows users to manage them through a user interface.'
…

Opened 📌 Rename update module back to Update Status Active .

I opened an MR to get started on #3483501, but there are a bunch of open questions in the issue for release and/or framework managers to weigh in on. Thanks!

what is a fate of authorize.php as it looks not deprecated yet?

@andypost we need an issue to deprecate it, I thought there already is one, but I can't find it.

📌 Remove adding an extension via a URL Fixed removed installation via URL but not updates.

See #3483501-5: Rename update module back to Update Status → where I asked similar.

Tried and failed again to find an existing issue, so I went ahead and opened 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active .