It can be very handy to dynamically enable/disable a module for your site. Assume you might share copies of same DB between live and development environments. You can enable devel module just for your dev environment and keep it disabled in the system table. Similarly, you might enable a module that logs all email rather than sending email when in dev environment.
Depends on #623992: Reduce {system} database hits, so it won't pass unit tests at least until that lands.
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | system_list_overrides.patch | 2.6 KB | marvil07 |
| #2 | mod_var.diff | 2.36 KB | moshe weitzman |
| module_variable.patch | 2.36 KB | moshe weitzman |
Comments
Comment #2
moshe weitzman commentedDependant patch has landed.
Comment #3
dries commentedOnly 359 passes because #623992: Reduce {system} database hits is still broken. Being worked on.
Comment #4
catchThis would be really handy for local sandboxes and shared development sites - where you'll often have devel etc. in sites/all and have to keep re-enabling them every time you bring down the live database. Patch looks clean, won't have any appreciable performance impact on live sites.
Comment #5
moshe weitzman commentedComment #6
mfer commentedsubscribe
Comment #7
boombatower commentedSubscribe. Directed from related blog post.
Comment #8
catchYou could almost do this in D7 via a contrib module and hook_module_implements_alter() - except for module_exists() and others which don't use that.
Comment #9
doublejosh commentedApparently this was implemented in at least this module
$conf['securesite_enabled'] = 0;There is also this project: http://drupal.org/project/environment
I very much want this for Devel (same case as the original post), but it looks like not possible in D6.
Comment #10
boombatower commentedI really think core should support something like in #7 rather then just drush/devel
Comment #11
catch15 lines of code including closing braces: http://drupal.org/sandbox/catch/1152890
Comment #12
moshe weitzman commentedSeems like a great solution for now. Time will tell how brittle it turns out to be. It is a bit disconcerting for modules to get loaded and stil have 0 status in DB.
Comment #13
catchYeah I still think we should consider this for D8, although at the moment I prefer making disabled modules enabled compared to the other way 'round - this way there's no runtime cost on production - enabled modules have to be loaded by system_list() and possibly elsewhere, which is currently not cheap for memory until the system_get_info() patch gets in.
Was mainly just excited that this was possible at all from contrib in D7, drupal_static() is amazing for hacks like this.
Comment #14
boombatower commentedOr you make an install profile with the .info file format I mentioned in #7.
Comment #15
xandeadx commentedsubscr
Comment #16
marvil07 commentedre-rolling
Comment #17
marvil07 commentedComment #18
moshe weitzman commentedThe system_list is about to made into a CMI object at #1608842: Replace list of bootstrap modules, enabled modules, enabled themes, and default theme with config. Once thats in, we have a more generic need to override CMI for a given environment. Not sure where the issue is for that.
Comment #19
alanburke commented#17: system_list_overrides.patch queued for re-testing.
Comment #21
alanburke commented#17: system_list_overrides.patch queued for re-testing.
Comment #23
candelas commentedSuch a good idea...
Comment #24
mgiffordUnassigning stale issue. Hopefully someone else will pursue this.
Comment #25
moshe weitzman commentedDrush has implemented this in config-import and config-export - http://docs.drush.org/en/master/config-exporting/#ignoring-development-m...