Drupal 11.5 Deprecates '.module' Files Before Drupal 13 Removal

Drupal core is deprecating the .module file extension in the 11.5 development line, beginning a transition that ends with Drupal 13 no longer loading those files automatically. The published change record directs module maintainers to move hooks and other procedural logic into object-oriented replacements rather than treating the change as a removal of Drupal's hook system.

Most hook implementations can move into classes using Drupal's #[Hook] attribute. Object-oriented hook support has been available since Drupal 11.1, allowing hook methods to live in autowired classes instead of specially named procedural functions inside a .module file. A hook keeps the arguments expected by Drupal, but its implementation moves into a class under the module's src/Hook structure.

The conversion extends beyond hook functions. The change record says hook helper functions should generally move to utility services or methods on the hook class that uses them, while other procedural functions should move to services. Public functions that other projects may call need more care: maintainers are advised to deprecate those functions and have them delegate to their replacements when backwards compatibility is required.

Several hooks need specialised migration paths instead of a direct #[Hook] conversion. The change record points separately to replacements for hook_requirements() during install, update and runtime phases, for template_preprocess_HOOK through theme hook callbacks, and for hook ordering or removal previously handled through hook_module_implements_alter(). hook_hook_info() is removed in Drupal 12.

Drupal provides automation for part of the conversion. The change record links to a Rector rule with a DDEV helper script that can convert hooks carrying the expected documentation, while the conversion documentation warns that the scripts are not perfect and can miss functions. Manual review therefore remains part of the migration.

The guidance also recommends setting a module's minimum version requirement to Drupal 11.3.0 where possible because that simplifies the conversion path. Projects that still support earlier Drupal versions need to account for backwards compatibility separately.

The #[ExtensionFileIsConverted] attribute addresses one part of that compatibility work. Maintainers can use it to suppress the upcoming deprecation message after a .module file has been fully converted but must remain for backwards compatibility. The attribute does not keep the file loadable in Drupal 13; automatic loading still ends there.

Drupal also documents #[LegacyHook] for procedural implementations that forward calls to class-based replacements while preventing newer Drupal versions from invoking both implementations. That gives maintainers a bridge when one codebase has to support versions on both sides of the object-oriented hook transition.

The same direction applies to themes. Drupal separately deprecated the .theme file extension for the 11.5 line after object-oriented hook support for themes arrived in Drupal 11.3. Like .module files, .theme files are scheduled to stop loading automatically in Drupal 13.

Core itself has also been removing remaining procedural extension-file logic. That work is related to the deprecation, but it is a separate cleanup process from the migration that contributed and custom module maintainers now need to plan.

For maintainers, the immediate task is not to delete every .module file. It is to identify which hooks can move directly into classes, which helpers belong in services or methods, which special hooks need dedicated replacements, and which public procedural functions still require compatibility layers. Drupal 13 is the hard boundary, while the 11.5 deprecation provides the migration window.