Environments Project Page

We created the Environments module (shortname Envts) to manage a “two-dimensional” site environment for a client site, and then abstracted the code into an API-type module.
Drupal is fairly good at running multi-site builds, with sites folders and different settings.php files. Modules like Domain Access are good at managing those sites one-dimensionally – a single list of hosts with primary (mysite.com), secondary (special.mysite.com), etc, and deep integration with Views and other modules.

But this single list of sites is built for one environment: one set of domains, such as for a live site.
<!–break–>
For example:

• dartcenter.org [primary]
• dartsociety.org [secondary]

Domain Access is good at listing these domains and filtering nodes by them. But in our work, there’s never only one environment. There’s a development environment -

• dartcenter.dev.echoditto.com [primary]
• dartsociety.dev.echoditto.com [secondary]

- and each developer usually has a local server environment -

• dartcenter.ben.local [primary]
• dartsociety.ben.local [secondary]

- and sometimes there’s a staging server between dev and live -

• staging.dartcenter.org [primary]
• staging.dartsociety.org [secondary]

- and so forth.

The result is two dimensions of sites that need to be managed, across dozens of sites folders, with no easy way to manage context (“which site and environment is running now?”), switch between them (“I’m on the ‘primary’ site on the ‘dev’ environment, take me to the same page on the ‘primary’ site in the ‘live’ environment”), or get an easy big-picture view of all the environments and sites in use.

We wrote most of this module as custom code for a multi-site client project (The Dart Center and The Dart Society) in order to fulfill those needs, then abstracted it to a standalone module. It’s currently very lightweight, an API-like module with a hook, global variables, and helper functions. There’s no UI yet, but a UI could easily be added as a separate module (and we welcome all such contributions!). It’s not meant as a replacement for Domain Access – it doesn’t try to replicate the Views and node form integration, for example – but instead serves a more limited purpose that Domain Access doesn’t do well, and maybe in the future it will become more robust.

The module provides a define_envts() hook, which other modules can implement, returning arrays of environments and sites that build a global $envts_list. A 2-dimensional hook implementation might look like this:

Envts then creates 3 global variables (in its own hook_init()), $envts_current_site (e.g. ‘primary’), $envts_current_envt (e.g. ‘live’), and $envts_current_host (’site.com’), which can be invoked directly for context handling. There are also helper functions: envts_which_site(), envts_which_envt(), and envts_which_host() which check their respective contexts for the current or specified hosts. In addition, the module provides a simple block showing all defined sites, with the current site highlighted and links to cross between the environments.

Check it out and tell us what you think (ben at echoditto dot com), what use cases should be added, what should be changed. A few basic TODO items are written in the code, and much more can be added over time, hopefully with community contributions.

Download: http://drupal.org/project/envts