Finish deprecating 'Update Manager' related code in Update Status

Thanks! Applied suggestions. Leaving the thread about moving the test into a new class open to see if anyone else has a strong opinion.

There are no failures. The failure was the pipeline never started. Longwave and Drumm seem to have sorted it out.
I’ll push a no-op commit to hopefully trigger a new pipeline.

Yay, the pipeline really ran. However, there seem to be failures, after all. 😂 I’ll look more closely when I’m at my laptop.

Was calling the deprecated method from hook cron, which caused any tests that enable update.module and invoke cron to trigger deprecation notices. Removed that from cron, and now the pipeline is all green. Back to NR.

All the new deprecations reference the CR from the parent issue. If we’re happy and this lands, I’ll update that CR to mention these other deprecations. Assuming this ships in 11.2, seemed silly to use a separate CR for it. See the parent issue and linked CR for more.

Thanks!
-Derek

p.s. This specific disk cache cleanup method is only cleaning up a cache of tarballs downloaded for the deprecated and removed “Update Manager” stuff. So nothing would be populating this cache, so no need to garbage collect it.

To make #11 explicit, adding the tag. I hereby solemnly swear to make the updates once this is committed...

Added a remaining task, probably for release managers:

Decide if we should explicitly mark the allow_authorize_operations setting itself deprecated in sites/default/default.settings.php and core/assets/scaffold/files/default.settings.php

Added a few more remaining tasks for decisions, and tagging for release manager review.

Per @berdir in Slack, #3518822: Convert template preprocess hooks in core/includes/theme.inc is related. We also forgot the authorize-report template and preprocess. I pushed 2 commits for those, 1 to properly deprecate the template and preprocess, and another to add @deprecated comments to authorize-report.twig.html files (both system and stable9). Can revert the last one if that's not desirable for some reason.

Add authorize-report to summary, and move the list of deprecations to the API changes section.

That's 2 votes in favor of a new CR for this issue. Created https://www.drupal.org/node/3522119 and moved all the deprecations to point there. Removing the tag.

Noticed I also missed _update_manager_unique_identifier(). That's not used for the fetch URL to be able to aggregate anonymous usage stats per site. It's only used for the name of the disk cache subdirectories.

Re #23: see #3502975: Remove all legacy code related to authorize.php and FileTransfer from 2 parent issues up. Yeah, we probably don’t *need* to deprecate all of this, but it seems safer to be complete at this point.

I'm not convinced the post_update() needs to be in 12.0. We've already removed all the UI that could trigger any of the code paths that put files in these temp directories. Some of that shipped in a previous release, the rest will be in 11.2.0. Can't we have a post_update() in 11.2 itself that removes these directories? Why leave them around for years? We mention cleaning them out at the CR. Probably also would in release notes. Why wait another major release for a post_update() to automate that? Once a site is running 11.2.0 or higher, nothing could be populating these directories unless we now believe there are contribs or custom code out there using any of this plumbing. Seems like those folks are on their own, and can be responsible for removing the directories again when they're really done.

But core will already be done the moment we're on 11.2.0. So if we're going to do a post_update() at all, seems best to do it right here in this issue.

Meanwhile, any release manager thoughts on remaining task #1: allow_authorize_operations setting?

Thanks!
-Derek

Re point #1: allow_authorize_operations setting:

My proposal would be to remove it from the default.settings.php files for new sites, but not formally "deprecate" the setting and generate warnings if sites have used it to opt-out of the Update Manager already. No real harm in leaving it in settings.php files, even if it's being ignored, right?

Maybe that is worth a D12 follow-up to formally deprecate the setting and trigger warnings about still having it defined?

Per Slack discussion with @nicxvan, decided to:

• Add update_post_update_clear_disk_cache() here to clean out the cache already. Then we don't have to mention that in any release notes. Updated the CR accordingly.
• Added a note to #3502975: Remove all legacy code related to authorize.php and FileTransfer about a duplicate post_update in D12 once all the code is also gone, just in case.
• Remove allow_authorize_operations from default.settings.php.

I'm reluctant to already deprecate the setting. In theory, if any contrib or custom code is still using any of the deprecated code paths, the allow_authorize_operations killswitch still might be validly preventing weirdness. So we don't want people to remove that from their settings.php files until all the code that it kills is already dead and gone. Wearing my former security team hat, any site that already used $settings['allow_authorize_operations'] = FALSE; gets a gold star for wanting to manage their site code in a better way. I don't want to nag them to remove that killswitch until we're absolutely sure nothing is relying on it.

Great, thanks! Crossed 1 off the remaining tasks.

Last point that needs a decision is remaining task 4:

Decide if update_post_update_clear_disk_cache() needs automated tests.

Then I think a release manager can remove the “ Needs release manager review” tag and this could be RTBC.

Thanks!
-Derek

Great, thanks again!

Fantastic, thanks!

I published the CR. I also added a note to the 1st Update Manager deprecation CR to link to this CR.

Glad this landed so we can cleanly remove all this stuff once 12.x is open. 🎉

Thanks again!
-Derek