Problem/Motivation
Install profiles specify modules to install as dependencies[]. These are not enforced as hard dependencies though and can be disabled. (
#808162: update.php fails when optional modules disabled →
for background). If a distribution wants to keep the install profile module around, tough luck. There's no mechanism right now to discern between "the install profile module is recommended" and "the install profile module is required to make the distribution work". This limits distrbutions as for the latter purpose another module needs to be maintained, confusing users and making the life of the distribution maintainer harder.
Proposed resolution
-Convert dependencies[] to hard requirements for install profiles.
-Removes all special casing that undoes it
-Ensure dependencies[] behaves the same for modules and install profiles
-Introduce support for recommends[]. This will install any module that is available in the modules system (just as dependencies[] does) but these modules can later be disabled/uninstalled. (Note: If a user git clones an install profile the dependencies will not be downloaded and this could lead to errors during install if dependencies were not downloaded. See comment #39)
Remaining tasks
-Re-roll patch in #26 replacing modules for recommends
-Add recommends[] support to module_enable()
User interface changes
-Add indicator in the UI to show that x module recommends y module.
Original report by catch
Install profiles specify modules to install alongside them as dependencies[], however they're generally not enforced as hard dependencies, see
#808162: update.php fails when optional modules disabled →
and linked issues for background.
To fix this, we need to
* ensure that install profile dependencies are shown on admin/modules (note:
#293223: Roll back "Hide required core modules" →
has been committed)
* update the core install profiles to always use hook_enable()
* document the API change for existing contrib profiles.
When the original patch went in, the idea was to use .info files to gather dependencies for Drupal.org packaging, however as far as I know this now uses .make files, so it shouldn't affect that at all, although it'd be good to have that confirmed, I've only half-followed the packaging work.
**Summary built from comments by catch in #37 and David_Rothstein in #39.
