Contrib.social

Rename 'module_handler' service and ModuleHandler classes

Open on Drupal.org →
Created on 20 January 2013, almost 13 years ago
Updated 8 June 2025, 5 months 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.

  • Comment 5 months ago →
    🇺🇸United States nicxvan
  • Comment 4 months ago →
    🇺🇸United States nicxvan

    This has been postponed for 10 years.

    I'm not sure this is worth doing, I'll leave this pmni for a few months in case someone wants to revive this.

  • Status changed to Closed: won't fix 25 days ago
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024