function variable_get($name, $default = NULL) {
  global $conf;

  return isset($conf[$name]) ? $conf[$name] : $default;

From where does variable_get() get the first parameter?


I think you're referring to the $conf variable?

It's set in sites/default/settings.php (or sites/SITENAME/settings.php if you have a multi-site installation), and that file is included in Drupal's page build.

| improve this answer | |
  • thanks. function hook_menu_delete($menu) { // Delete the record from our variable. $my_menus = variable_get('my_module_menus', array()); unset($my_menus[$menu['menu_name']]); variable_set('my_module_menus', $my_menus); } from where it get 'my_module_menus' , where is the variable defined . – Mehdy Mahmood Aug 23 '12 at 16:42
  • 1
    It's just a string, it doesn't get defined anywhere as such – Clive Aug 23 '12 at 16:50
  • 3
    @MehdyMahmood It does get shoved into the $conf array by variable_set() though if that's what you are after, e.g., each variable name is an index into that array. – Jimajamma Aug 23 '12 at 16:59

The first parameter passed to variable_get() is the variable name. Every module decides the name of the persistent variables it uses.

Apart from avoiding conflicts with other variables defined from other modules, developers can use the variable name they like better. Preferably, they should use characters from a to z, the underscore, and numbers. Using other characters in the variable name could cause compatibility issues with other database engines, as different coding used for tables could not maintain the difference between lower-case characters, and upper-case characters.
The suggestion to use only lower-case characters is also reported in the Drupal.org coding standards:

Persistent variables (variables/settings defined using Drupal's variable_get()/variable_set() functions) should be named using all lowercase letters, and words should be separated with an underscore. They should use the grouping/module name as a prefix, to avoid name collisions between modules.

For each call to variable_get(), there is an equivalent call to variable_set(), which can be implicit (i.e. made from Drupal) in the case variable is used in a form similar to the following one.

function book_admin_settings() {
  $types = node_type_get_names();
  $form['book_allowed_types'] = array(
    '#type' => 'checkboxes', 
    '#title' => t('Content types allowed in book outlines'), 
    '#default_value' => variable_get('book_allowed_types', array('book')), 
    '#options' => $types, 
    '#description' => t('Users with the %outline-perm permission can add all content types.', array('%outline-perm' => t('Administer book outlines'))), 
    '#required' => TRUE,
  $form['book_child_type'] = array(
    '#type' => 'radios', 
    '#title' => t('Content type for child pages'), 
    '#default_value' => variable_get('book_child_type', 'book'), 
    '#options' => $types, 
    '#required' => TRUE,
  $form['array_filter'] = array(
    '#type' => 'value',
    '#value' => TRUE,
  $form['#validate'][] = 'book_admin_settings_validate';

  return system_settings_form($form);

The "book_child_type" variable is not explicitly set by the Book module, but from system_settings_form_submit(), the form submission handler added by system_settings_form().

  foreach ($form_state['values'] as $key => $value) {
    if (is_array($value) && isset($form_state['values']['array_filter'])) {
      $value = array_keys(array_filter($value));
    variable_set($key, $value);
| improve this answer | |

Drupal maintains a table called variable, it's used as a key-value store, and is the permanent storage for all "variables".

Each variable_set encodes data and inserts/updates in the table.

During boostrap, Drupal loads the entire variable table into memory, in the form of the $conf variable. Since most variable tables are fairly small, loading everything into RAM is seen as prefered to making a SELECT query in the table for every variable get.

As Clive pointed out, one can override individual values in the settings.php file, either because one needs data available really early during bootstrap, such as for cache-related settings, or because a site needs a temporary workaround for a certain variable value.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.