Posted by earnie on December 7, 2006 at 1:48pm
6 followers
Jump to:
| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
Just like the recent addition of the requires variable there needs to be a conflicts variable so that contributed modules that are similar can declare that they conflict with one another. Example of existing conflicting modules is the conflict between Flexinode and CCK. CCK's content.info file would contain a ``conflicts = Flexinode'' and Flexinode's flexinode.info file would contain ``conflicts = Content''. The module system would then not allow the two modules to be selected at the same time.
Comments
#1
Interesting idea, Has this been implemented in Drupal 6 and update_status?
#2
Not that I'm aware of. Want to look at doing the patch? If so go ahead, I'm not going to be able to get to it anytime soon.
#3
It's a bit dangerous. When a conflicting module is fixed, other modules that specified it as conflicting have to be updated too! Otherwise the poor old module still won't be able to run.
And really conflicting modules like CCK and Flexinode are an exception I guess. Most modules implementing the same kind of features can work together, like image module and CCK+imagefield.
Displaying a list of conflicting modules on the project page may be enough.
#4
I'm not sure how you "fix" a conflict other than removing it; but, yes, the maintainers of the conflicting modules would need to work together to maintain the variables in each package. Working together is a good thing. My installing and enabling conflicting modules unaware is not a good thing. And listing conflicting modules on the project page isn't good enough since it would require maintenance of that page which not everyone can do.
#5
I see an upside to the case of having a module that previously conflicted with another module fixed and therefore they removed the conflicts variable from the .info file. Even if the module that previously conflicts may still conflict with the other module, a new bug report could be filed and then that bug report could be triaged to the appropriate module that is causing the conflict.
If a module says its going to work and doesn't, then its a bug. And if previously the avid users of that module knew there was a conflict and the module developer says the conflict has been cleared and it still doesn't work. Then the bug submitted has a lot of previously known information to add to their bug report.
#6
Moving issues from User experience project to Drupal core usability component.
#7
No. Contrib modules should be written in a non-conflicting way in the first place.
Also, you can use hook_requirements() to check for any other, conflicting modules already.
#8
Sun you're a bit naive.
Flexinode and CCK are both valid modules and conflict with each other.
Ubercart and eCommerce are both valid modules and conflict with each other.
I could find others but do not have time right now. These modules need to be able to mark themselves as conflicting with each other and then if one is active Drupal disables the checkbox of the other. These modules are "by design" conflicting and the maintainers know it. There are valid reasons for "by design" conflict and you can't just thumb your nose at them saying get together and cooperate. Drupal is a framework for independent work by others to be created and shared. The independent nature of contributed modules makes it necessary that this feature remains active.
#9
Duplicate of #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file (there has been more work and traction there).
#10
Humph.. #328932: Modules and partial dependencies - enhances[] and enhancedby[] field in modules .info file is nearly two years younger than this issue and yet this one is marked duplicate!
I'm being sarcastic, no need to comment.