the .info files should have a line to list modules with which the module conflicts with. that way if you have two modules that perform the same function and step on one another, they could be marked that way. The module admin page could tell you that you are enabling conflicting modules, and of course tell you that they conflict before you enable them.

Comments

sime’s picture

Version: 5.0-beta1 » x.y.z

sorry, 5.0 is closed for feature requests

coreb’s picture

Version: x.y.z » 6.x-dev

moving from x.y.z to 6.x-dev version queue

fax8’s picture

+1 for this. I would use if available in my video module.

Fabio Varesano

suydam’s picture

What ever came of this? I'm working on a pricing level module that directly conflicts with Role Discounts. I'd love to be able to say that in my .info file.

ntroutman’s picture

I would like this functionality to, mainly to prevent namespace conflicts.

xolotl’s picture

+1 For example, the 5.x cck date field conflicts with the 5.x event module, with this feature, one could be prevented from installing the cck date module until the event module was disabled.

ugerhard’s picture

Version: 6.x-dev » 7.x-dev
lilou’s picture

fgm’s picture

fgm’s picture

While we're at the "dependencies feature" stage, it would also be nice to have a way to indicate when a module does not actually "need" an other module, but has added features when it is present. This would remove a burden from contrib module devs who need to add specific code for this to their module, while a core mechanism could allow refactoring all this contrib-specific code to just one standard way of having such optional dependencies expressed.

babbage’s picture

Subscribing.

Dave Reid’s picture

doq’s picture

Subscribing.

voxpelli’s picture

Added a patch to the issue mentioned in #12, #328932-66: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files, which could be built upon to solve this issue. If that issue develops in the direction of my patches then this issue perhaps should be postponed until that issue has been solved.

sun.core’s picture

Version: 7.x-dev » 8.x-dev
shadcn’s picture

subscribing

I think modules like admin_menu vs toolbar would benefit from this implementation

lpalgarvio’s picture

Title: Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file » module .info files should have a field for conflicts
Component: system.module » base system
Issue tags: -conflict, -.info file, -.info, -conflicts

we need these:
* conflicts[] - module(s) that can NOT be enabled when enabling this module (ERROR)
* breaks[] - module(s) that will NOT work after enabling this module (WARNING)
* brokenby[] - module(s) that will make this module NOT work after being enabled (WARNING)

see:
#328932-153: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files
#328932-139: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files
#328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules' .info.yml files

lpalgarvio’s picture

Title: module .info files should have a field for conflicts » Modules in conflict - conflicts[] and breaks[] field in modules .info file
Component: base system » system.module
Issue tags: +conflict, +.info file, +.info, +conflicts
lpalgarvio’s picture

Title: Modules in conflict - conflicts[] and breaks[] field in modules .info file » Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file

actually, we should use brokenby[] instead of breakedby[].

english lessons reminded me of broke/broken and simple past and past participle, so i read a bit to make sure:
http://en.wiktionary.org/wiki/break
http://en.wiktionary.org/wiki/breaks
http://en.wiktionary.org/wiki/broke
http://en.wiktionary.org/wiki/broken
http://en.wiktionary.org/wiki/enhance
http://en.wiktionary.org/wiki/replace

cafuego’s picture

Title: module .info files should have a field for conflicts » Modules in conflict - conflicts[], breaks[], brokenby[] field in modules .info file
Component: base system » system.module
Issue tags: +conflict, +.info file, +.info, +conflicts

This has been open for half a decade and seems very useful. Can we get this into D8?

Andre-B’s picture

maybe d9 it will be :(

DarrellDuane’s picture

Issue summary: View changes

I think this is a better solution, and it could be implemented for d7 now, maybe even d6:

https://www.drupal.org/node/2478351

I am thinking it would be a very nice feature for each project listed on Drupal.org to have the ability to add a list of other projects that the given project conflicts with. This is a new solution to the problem noted above.

By maintaining this information on Drupal.org, rather than in .info files we can better track issues and allow Drupal Core to get the latest updates about problems and fixes to problems related to conflicts with another project/module. I know that there could be some themes that have conflicts with modules.

One way to do this would be to add another field on the issue tracker for the listing of a conflicting project. From here, details about what the bug is and whether its something that can be fixed, and a level of severity would be good to have. Another way to do it is to have an entirely new field for the project to add conflicting projects, and at that time also add any issues that have more details about the conflict. I'd suggest the former. If we do the former, I expect we will have some issued as won't fix.

It would be nice to get a quick report of conflicts with other projects, such that we might quickly identify other modules with similar functionality.

It would be nice to make an API to read this data from Drupal.org so that when someone enables two modules that conflict, a message can appear on the module page or elsewhere notifying the administrator and allowing them to quickly research the concern.

Thanks for your consideration, let me know how I can help with this.

fgm’s picture

As an interesting side effect of maintaining the info on d.o. instead of within each project, the info could be included in releases packaged by the distribution system, like other extensions to the *.info[.yml] files.

lpalgarvio’s picture

Version: 8.0.x-dev » 8.2.x-dev
sime’s picture

*cough* composer *cough*

ajay_reddy’s picture

Is there any way to add conflicts in D8 .info.yml as like in D7. If any helpful links post it here or in this issue queue.

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.

geek-merlin’s picture

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.

slefevre@ccad.edu’s picture

Issue tags: -, -

This would be a very useful feature to have. Here's an issue thread for unpublished_node_permission, where a user notes that, within the thread, two modules are known to conflict with unpublished_node_permission (content_access and advanced_access).

Having a `conflicts` line would prevent waste of developers' time and creation of extraneous issues.

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.

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.