1

Uninstalling my module threw this error:

[error] my_module: The My Field field type is used in the following field: my_module.my_field

But, since my module defines both an entity and a field, both of which will be uninstalled when I uninstall this module, it doesn't make sense. I'm trying to handle this by removing all of the fields programmatically in hook_module_preuninstall, which I have in the .module file because it wasn't working in the .install file.

The problem is, this hook runs after the checks for field dependencies. It would make more sense if it ran before, in my opinion, but, what can I use to get ahead of these checks? Anything? If not, what should I do so that my module realizes it needs to uninstall these things when the module is uninstalled?

Also, shouldn't this hook run earlier? If not, what is the point of it?

Improve this question
1
  • You could also decorate the module_installer service and override the ::uninstall() method. Execute your code prior to the parent::uninstall($module_list, $uninstall_dependents) call. I used this method to overcome a similar problem. See previousnext.com.au/blog/decorated-services-drupal-8
    – Beau
    Commented Sep 24, 2019 at 16:02

1 Answer 1

Reset to default
2

Yes, there is currently no hook to do this.

The only thing you can do is have your own custom uninstall form that allows you to prepare the uninstall by deleting all data and then delete the field through the API, then point the user to the uninstall form.

Improve this answer
5
  • Okay, thank you. Don't you think there should be? Is there any use for hook_module_preuninstall the way it is?
    – RaisinBranCrunch
    Commented Aug 23, 2017 at 14:54
  • Yes, that hook is really not very useful, it was added before config dependencies were. I suggest you look for or create an issue and a patch, should not be too hard to the hook up. The challenge I guess is what if your preuninstall hook runs, you delete something, and then there is still a validation problem? Then your module might be in a broken state (the same is true for my approach, though)
    – Berdir
    Commented Aug 23, 2017 at 19:04
  • It looks like, if I'm reading it right, this issue: drupal.org/node/2350111 will create an onModuleUninstall event which I can subscribe to, which will hopefully happen before the config dependencies are checked?
    – RaisinBranCrunch
    Commented Aug 23, 2017 at 19:22
  • And, if I were to make a patch, which Drupal version should I use? 8.3.7? 8.4.x? 8.5.x?
    – RaisinBranCrunch
    Commented Aug 23, 2017 at 19:37
  • Don't worry about that, that's usually easy to change and is for the release manager to decide. Depends on whether it is classified as a bugfix, feature or something inbetween.
    – Berdir
    Commented Aug 23, 2017 at 22:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.