Change record status: 
Project: 
Introduced in branch: 
8.x
Introduced in version: 
8.0
Description: 

The disabled module state was a very confusing state for Drupal core. Although the data of modules (for example fields, settings, etc) is not removed, the data may or may not be updated with update hooks and processes and may or may not be used by runtime tools. Some systems (such as fields) had the notion of disabled fields to trickle this down, or views has handlers that may be optional if the module is not installed/enabled to handle them. However most other systems in Drupal did not have solutions to handle "disabled data" and introducing such solutions would have been solving this problem the wrong way.

This situation may lead to data integrity problems and the system may move to an unpredictable state. Therefore in Drupal 8, modules cannot be disabled anymore. Modules are now either installed or uninstalled.

API changes

  • Completely removed the concept of disabled modules.
  • system.module.disabled config was removed.
  • module_enable() was deprecated and now does an install.
  • module_disable() was removed as it does not make sense to change this to the destructive operation of uninstalling modules.
  • All usages of module_enable() and module_disable() are removed from core.
  • module_uninstall() was deprecated but core usages are left to be converted in a followup (this is less confusing than module_enable() and module_disable()).
  • moduleHandler::enable() and moduleHandler::disable() are removed.
  • \Drupal::service('module_handler')->install() was added.
  • The following hooks are removed:
    • hook_modules_preenable()
    • hook_enable()
    • hook_modules_enabled()
    • hook_disable()
    • hook_modules_disabled()
    • hook_modules_preinstall()
  • The following hooks are added:
    • hook_module_preuninstall()
    • hook_module_preinstall()

The change from invoking hook_modules_preinstall() with a list of modules to invoking hook_module_preinstall() with single module is so that we can guarantee the environment that will be running when the preinstall action is fired before installing a particular module. For example if both taxonomy and forum are being installed this change means that you now know that the taxonomy will be installed when the hook fires for the forum module - which is a good thing because taxonomy is a dependency for forum.

In order to explore the ability to disable modules the contrib module https://drupal.org/project/disable_modules has been created

Updating contrib code

Functions

  • module_enable(array('mymodule')) becomes \Drupal::service('module_installer')->install(array('mymodule'), $enable_dependencies)
  • module_disable(array('mymodule')) should be removed.
  • module_uninstall(array('mymodule')) becomes \Drupal::service('module_installer')->uninstall(array('mymodule'), $enable_dependencies)

Hooks

  • hook_enable() functionality should be moved to hook_install()
  • hook_modules_enabled($modules) functionality should be moved to hook_modules_installed($modules)
  • hook_disable() functionality should be moved to hook_uninstall()
  • hook_modules_disabled($modules) functionality should be moved to hook_modules_uninstalled($modules) or hook_module_preuninstall($module) (note per module not a list)
  • hook_modules_preenable($modules) functionality should be moved to hook_modules_installed($modules) or hook_module_preinstall($module) (note per module not a list)
  • hook_modules_preinstall($modules) functionality should be moved to hook_module_preinstall($module) (note per module not a list)

In a related note, themes are still being fixed so they have an installation status similar to modules. See #1067408: Themes do not have an installation status.

Impacts: 
Site builders, administrators, editors
Module developers
Updates Done (doc team, etc.)
Online documentation: 
Not done
Theming guide: 
Not done
Module developer documentation: 
Not done
Examples project: 
Not done
Coder Review: 
Not done
Coder Upgrade: 
Not done
Other: 
Other updates done