Contrib.social

Rename 'module_handler' service and ModuleHandler classes

Open on Drupal.org →
Created on 20 January 2013, over 12 years ago
Updated 8 June 2025, 16 days ago

Follow-up to: #1331486: Move module_invoke_*() and friends to an Extensions class →

Problem

  • "module_handler" as a service name is a bit off, since most services are "handlers".

Details

  • Just "module" would be too unspecific/generic/meaningless.
  • So what does ModuleHandler really do?
    1. It determines which module implements which hook.
    2. It invokes hooks in modules that implement them.
    3. It maintains a list of active modules that should be invoked for hooks.

    To do so, it gets the list of enabled modules injected from DrupalKernel (which reads the list from the system.module:enabled configuration). The list of modules can be overridden/mocked for special use-cases though; e.g., install.php, update.php, and tests are operating with a fixed/locked module list, which is not the configured list of enabled modules.

    There's an additional set of functionality tacked onto it:

    1. It loads .module files, in order to determine existence of hook implementations and to invoke hooks.
    2. It tracks whether all modules in the currently active module list have been loaded, so certain code that is invoking hooks are able to verify that the returned results are complete (e.g., the theme registry needs to be sure that all hook_theme() implementations are loaded in order to build the complete theme registry).
    3. It answers whether a given module "exists" — based on the currently active module list.

Proposed solution A

  1. Rename "module_handler" to "hook", and rename ModuleHandler to HookManager.
  2. Clarify or move the straw ::moduleExists() method somewhere else, and decide whether its result shouldn't be based on the configured list of enabled modules, instead of the currently active module list being used for hooks.
📌 Task
Status

Postponed

Version

11.0 🔥

Component

extension system

Created by

🇩🇪Germany sun Karlsruhe

Live updates comments and jobs are added and updated live.
  • API clean-up

    Refactors an existing API or subsystem for consistency, performance, modularization, flexibility, third-party integration, etc. May imply an API change. Frequently used during the Code Slush phase of the release cycle.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024