Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Updated: Comment #6
Problem/Motivation
user_cancel_methods() defines several methods for canceling a user account.
There is no info hook, but there is an alter.
This would imply that allow a module to provide its own methods, but they cannot as these are then checked in _user_cancel(), and actual code is run from there only.
These constitute a good chunk of procedural code left in user.module, and in issues like #1946466: Convert all confirm_form() in user.module and user.pages.inc to the new form interface and convert route, they are called from within a class.
Proposed resolution
Provide a UserCancellation plugin type
Remaining tasks
Decide if this is a good idea
User interface changes
N/A
API changes
This could potentially be done with no API break. It would be a pure API addition
Related Issues
Original report by @tim.plunkett
#1946466: Convert all confirm_form() in user.module and user.pages.inc to the new form interface and convert route moves user_cancel_methods() from user.pages.inc to user.module, but we need a better solution.
catch jokingly suggested plugins, but that's not as crazy as it sounds.
It's essentially an info hook, it has an alter, and _user_cancel() provides functionality for each of the different methods.
Comments
Comment #1
Crell CreditAttribution: Crell commentedWeird as it sounds, either plugins or a chain-of-responsibility set of services seem like a decent fit in the new model. As Tim notes, it's badly implemented info hook with one method for each thingie defined. The one caveat is that plugins, AFAIK, assumes you will be instantiating something. There's really nothing to configure/instantiate here, is there? It's a global setting, and we've not been using plugins for most of those, just services and a facade object.
Comment #2
tim.plunkettIf we moved it to proper plugins, contrib could provide new ways to cancel an account, or tweak/replace existing ones.
Comment #3
dawehnerAs far as I understand you currenlty extend the behavior by implement hook_user_cancel_methods_alter and hook_user_cancel
This will be replaced by a plugin system which can register new items in the batch and then call arbitrary methods while running the batch. A service based approach seems not really needed.
Comment #4
Crell CreditAttribution: Crell commenteddawehner: I usually argue that a plugins approach is not needed, as the service-based one has fewer moving parts. :-) But more to the point, does the lack of instantiation mean it doesn't fit the Plugins model?
Comment #5
dawehnerI personally think that a service matches everything you want to be able to reuse a certain component in potential multiple places which is probably not the case for user cancel?
Comment #6
tim.plunkettI think instantiation will be needed? Each of those methods corresponds to some functional code in _user_cancel(), those would be a method on the class...
I will update the issue summary, but I'm not jumping into coding this until it has more committer feedback.
Comment #6.0
tim.plunkettUpdated
Comment #7
tim.plunkettComment #8
tim.plunkettComment #16
joachim CreditAttribution: joachim as a volunteer commented> But more to the point, does the lack of instantiation mean it doesn't fit the Plugins model?
One case for plugins is that the user cancellation methods are something that need to be listed and selectable in the admin UI.
> I will update the issue summary, but I'm not jumping into coding this until it has more committer feedback.
Tagging for that.
Comment #19
andypostThere's better patch in #3043725: Provide a Entity Handler for user cancelation
So #3079085: Move user cancellation functions to a service could be close with this one
Comment #20
phenaproximaI agree that this can be closed out. Since this issue predates Drupal 8.0.0, but never really got off the ground, I'm not going to bother transferring credit (but happy to do that if someone feels it would be appropriate).