Postponed until 8.1.x
📌 [META] Improve the extension system (modules, profiles, themes) Active
Currently it is possible to install a module without installing a dependency. Installing a module without its dependencies is dangerous as it potentially leaves your site in a broken state where module B tries to invoke code or use objects from module A which either does not exist in the first place or lies there, inactivated, without it's code included and without it being registered with the classloader. The same is true for uninstalling modules without uninstalling dependent modules beforehand which is equally risky.
To me it looks like we added this feature for things like allowing the site installation batch process to cleanly install modules one by one without the risk of timeouts. Another place where we currently use it is the modules page submit handler where we handle dependencies, version miss-matches, etc. outside of ModuleHandler, basically duplicating half of what ModuleHandler already does anyways. This adds even more weight to the already hardly maintainable code around module installation, uninstallation, etc. and from a first glance it doesn't look like anyone touched that code in years. Other than that, it is only used in tests.
Let's remove it and refactor our site installation batch and the modules page submit handler to rely on ModuleHandler for building the dependency tree and installation order for modules.
This can be solved by retrieving the module dependency tree as a properly sorted list through ModuleHandler and then incrementally installing them one by one.
We still want to show a confirmation form if a module was selected for installation that has currently uninstalled dependencies (same with uninstallation). The actual installation and dependency management and sorting should happen in ModuleHandler though allowing us to remove about 50% of the code from the submit handler and moving some parts into the ModuleHandler (like version validation/miss-match detection or sorting based on dependencies which we currently lack interface methods for on ModuleHandler).
We should probably clean up and extend ModuleHandler beforehand so the patch for removing the '(un)install without dependencies/dependents" patch does not get any bigger than it has to.
None.
Removing $install_dependencies/$uninstall_dependents from ModuleHandler::install()/ModuleHandler::uninstall().
TBD
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
