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 ().
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
- 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 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.
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.
- Clean up the entire thing and get rid of all those function calls.
- Implement modules as classed objects according to .
- 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 is resolved. Needs issue
- Refactor graph API according to