Deprecate .inc files

Created on 16 November 2024, 9 months ago

Problem/Motivation

Let's deprecate modules having .inc files.

Most of what is in .inc are hooks which can now be moved to classes.

Contrib will still need the LegacyHook to support both Drupal 10 and 11.1, but the main purpose was for code organization, it's less of an issue for the legacy service callback to be in a .module file.

In core hook_hook_info is used by system for tokens and those implementations can already be OOP we still need to handle system_hook_info itself.

Then views uses it as well. The core usages are:

  • datetime_type_field_views_data_helper
  • views_entity_field_label
  • views_field_default_views_data

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component

base system

Created by

πŸ‡ΊπŸ‡ΈUnited States nicxvan

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @nicxvan
  • πŸ‡ΊπŸ‡ΈUnited States nicxvan
  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    I'm not sure what the purpose of this issue is. We will deprecate the concept of autoloading inc files for hooks as part of πŸ“Œ Deprecate hook_hook_info() Active , but do we really need to do more?

    While discouraged and not really serving a purpose, if you load them manually, it's not really an issue? I think this would essentially deprecate \Drupal\Core\Extension\ModuleHandlerInterface::loadInclude(), but for that we IMHO need to get rid of .install too, which is quite a big thing and not really that urgent?

  • πŸ‡ΊπŸ‡ΈUnited States nicxvan

    Yeah, this was cause there are some wider things for deprecating hook_hook_info. This might become unnecessary though.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    There is an existing meta for replacing include files, 🌱 [META] Provide modern replacements for and deprecate the legacy include files Active

  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    That meta is for the non-module includes folder. IMHO this is either a duplicate of deprecating hook_hook_info() (which itself now is kind of a duplicate of deprecating legacy hooks) or it's a fairly-far-future deprecation of ModuleHandler::loadInclude()

  • πŸ‡ΊπŸ‡ΈUnited States nicxvan

    @berdir is mostly correct. The one additional thing I might consider here are child tasks to eliminate module .inc files.

    They used to be useful from a pure organization standpoint, but now many have just a couple preprocess functions and with the .module files so much shorter it may make sense to consolidate some.

    This title may be better called something like evaluate core .inc files in modules.

  • πŸ‡ΊπŸ‡ΈUnited States nicxvan
  • πŸ‡ΊπŸ‡ΈUnited States nicxvan
  • πŸ‡ΊπŸ‡ΈUnited States nicxvan

    I've attached two files.

    One with module and test .inc file functions
    One with core/includes .inc file functions

    I've also updated the proposed resolution.
    I'm confident we can and should do the section for helpers, the other sections I'm as convinced it's worth changing.

  • πŸ‡ΊπŸ‡ΈUnited States nicxvan

    A specific example is: _content_translation_form_language_content_settings_form_alter

    It's marked as proxied, which I don't know what the purpose of that is in this context, but that seems like it should be easily moved to:
    ContentTranslationHooks

  • πŸ‡ΊπŸ‡ΈUnited States nicxvan
Production build 0.71.5 2024