In a multi-environment setup (e.g. prod, test, dev, local) there are some modules that you'd like to always be enabled or disabled on certain environments. Each time you sync a database down though you have to re-enable/disable the same modules. Worse, you get lazy and keep development modules enabled on production.

Habitat provides settings to enable or disable certain modules on each environment (habitat). Just set a variable with e.g. $conf['habitat'] = 'local'; in your settings.php file (the actual variable to use there is configurable for your current workflow). The disabling/enabling modules is done on hook_init.

A token ([site:habitat]) is provided in case you want to include it in a page or email.

Use Cases

With habitat you may set that on prod certain UI modules are always disabled (views_ui, field_ui, even habitat_ui itself), to prevent untrained site builders from overriding Features.

On local you may set that they are always enabled and also enable development modules like devel or stage_file_proxy.

You can also use environment-specific Features modules to ensure settings (e.g. css aggregation, error settings) are different between environments. If you have certain settings you change as part of a launch checklist, you can automate these with a prod-only Features module.

Related projects

Built by Zivtech as part of our starterkit profile Bear.

Bear includes starter features for Habitat in its Bear Habitat modules.

Habitat also plays well with Fetcher, our drush tool for building and cloning sites to different environments.

Habitat makes most sense in a Features-based workflow.

Habitat

Issues

habitat project open to new maintainer applications on 5 Oct, 2021Closed: outdatedMiscellaneous Created about 4 years ago

habitat project open to new maintainer applications on 5 Oct, 2021
Closed: outdated
Miscellaneous
Created about 4 years ago