You are here

README.txt in Environment 7

Same filename and directory in other branches
  1. 8 README.txt
  2. 6 README.txt
ENVIRONMENT

Creates an API for specifying an environment for a site instance.  Other modules
may then change their logic depending upon the current active environment. When
switching environments a hook is invoked to allow any module to run additional
required actions.

The environment states are defined for use in hook_environment() and so 
may be unique to the current project. Predefined environments are 'development' 
and 'production'.

This module provides a UI to facilitate basic use, but is at heart a 
developer's module, providing the ability to perform site operations as 
part of a state machine transition.

Environment module now support now supports multiple environments per site. The
"default" workflow environment is the same as previous module behavior, and
includes the sample environment states of "development" and "production".
Creating new workflows is a developer task, much as creating new environment
states.

USING DRUSH

Environment provides two drush commands, 'environment' and 
'environment-switch'. Environment tells you the current environment, 
environment-switch toggles the current environment state as you declare. 
For usage instructions, turn on the Environment module and type `drush 
help environment` and `drush help environment-switch`.

FOR DEVELOPERS

'environment.api.php' describes the use of hook_environment() to define 
new environment states, hook_environment_alter() to tweak those 
definitions, and hook_environment_switch() to trigger any environment 
change operations defined in any module of your site.

To create new workflows, implement hook_environment_workflow() and at least
define a label element. To categorize an environment state as part of a given
workflow, just add that element to the environment definition.

The `environment_allowed()` function is a method for asserting behaviors 
predefined as permitted or not permitted in the environment definition.

FOR ADMINISTRATORS

Once installed, you can toggle the current environment amongst any 
defined by visiting 'admin/settings/environment'. This will do nothing 
unless the site has been built to do something depending on the current 
environment.

Sites which make heavy use of the Environment module may choke if you 
try to use the UI to toggle the environment state. In that case, you may 
want to use `hook_form_alter()` to hide that option.

If you prefer to manage environment states entirely in code, you can 
check on 'Require environment override', this will help you enforce that 
an `environment_override` variable defined in your settings.php file is 
correctly used as your environment. You may also simply define the 
`environment` variable, but you will then lose some of the extra UI help 
that explains why the UI no longer updates the environment state.

When you define the environment state in settings.php, you will still 
need to run `drush env-switch` to update the environment to that state, 
possibly using the --force flag if the system thinks it is already in 
that state.

Check 'admin/reports/status' for any problems with your Environment 
configuration.

FOR SITE BUILDERS

The Environment module provides Token and Context integration to 
facilitate building actual functionality around your current 
environment. This is primarily envisioned as mechanisms to help inform 
the current site user of the current environment. If you do anything 
inventive, be sure to let us know!

There are 'environment' and 'environment-label' tokens that will show 
the machine name or human title for the current environment.

There is also an Environment condition for the Context module that will 
allow you to trigger block placement or other context reactions based on 
the site environment.

File

README.txt
View source
  1. ENVIRONMENT
  2. Creates an API for specifying an environment for a site instance. Other modules
  3. may then change their logic depending upon the current active environment. When
  4. switching environments a hook is invoked to allow any module to run additional
  5. required actions.
  6. The environment states are defined for use in hook_environment() and so
  7. may be unique to the current project. Predefined environments are 'development'
  8. and 'production'.
  9. This module provides a UI to facilitate basic use, but is at heart a
  10. developer's module, providing the ability to perform site operations as
  11. part of a state machine transition.
  12. Environment module now support now supports multiple environments per site. The
  13. "default" workflow environment is the same as previous module behavior, and
  14. includes the sample environment states of "development" and "production".
  15. Creating new workflows is a developer task, much as creating new environment
  16. states.
  17. USING DRUSH
  18. Environment provides two drush commands, 'environment' and
  19. 'environment-switch'. Environment tells you the current environment,
  20. environment-switch toggles the current environment state as you declare.
  21. For usage instructions, turn on the Environment module and type `drush
  22. help environment` and `drush help environment-switch`.
  23. FOR DEVELOPERS
  24. 'environment.api.php' describes the use of hook_environment() to define
  25. new environment states, hook_environment_alter() to tweak those
  26. definitions, and hook_environment_switch() to trigger any environment
  27. change operations defined in any module of your site.
  28. To create new workflows, implement hook_environment_workflow() and at least
  29. define a label element. To categorize an environment state as part of a given
  30. workflow, just add that element to the environment definition.
  31. The `environment_allowed()` function is a method for asserting behaviors
  32. predefined as permitted or not permitted in the environment definition.
  33. FOR ADMINISTRATORS
  34. Once installed, you can toggle the current environment amongst any
  35. defined by visiting 'admin/settings/environment'. This will do nothing
  36. unless the site has been built to do something depending on the current
  37. environment.
  38. Sites which make heavy use of the Environment module may choke if you
  39. try to use the UI to toggle the environment state. In that case, you may
  40. want to use `hook_form_alter()` to hide that option.
  41. If you prefer to manage environment states entirely in code, you can
  42. check on 'Require environment override', this will help you enforce that
  43. an `environment_override` variable defined in your settings.php file is
  44. correctly used as your environment. You may also simply define the
  45. `environment` variable, but you will then lose some of the extra UI help
  46. that explains why the UI no longer updates the environment state.
  47. When you define the environment state in settings.php, you will still
  48. need to run `drush env-switch` to update the environment to that state,
  49. possibly using the --force flag if the system thinks it is already in
  50. that state.
  51. Check 'admin/reports/status' for any problems with your Environment
  52. configuration.
  53. FOR SITE BUILDERS
  54. The Environment module provides Token and Context integration to
  55. facilitate building actual functionality around your current
  56. environment. This is primarily envisioned as mechanisms to help inform
  57. the current site user of the current environment. If you do anything
  58. inventive, be sure to let us know!
  59. There are 'environment' and 'environment-label' tokens that will show
  60. the machine name or human title for the current environment.
  61. There is also an Environment condition for the Context module that will
  62. allow you to trigger block placement or other context reactions based on
  63. the site environment.