Site administrators

The Environment Indicator settings page allows you to modify some elements of the indicator's behaviour and appearance. Individual settings, such as the text to display and the colour can be overridden for each of your specific environments in the site's settings.php file. This allows you to customise the indicator for each of your environments without needing to make any changes in the database. This means that the Environment Indicator will always display correctly when moving your site from development to staging to production.

Examples of how to override settings in settings.php:

environment_indicator_text

The text that will be displayed vertically down the indicator. e.g:
$conf['environment_indicator_text'] = 'DEVELOPMENT SERVER';

environment_indicator_color

A valid css color. e.g:
$conf['environment_indicator_color'] = 'dark-red';

environment_indicator_enabled

A boolean value indicating whether the Environment Indicator should be enabled or not. On your production environment, you should probably set this to FALSE. e.g:
$conf['environment_indicator_enabled'] = FALSE;

The Environment Indicator's visibility depends upon the permissions of the viewer (access environment indicator).

This module will help you to keep sane while working on your different environments by adding a configurable color bar to each one of your environments. The Environment Indicator adds a coloured bar on the site informing you which environment you're currently in (Development, Staging, Production etc). This is incredibly useful if you have multiple environments for each of your sites, and like me, are prone to forgetting which version of the site you are currently looking at.

This module can help you avoid making configuration changes to your live server by mistake by adding a coloured strip to the side of your site, clearly marking each version of the site.

Hopefully your project has several of the following environments. By placing an indicator you will know with a glance where you are testing that last code, that you're about to configure the right environment, etc.

Drupal 7 added a new feature into core that is not user facing directly, but is sometimes called poor man's cron. The feature triggers the periodic tasks of a Drupal site like emptying log files, sending e-mails, and clearing out caches. This feature, when combined with dynamic detection of the "base url" (added in Drupal 4.7), can lead to some screwy situations. This article is a description of some of those screwy situations that occur with either module or both of them and what you can do to prevent them. The comments below assume some default configurations - I'll discuss at the end how to break away from those defaults to prevent these problems.

Scenario 1: Getting/sending user emails that appear to be for another domain

This behavior is pretty easy to replicate:

1. Point a new domain at the IP of an existing site - let's call the existing site http://www.example.com and the new name pointed at that IP is http://other-site.example.org

2. Visit the url: http://other-site.example.org/user/password

3. Submit a username that is likely to be populated

The Poultry provides a fluid, responsive theme customized to make RedHen easier to use and prettier to look at.

The RedHen Membership module provides
User Interface: path
Configuration: path

RedHen is designed to be extended, and some significant extension modules already exist. You can learn more about these pages in the sections below.