Problem/Motivation
Split from #3491731: [META] Remove the ability to update modules and themes via authorize.php
This issue is for 12.x to (finally!) remove authorize.php, the FileTransfer classes, the rest of the Updater classes, everything in System and Update modules related to this, tests for all this code, and any stale references in docs, etc.
Note that "update.module" is slightly a lie for component, since it's also touching "base system", "system.module", etc, but it's ultimately all for the legacy "Update Manager".
At #3521059: Finish deprecating 'Update Manager' related code in Update Status we deprecate update_clear_update_disk_cache(). We stop calling it from hook_cron(), and have update_post_update_clear_disk_cache() to remove it. However, since in theory something could be calling the deprecated code directly and populating these directories, the "most complete" solution is to have another (basically duplicate) post_update in D12 once all the code paths are totally removed, too.
Steps to reproduce
Proposed resolution
- Remove everything that was deprecated in any of the related issues in D11:
- Add
update_post_update_clear_disk_cache_again()or equivalent.
Remaining tasks
Wait for 12.x branch to openRemove everythingAddupdate_post_update_clear_disk_cache_again()or equivalentDecide if we need to split this up (since the diffstat is nearly 5000 lines of code).Per @catch in #12 "Overall if we can just delete code without having to update logic, I'm (very, extremely) happy to commit thousands of lines of deletions in a single issue/MR." Split out Twig/CSS changes from core to #3571595: Remove authorize.php related Twig and CSS from coreDecide if we should remove CSS andMoved to #3571596: Remove authorize.php related Twig and CSS from stable9authorize-report.html.twigfrom thestable9theme, or leave that alone. Currently the MR doesn't touchstable9and leaves the dead code in there. Perhaps irrelevant given #3560200: [meta] Tasks to deprecate Stable 9.Decide if we should touchPer @catch in #12: "we can leave it in until the fixture is removed which will happen in 12.x too"core/modules/migrate_drupal/tests/fixtures/drupal7.phpat all as part of this. That file still references lots of stuff being removed here, but I assume we're not supposed to touch that, either.Decide what to do withRemove them. Tests still pass. They should have been removed at #2715145: Remove system.authorize config but were missed at that time.core/tests/fixtures/config_install/testing_config_install/system.authorize.ymlandcore/tests/fixtures/config_install/multilingual/system.authorize.yml.
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Issue fork drupal-3502975
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:
- 3502975-12.x-remove-legacy-update-manager
changes, plain diff MR !14627
Comments
Comment #2
dwwComment #4
dwwRe-parenting this to the more active initiative.
Comment #5
longwaveComment #6
dwwI’m going to work on this. It’s a bit more involved than the usual. And this mostly code I wrote, and would love the satisfaction of being the one to actually remove it. Please don’t work on this until I post an MR for review. Thanks!
Comment #7
kim.pepperI agree! Why is deleting code much more satisfying than writing code!? I love it. 🤣
Comment #9
dww50 files +20 −4945(includes -409 from.phpstan-baseline.php) 🎉update_post_update_clear_disk_cache_again()core/lib/Drupal/Core/Archivertoo, that's actually still in use by core/modules/config (both insrc/Form/ConfigImportForm.phpandsrc/Controller/ConfigController.php).Updated the issue summary. Ready for review!
Comment #10
dwwFound a few more references to
authorize.phpso diffstat is now:53 files +22 −4948. The additional +2 are a comment in.htaccessandcore/assets/scaffold/files/htaccessthat referencedauthorize.phpbut is otherwise still valid.Added these decisions to remaining tasks:
authorize-report.html.twigfrom thestable9theme, or leave that alone. Currently the MR doesn't touchstable9and leaves the dead code in there. Perhaps irrelevant given #3560200: [meta] Tasks to deprecate Stable 9.core/modules/migrate_drupal/tests/fixtures/drupal7.phpat all as part of this. That file still references lots of stuff being removed here, but I assume we're not supposed to touch that, either.core/tests/fixtures/config_install/testing_config_install/system.authorize.ymlandcore/tests/fixtures/config_install/multilingual/system.authorize.yml.Comment #11
dwwMinor summary cleanup.
Comment #12
catchOverall if we can just delete code without having to update logic, I'm (very, extremely) happy to commit thousands of lines of deletions in a single issue/MR.
What this means though is anything tricky we should split out - either to one issue if it's just a bit fiddly, or separate issues if it's genuinely hard to review.
On the remaining bits:
If cruft in
core/modules/migrate_drupal/tests/fixtures/drupal7.phpdoesn't break any tests, we can leave it in until the fixture is removed which will happen in 12.x too.I think it probably would be OK to remove because these are for an interface that no-one will be able to access any more, but I think we should split the CSS/template changes out to their own issue anyway and discuss it there. And possibly split that issue into two if stable9 needs discussion.
These seem like they could just go? But are tests relying on them?
Comment #13
dwwSweet, thanks!
system.authorize.ymlcopies fromcore/tests/fixtures/config_install. Bot seems happy (other than the dreadedDrupal\Tests\layout_builder\FunctionalJavascript\InlineBlockTest- re-running now).Updating summary accordingly. I believe this is now RTBC, but that's for someone else to say.
Thanks again!
-Derek
Comment #14
kim.pepperI feel like this a release highlight 😆
Comment #15
dww@kim.pepper: Thanks for your comments! Feels supportive to know other folks are watching this.
re: #7: Yeah, funny, huh? 😉 I think in cases like this, it's partly the thrill of finally being rid of something we were responsible for, the burden of supporting it all, the issues, bugs, support requests, etc. But the other part, maybe more significant, is that it was "our baby" all that time, and if someone *else* was the one to come in and rip it all out, it'd be a little bit of an ouch. Yeah, I wrote it (decades ago), and I maintained it (such as it was), and now I'm here to finally put it to rest. If that flow was interrupted, and another person finished the loop, I'd feel left out. That's my I'm-not-a-therapist diagnosis, at least. 😂
re: #14: It's a release highlight for old-timers like us, but "removed a bunch of stuff that hasn't really worked for a few years" isn't exactly highlights for 99+% of the folks reading release notes. 😅 The issues for deprecating it and removing the UI for it were already release highlights. I don't think finally removing the cruft from the codebase counts.
Relative to the total size of core, even a 5K line removal is still only a drop. But it'll be a relief to see it gone, that's for sure!
Thanks again,
-Derek
Comment #16
dwwRe remaining task #7: Was doing some git and issue archeology for another issue, and found #2715145: Remove system.authorize config. That's where
system.authorize.ymlwas removed. Looks like we missed those test fixture files at that time. But yeah, clearly, this is very dead code, and should finally be put to rest.Comment #17
catchFor release highlights, maybe we could have something about net lines of code removed between 11.4 and 12.0, or between 11.3 and 12.0 would match how https://dbuytaert.github.io/drupal-core-metrics/ keeps track.
For comparison, Drupal 9.0 looks like it removed about 7,000 net lines of code (8 minor releases of Drupal 8 deprecations to delete).
Drupal 10.0.0 removed more or less zero (possibly because we added a couple of new things like views responsive grid?)
Drupal 11.0.0 removed about net 3,000.
Comment #18
longwaveThis is great cleanup! SystemHooks still has a now-obsolete hook:
Otherwise I can only find the theme layer related bits remaining, they can go in the followups.
Comment #19
dww@catch re: #17: That sounds good, and more highlightable.
@longwave re: #18: Nice find! Dang, I thought I had grep'ed for all that, but I guess I missed that one. Pushed a commit for it.
GitLab seems weird these days. It keeps claiming a merge is blocked by a non-fastforward. But when I rebase, there aren't conflicts. This has happened multiple times in the last few days on multiple issues. I don't remember this being a thing until recently. But I rebased again, just in case.
Thanks!
-Derek
Comment #20
longwave@dww yeah that seems like a recent change in GitLab, it says the merge is blocked unless it is rebased onto HEAD. But the committers don't use merges anyway, so as long as it doesn't explicitly say there's a merge conflict, you are all good.
Comment #21
dwwFYI that I put the remaining 5 deprecated functions in update.module into a separate issue for better scoping: #3571860: [12.x] Remove deprecated template_preprocess functions from update.module. That's also ready for review. With both branches merged locally, there are no longer any hits for 'deprecate' in core/modules/update/*.
Comment #22
smustgrave commentedVery nice work @dww! Serious rabbit hole of stuff.
I applied the MR and did a search for deprecated and 12.0.0 and believe all instances have been removed.
Comment #23
catchSorry this needs a rebase. I think because the preprocess removal landed.
Comment #24
dwwRebased. Trivial merge conflict resolved (both branches removing unused use statements next to each other). Let's see what the bot thinks.
Comment #25
dwwRandom fails (including a Functional random in package_manager? and the dreaded InlineBlockTest), but green pipeline now. Gonna go ahead and self-RTBC in this case.
Thanks!
-Derek
Comment #26
dwwComment #28
longwaveGoodbye, Update Manager!
Committed and pushed 09985a50b2b to main. Thanks!