Postponed until 8.1.x

Parent issue

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

Problem/Motivation

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.

Proposed resolution

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.

Site installation

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.

Modules page

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).

Remaining tasks

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.

User interface changes

None.

API changes

Removing $install_dependencies/$uninstall_dependents from ModuleHandler::install()/ModuleHandler::uninstall().

TBD

Comments

fubhy’s picture

fubhy CreditAttribution: fubhy commented

The fact that we support this just shows that the code where we use it is broken.

Just take the installer as an example. It uses this to make sure that, during the batch, we install our modules one at a time. If we had a proper, sorted graph we would not even need that as we could just retrieve that graph from the ModuleHandler and then iterate over it one by one. By that we would ensure that we never install a module for which we still need to install dependencies. Ensuring that would be the job of the graph. Problem solved.

fubhy’s picture

fubhy CreditAttribution: fubhy commented
Issue summary: View changes

Updated issue summary.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented
Component: install system » extension system
filijonka’s picture

filijonka CreditAttribution: filijonka commented
Version: 8.0.x-dev » 8.1.x-dev
Issue summary: View changes
Status: Active » Postponed

Postponing this to 8.1.x since META has been changed to that and also there are API chnages which isn't allowed during BETA phase per https://www.drupal.org/core/beta-changes

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

Changing the API to remove this capability isn't likely on the table for Drupal 8 at this point, right?

But refactoring the code to do things differently (and/or providing alternate ways to do it) seems like it could get into 8.1.x. However, need to make sure not to kill performance... recalculating the dependency tree every time a new module is installed can be wasteful if you already know the dependency tree.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost as a volunteer and at Skilld commented
Status: Postponed » Active
Parent issue: » #2024083: [META] Improve the extension system (modules, profiles, themes)

no reason to postpone

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.