Posted by drinkypoo on October 31, 2006 at 6:42pm
19 followers
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | system.module |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | .info, .info file, conflict, conflicts |
Issue Summary
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
#1
sorry, 5.0 is closed for feature requests
#2
moving from x.y.z to 6.x-dev version queue
#3
+1 for this. I would use if available in my video module.
Fabio Varesano
#4
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.
#5
I would like this functionality to, mainly to prevent namespace conflicts.
#6
+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.
#7
#8
Mark #108458: Implement a system of module conflict detection as a duplicate of this issue.
See also : #211747: Allow specifying version information as part of module dependencies
#9
Marked #170424: .info file should support negative dependencies as a duplicate of this issue.
#10
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.
#11
Subscribing.
#12
See also #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file.
#13
Subscribing.
#14
Added a patch to the issue mentioned in #12, #328932-66: Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file, 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.
#15
#16
subscribing
I think modules like admin_menu vs toolbar would benefit from this implementation
#17
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 file
#328932-139: Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file
#328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file
#18
#19
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