Contrib.social

[META] Improve the extension system (modules, profiles, themes)

Open on Drupal.org →
Created on 20 June 2013, almost 11 years ago
Updated 16 June 2023, 12 months ago

Postponed until 8.1.x

As nice as ModuleHandler is compared to what we used to have (nothing) it is still DX hell. The method signatures are needlessly complex, some methods are well over 200 or 300 LoC long and would definitely please people who enjoy arrow-shaped code.

Additionally, we should consider implementing a similar manager for themes (ThemeHandler) as well as for profiles (ProfileHandler) and implement the managed items as proper objects with proper interfaces (probably using some sort of ArrayCollection/ParameterBag to provide nice DX e.g. when reading from .info.yml properties).

ThemeHandler, ProfileHandler and ModuleHandler

We should add both, a ThemeHandler and a ProfileHandler and probably consider setting up some level of inheritance including proper interfaces and an abstract base class.

While we are at it we should probably provide proper classed objects for Modules, Themes and Profiles ( 📌 Add Module, Theme, Profile, and Extension value objects Needs work ).

Fix ModuleHandler

  1. ModuleHandler::install / ::uninstall are needlessly complex. Let's simplify both.

    • Currently, both methods and their procedural wrappers (@deprecated) module_install()/uninstall() each expect an array of module names. This is one of the reasons why ModuleHandler::install()/uninstall() are as gigantic as they are today. Internally, the only thing that would justify an array of modules is the post-installation hook invocation at the end of these methods which expects an array as well. But that should really not stop us. @see #2024071: Change ModuleInstallerInterface::install()/uninstall() method signature to expect single values instead of arrays. →

    • Both methods also allow uninstallation/installation of modules without looking at dependent modules (uninstallation) or module dependencies (installation). Let's remove that and always include dependencies/dependent modules. The logic for building the properly sorted dependency lists for modules should be moved into public helper methods too (things like the module overview and confirmation form also need that). @see 📌 Remove the ability to install/uninstall a module without it's dependencies/dependents Active
  2. Remove theme-related code from ModuleHandler::alter().
    The question is: Why do we invoke alter hooks in themes anyways? This should really not be allowed. Either themes are full modules or they are not. And currently they are not. However, can we introduce this API change for D8? Probably not, so what do we do instead? Do we need a ThemeHandler and an ExtensionHandler that wraps both? Anyways, it's definitely wrong to have that code in the module handler (apart from the fact that it's probably wrong to even support alter hooks in themes in the first place). The worst part about theme-level alter hooks is that whether or not they ever reach the theme depends on how early in the bootstrap they are invoked. So it's really trial- and error for a themer anyways as some of the alter hooks will simply not work in themes.
    @see #2024217: Should themes be able to implement hooks, e.g. hook_system_info_alter()? →

  3. Add a public method for retrieving properly sorted lists of modules based on the dependency tree. Needs issue
    We need this for the modules overview page and confirmation form when installing/uninstalling modules as well as the site installation batch process. Both places currently use custom code to fire module installation step by step and in the right order.

  4. Clean up the entire thing and get rid of all those function calls.

  5. Implement modules as classed objects according to 📌 Add Module, Theme, Profile, and Extension value objects Needs work .

  6. Refactor system.admin.inc and the site installation batch process to adjust to the aforementioned changes make use of the $module object properties wherever module information is being accessed once 📌 Add Module, Theme, Profile, and Extension value objects Needs work is resolved. Needs issue

  7. Refactor graph API according to #1915308: Make the graph component input an edge list and add topological sort →

Related issues

📌 Remove the ability to install/uninstall a module without it's dependencies/dependents Active
📌 Add Module, Theme, Profile, and Extension value objects Needs work
#2024071: Change ModuleInstallerInterface::install()/uninstall() method signature to expect single values instead of arrays. →
#1915308: Make the graph component input an edge list and add topological sort →
#2024217: Should themes be able to implement hooks, e.g. hook_system_info_alter()? →
#2021959: Refactor module handling responsibilities out of DrupalKernel →
#1067408: Themes do not have an installation status →
#2029819: Implement a ThemeHandler to manage themes (@see ModuleHandler) →
📌 Implement a ProfileHandler to manage profiles (@see ModuleHandler) Active

📌 Task
Status

Active

Version

11.0 🔥

Component
Extension  →

Last updated 3 days ago

No maintainer
Created by

🇦🇹Austria fubhy

Live updates comments and jobs are added and updated live.
  • Needs issue summary update

    Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.

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.69.0 2024