Problem/Motivation

Split from #3491731: [META] Remove the ability to update modules and themes via authorize.php

This issue is for 11.2.x to deprecate authorize.php, the FileTransfer classes, and the rest of the Updater classes.

See also:
#3285191: [meta] Only support Drupal core installs managed by composer
#3483501: Rename update module back to Update Status
#3253158: Add Alpha level Experimental Update Manager module

Steps to reproduce

Proposed resolution

Remaining tasks

  1. Reviews.
  2. RTBC.
  3. Commit.
  4. Rejoice.

User interface changes

Introduced terminology

API changes

All of these are now deprecated:

  1. core/authorize.php
  2. system_authorized_init()
  3. system_authorized_get_url()
  4. system_authorized_batch_processing_url()
  5. system_authorized_run()
  6. system_authorized_batch_process()
  7. core/lib/Drupal/Core/FileTransfer/*
  8. core/lib/Drupal/Core/Updater/*
  9. drupal_get_filetransfer_info()
  10. hook_filetransfer_info()
  11. hook_filetransfer_info_alter()
  12. drupal_get_updaters()
  13. hook_updater_info()
  14. hook_updater_info_alter()
  15. hook_verify_update_archive()
  16. Every method in core/modules/update/update.authorize.inc
  17. Every method in core/modules/update/update.manager.inc

Data model changes

Release notes snippet

Issue fork drupal-3502974

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

dww created an issue. See original summary.

andypost’s picture

dww’s picture

@andypost: Not sure what you're requesting in #3. That MR is for a set of changes to completely remove all this code. Instead, it'll probably be more simple to start over from scratch here, since there's now a different scope and approach needed for this issue.

But if I'm misunderstanding, please let me know.

Thanks!
-Derek

dww’s picture

Status: Active » Needs work

Opened a CR for this (to get a valid NID for deprecation messages) and started deprecating everything in the IS. Pushed commits for authorize.php and system_authorized_*(). Opened an MR. Still incomplete, so NW, but wanted to at least get this started and to see if the bot explodes in any unexpected ways. 😅

dww’s picture

I asked in #core-development in Slack, but x-posting here:

core/modules/system/tests/src/Functional/System/SystemAuthorizeTest.php is now failing since it's triggering deprecations. Can I completely remove that test as part of this issue, or do I need to convert it to expect deprecations, etc?

catch’s picture

I think @group legacy will allow the test to pass with deprecations without changing anything else about it. We have to use that on update test for similar reasons.

andypost’s picture

Maybe deprecation of hooks could be done in module handler? gonna dig it

dww’s picture

Assigned: Unassigned » dww

@andypost, see:
https://www.drupal.org/about/core/policies/core-change-policies/how-to-d...

I’m assigning myself, since I’ve got more of this done locally. Stay tuned.

dww’s picture

Issue summary: View changes

Okay, cool, that's working now.

Adding a TODO list under remaining tasks, and crossing out what's already been pushed...

dww’s picture

@andypost: Argh, what are you doing? I assigned this to myself and am actively working on it.

dww’s picture

Issue summary: View changes

Added an item to API changes for:

  • Every method in core/modules/update/update.authorize.inc

Updating remaining tasks to cross off what's done. Almost there...

dww’s picture

Title: Deprecate authorize.php and the FileTransfer system » Deprecate authorize.php, the FileTransfer and Updater systems
dww’s picture

Assigned: dww » Unassigned
Issue summary: View changes
Status: Needs work » Needs review

Added another API change point for:

  • Every method in core/modules/update/update.manager.inc

Everything is now done. Pipeline is green. Simplified remaining tasks.

This is now ready for review (both the MR and the CR). Unassigning.

Thanks!
-Derek

andypost’s picture

I'd like to set RTBC but probably exception classes needs constructor to throw deprecation...
but they are inherited so both will throw

dww’s picture

Re:

except probably exceptions need constructor to throw deprecations

From @catch via Slack:

https://drupal.slack.com/archives/C079NQPQUEN/p1741811869453559?thread_t...

catch: I don't think we have anything explicit for deprecating exceptions, but given these aren't used anywhere outside the system we're deprecating I think just @trigger_error() is fine.
dww: But then I have to add __construct() methods. 😅 Can I just do the annotation, instead?
catch: Sorry that's what I meant...

andypost’s picture

Status: Needs review » Reviewed & tested by the community

Checked usage in contrib and it could be found in DB-mocks of D7 http://codcontrib.hank.vps-private.net/search?text=UpdaterFileTransferEx...

RTBC as both code and CR looks ready

dww’s picture

Issue summary: View changes

Huzzah, thanks!

  • catch committed 3c1b4482 on 11.x
    Issue #3502974 by dww, andypost: Deprecate authorize.php, the...
catch’s picture

Status: Reviewed & tested by the community » Fixed

Given zero actual usages of those exceptions I think it's fine to add just the annotation. Everything else looks good. Ideally phpstan would ignore deprecated usages inside deprecated code but either it doesn't or it's not perfect.

Committed/pushed to 11.x, thanks!

dww’s picture

Yay, thanks! I published the CR

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.