Add Alpha level Experimental Update Manager module

After discussion in Slack with @tedbow and @AaronMcHale, I removed the hidden: true flag from Package Manager's info file. By doing this, we won't need to change existing core tests to make this merge request green.

Here's the discussion from Slack, for reference:

phenaproxima
@tedbow InstallUninstallTest is a tricky question. The fix is easy, but the question I think we need to figure out is: should we just build some workarounds into InstallUninstallTest, or should we actually change it in such a way that it respects hidden modules as dependencies?

tedbow
We could a work around with stable blocking follow up

phenaproxima
++

Aaron McHale
Hello, quick question, is Package Manager always enabled, or is it only enabled when a required module needs it, like auto updates?

phenaproxima
The latter

Aaron McHale
Okay, so if I install auto updates, it prompts me to install package manager, if I uninstall auto updates, then I have no way to uninstall package manager if it's hidden?

phenaproxima
Hmmm, I guess you’re right, if the module uninstall page doesn’t show hidden modules

Aaron McHale
Personally, I'd want the control of being able to uninstall it, should I need to

phenaproxima
I guess that’d require us to un-hide it. @tedbow, thoughts?

phenaproxima
I think it might just be easier to un-hide it, in all honesty. Even if someone enables it on its own…so what? It’s harmless.

tedbow
Think this points to just a general problem with hidden modules. They should be uninstalled when the last module that depends on them is uninstalled
I think

tedbow
I think I'm hiding it is just going to lead to confusion

tedbow
This is a pre-existing problem for any hidden module

Aaron McHale
I feel like the whole ideal of hidden modules is counterintuitive, but that's a wider discussion than this thread

tedbow
Well I guess we kind of overload hidden and API only modules.

tedbow
Package manager is an API only module. But test modules are hidden but not API only

tedbow
Seems we need API Only in yml.info . Basically hidden and uninstall if no more dependents

Aaron McHale
Maybe instead of hidden modules, we should have test-only modules, since that appears to be the primary use-case for it. There's no reason to enable a test-only module outside of a test environment, but a module like package manager is enabled outside of a test environment, in production even, so as a site administrator, I'd probably want to know it exists

Aaron McHale
Yeah or api-only

tedbow
Or both and deprecate hidden

phenaproxima
@tedbow So for our immediate problem…maybe just un-hide Package Manager?

phenaproxima
I think that if we did that, the core MR would just pass.

phenaproxima
Without any changes to existing tests. And then we can have another issue to deal with this hidden-module nonsense

tedbow
Ok unhide for now

phenaproxima
On it.

Crediting @kunal.sachdev for contributions in the contrib version of this module.

The issue summary explains lots of technicalities about how the MR is produced, but not what the module is doing, the features, ie. why would this module be added to core. Is there another place where this is explained? Screenshots would also help to asses the extent of this issue as well as use for promoting it for review. Also, tips as to what to review would help in getting reviews.

Also adding release manager tag, since that was already in the issue summary as a list item.

Might be good to also do a final UX review before this is committed.

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 #3316617: Add a validator to check that PHP-TUF's Composer integration is present and configured correctly 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 #3346707: Add Alpha level Experimental Package Manager module.

#3316617: Add a validator to check that PHP-TUF's Composer integration is present and configured correctly landed, so this now has only one blocker, #3346707: Add Alpha level Experimental Package Manager module, though that issue has several (see the top section of #3319030: Drupal Core Roadmap for Package Manager and Update Manager 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.

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

#3319030: Drupal Core Roadmap for Package Manager and Update Manager is now linked from the issue summary (it wasn't before), but it's not very scannable to see e.g. that #3392196: Exceptions in batch no longer are shown on the page when Javascript is disabled 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.

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.

#3346707: Add Alpha level Experimental Package Manager module 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.

The secondary and even longer term reason is that some point we may want to merge or otherwise clarify the relationship between update status and update manager. In HEAD update status includes 'update manager' tarball support which is very much deprecated and confuses things even further, but without that, one gives you statuses about updates, and one manages the updates - it's not too bad considering the somewhat crowded namespace area with package_manager and project_browser on top.

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 #3483501: Rename update module back to Update Status.

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.

#3417136: Remove adding an extension via a URL 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 #3491731: [META] Remove the ability to update modules and themes via authorize.php.

Update: both #3483501: Rename update module back to Update Status and #3491731: [META] Remove the ability to update modules and themes via authorize.php are now done, in time for 11.2.0-alpha1. So there's nothing in the legacy "Update Manager" to worry about for moving this forward.