This idea first popped up with two contrib modules that use the same database table (from D7), but might also be helpful regarding Forum version 1.x-1.x and Forum version 1.x-2.x, basically any modules that compete for the same resources.
A module should be able to declare a conflict in an easy way. This currently has to be done with custom code in hook_requirements() - and that possibly has to happen in both conflicting modules.
It would be much easier, if that could be done in the info file, similar to the way dependencies are declared.
In the case of modules that compete for the same resources, it could be:
name = Foo Module description = Does footastic things type = module backdrop = 1.x dependencies[] = needed_module (<1.12) conflicts[] = other_foo_module
If one of the two conflicting modules is already installed, the installer should refuse to enable the other one. No matter, which of the two modules declares the "conflict".
In the case of conflict or incompatibility between different major versions of the same module (where for example no upgrade path is ready yet between v1.x and v2.x):
v2.x could declare:
name = Forum description = Provides discussion forums. type = module backdrop = 1.x dependencies[] = views conflicts[] = forum (<2.0)
v1.x could declare
name = Forum description = Provides discussion forums. type = module backdrop = 1.x conflicts[] = forum (>=2.0)
In this case:
- on sites where v1 of the module is installed, v2 of the module should NOT be offered as an option for upgrade
- on new sites, v2 of the module should be provided as the default/recommended version
Does this seem feasible?
Recent comments
Tried and successfully applied DrAlbany's method with the form https://www.drupal.org/sandbox/grobot/2105379stickman hook. I also encountered the same situation. Thanks DrAlbany
Ubercart - Auto increment SKU
Since before migration you need to prepare the Drupal site - disabling and removing all modules, disabling themes, as part of the preparation you can clear the cache and logs, delete the search...
Trimming the size of my database for D2B_migrate not to error out (Request Entity Too Large / 504 Gateway Time-out)
QuickTabs is now available!!! But does not work as expected, already reported (https://github.com/backdrop-contrib/quicktabs/issues/14). Maybe an alternative solution using Views...
Quick Tabs (or method to simulate)