- 🇺🇸United States dww
If you intend to rely on the FileTranfser classes to do this, and you actually think that could still work, you need to speak up (quickly?) in 📌 Deprecate/remove the ability to update a module from a URL and authorize.php Active . The current MR there completely removes that entire API (along with authorize.php and related methods from system.module). Everyone (so far) thinks it’s legacy cruft that no one could possibly care about anymore and doesn’t even deserve to be deprecated before removal. 😅
I’m extremely familiar with the goal of UI-based updates for sites configured in depth. I have championed that approach since D6, and wrote the bulk of this code in the first place. You don’t have to explain to me how it works or why in principle it’s a good idea.
However, I’m no longer convinced that any site with httpd running as another user than the one who owns the files will be maintained by someone who is CLI averse. It’s only wild speculation, but my sense is the intersection of those two sets is vanishingly small, and not worth bogging down core with technical debt to support.
It’s absolutely worth making the UI play nicely with a cron-driven “sudo” step. That’s already been done. But actually requiring manually logging in via FileTransfer directly as part of the UI seems unnecessary.
- 🇺🇸United States dww
For clarity, the “cron-driven sudo” step that’s already supported is not via Drupal’s hook cron, which “might be triggered by any user”. I/we are talking about good ole *nix crontab, and specifically setting up the script completely outside of Drupal.