Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Enhances an existing API or introduces a new subsystem. Depending on the size and impact, possibly backportable to earlier major versions.
Needs backport to D7
After being applied to the 8.x branch, it should be considered for backport to the 7.x branch. Note: This tag should generally remain even after the backport has been written, approved, and committed.
Seems like there's a few ideas floating around that hint at roughly the same "ideas". However, I'm not entirely sure, at this point, whether this is indeed a duplication.
The other issues seem to be more focused on the "suggest install" idea (like: "hey, you might like this module too"). This is about ensuring "peer dependencies" are also always installed, just after (not before like it currently is: a requirement).
I think, if anything, we need to have a serious discussion (plan) on how to now define "dependencies" as a concept in Drupal. Only having a single "dependencies" entry isn't enough and is the only way to correlate extensions (albeit, currently in a very inconsistent manner). Drupal has grown up.
It wasn't immediately clear from the other issue if this is about depending on one of the modules in a provided list. In other words, if a module requires certain functionality provided by a bunch of modules, where any one will do, are we talking about setting something up so any one of the modules is required? Or, as Debian would put it,
[...] lists of alternative package names, separated by vertical bar (pipe) symbols |.
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.
Comments
Comment #2
David_Rothstein commentedPossibly related? (Not positive if it is.)
Comment #3
markhalliwellSeems like there's a few ideas floating around that hint at roughly the same "ideas". However, I'm not entirely sure, at this point, whether this is indeed a duplication.
The other issues seem to be more focused on the "suggest install" idea (like: "hey, you might like this module too"). This is about ensuring "peer dependencies" are also always installed, just after (not before like it currently is: a requirement).
I think, if anything, we need to have a serious discussion (plan) on how to now define "dependencies" as a concept in Drupal. Only having a single "dependencies" entry isn't enough and is the only way to correlate extensions (albeit, currently in a very inconsistent manner). Drupal has grown up.
Comment #5
colanIt wasn't immediately clear from the other issue if this is about depending on one of the modules in a provided list. In other words, if a module requires certain functionality provided by a bunch of modules, where any one will do, are we talking about setting something up so any one of the modules is required? Or, as Debian would put it,
For example, I'm thinking of module that needs a Services authentication plug-in where I want either Services API Key Authentication or Services API Keys Authentication. I can't make them both required as either one will do.
So either this issue:
Comment #20
nicxvan commentedWhy wouldn't we do this with hook requirements?
Is this just for convenience?
Comment #21
nicxvan commentedNot exactly sure which closed status is applicable.
If someone had a clearer requirements that isn't covered by install requirements feel free to reopen.