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.

CommentFileSizeAuthor
#17 system_list_overrides.patch2.6 KBmarvil07
#2 mod_var.diff2.36 KBmoshe weitzman
module_variable.patch2.36 KBmoshe weitzman
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch failed testing.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Status: Needs work » Needs review
FileSize
mod_var.diff2.36 KB

Dependant patch has landed.

Dries’s picture

Dries CreditAttribution: Dries commented

Only 359 passes because #623992: Reduce {system} database hits is still broken. Being worked on.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

This 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.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Version: 7.x-dev » 8.x-dev
mfer’s picture

mfer CreditAttribution: mfer commented

subscribe

boombatower’s picture

boombatower CreditAttribution: boombatower commented

Subscribe. Directed from related blog post.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

You 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.

doublejosh’s picture

doublejosh CreditAttribution: doublejosh commented

Apparently 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.

boombatower’s picture

boombatower CreditAttribution: boombatower commented

I really think core should support something like in #7 rather then just drush/devel

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

15 lines of code including closing braces: http://drupal.org/sandbox/catch/1152890

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

Seems 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.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

Yeah 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.

boombatower’s picture

boombatower CreditAttribution: boombatower commented

Or you make an install profile with the .info file format I mentioned in #7.

xandeadx’s picture

xandeadx CreditAttribution: xandeadx commented

subscr

marvil07’s picture

marvil07 CreditAttribution: marvil07 commented
Status: Needs review » Needs work

re-rolling

marvil07’s picture

marvil07 CreditAttribution: marvil07 commented
Status: Needs work » Needs review
FileSize
system_list_overrides.patch2.6 KB
moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Status: Needs review » Active

The 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.

alanburke’s picture

alanburke CreditAttribution: alanburke commented
Status: Active » Needs review

#17: system_list_overrides.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, system_list_overrides.patch, failed testing.

alanburke’s picture

alanburke CreditAttribution: alanburke commented
Status: Needs work » Needs review

#17: system_list_overrides.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, system_list_overrides.patch, failed testing.

candelas’s picture

candelas CreditAttribution: candelas commented
Issue summary: View changes

Such a good idea...

mgifford’s picture

mgifford
he/him
Primary language English
CreditAttribution: mgifford at OpenConcept Consulting Inc. commented
Assigned: moshe weitzman » Unassigned

Unassigning stale issue. Hopefully someone else will pursue this.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented
Status: Needs work » Fixed

Drush has implemented this in config-import and config-export - http://docs.drush.org/en/master/config-exporting/#ignoring-development-m...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.