Configure Environment Indicator 7.x-2.x

Note that the Environment Indicator (envindicator) project was a complete rewrite of Environmental Indicator. This project has been incorporated back into Environment Indicator (environment_indicator) as part of the 7.x-2.x branch.

Key differences with the 7.x-1.x release:

  • You can configure all your indicators from one place.
  • You can position your indicator to not to interfere with your design.
  • You can control permissions per environment. This way you can show the indicator for anonymous users in all the environments except for production.
  • You can export your configurations to code and include them in GIT.
  • It can be used on dynamically generated environments.
  • Your site builders won't need to access your settings.php.
  • It's integrated with the features module.
  • It's integrated with the Toolbar module.
  • Integration with Admin menu module.

Configure Environment Indicator 6.x-1.x & 7.x-1.x

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.

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.

Environment/Tier Name Description
Local Developer's desktop/workstation
Virtual Machine VM hosted on developers desktop or possibly development server
Development Development server aka sandbox
Integration CI build target, or for developer testing of side effects

Contributor task: Manually do accessibility testing of a patch for a Drupal issue

On this page:

To get help completing this task, see the Getting help completing your task page. The #drupal-accessibility irc channel might have people in it to chat with about coding and accessibility issues and extensions in Drupal.


From an accessibility point of view, manually test a patch (software fix) for a reported Drupal issue to verify that it resolves the issue and does not cause other regressions (new bugs). The Accessibility section of the core gates documentation page has more information.

Skills needed

Some familiarity with the module, theme, or task is helpful, but not required. You will also need to apply a patch to a test site.

Testing a three-legged and two-legged OAuth REST, using Services 7.x-3.2 and Oauth 7.x-3.0, with PHP Client

Here I will post all my system settings and configurations to test it out.



  • CentOS 6.3
  • PHP 5.3.18
  • PECL Oauth extension (via command pecl install oauth)
  • Drupal-7.17
  • Server URL: http://core.zeus.lan (you can use any URL BUT You SHOULD really going for HTTPS)
  • Client URL: http://localhost/oauth.php (this will be used below)



I use location sites/all/modules/contrib for my drupal modules.

Services Configuration

First we set up the services with oauth.

  1. In Drupal site, install modules: REST Server, OAuth Authentication, OAuth Provider UI.
  2. In Drupal directory, comment out line 6 to 8 in file oauth/lib/OAuth.php, since it will conflict with PECL OAuth.
  3. In Drupal site, Create OAuth context in admin/config/services/oauth/add, make sure to create Authorization level and set as default.

Creating and testing full projects and releases

Gather concepts about releases, review processes, and other meta-project info... use the child pages for the HowTo. These are still, in general not specific about the git tool in use.

Full project overview

Full projects are typical modules, themes, and installation profiles you download from the download and extend section of

In contrast to sandbox projects, full projects offer the following benefits:

  • Human-readable shortname in the URL rather than numeric ID (for example, /project/projectname rather than /sandbox/username/node-id)
  • Downloadable releases for end users
  • Usage statistics
  • Increased ranking in search results
  • No Experimental Project warning message on project page
  • Project appears in the Main project issue drop-down
  • Full support for Drupal Translations

Once you have both obtained basic Git access on and completed a one-time approval process, you have two ways of creating a full project:

Subscribe with RSS Subscribe to RSS - testing