I've gotten into the habit of doing pretty robust configuration panes for my modules now, and I'm finding the variable names & management to be quite the pain.

I have variables like mymodule_section_subvar_varname_type_context and I not only loose track of the order of the elements in my variable names but I feel as if having a variable name that long is a design flaw.

I've been considering using a serialized array in a variable mymodule_section_settings in conjunction with a set of functions that make it easy to maintain that array but I'd love some input in what (if any) best practices have been established outside of prefixes and/or examples of modules that we trust and what they are doing for large sets of variables.


  • Also, I'd like to consider updates in this as well (which is why I am leaning towards a serialized array) so making changes to the variable names doesn't orphan data and add extra work for additional upgrade path functionality/tests – electblake Mar 17 '11 at 2:23

It is possible to use a Drupal variable to contain an array; that is what Drupal core modules do too (see book_type_is_allowed()).

It is possible to use a single Drupal variable to contain different settings used by a module into an array. With the form #tree attribute is still possible to use system_settings_form() to save the array into a Drupal variable without writing any additional code. Serializing the de-serializing the code is automatically done by the Drupal core functions that handle Drupal variables (see the code of variable_set()).

The question is then: when should a single Drupal variable be used to contain different settings? I would use a single variable for settings that are used by a function, or a group of functions; if the array contains values used by (for example) 10 different functions, but those functions access a single value (or a couple of values) from that array, then I would not use a single persistent variable for the settings.

  • Do you / anyone know how this type of scenario will react within Features and/or Strongarm? I'd hate to lock out those modules and the users who cherish the mobility those modules can bring. – electblake Mar 17 '11 at 14:12
  • I don't see any reasons why Features would have any problem with a Drupal variable that contains an array. Somebody else could report you in details if it is completely true, or not. – kiamlaluno Mar 17 '11 at 14:48
  • yes, I understand this may be a tad out of scope of this question - but want to make sure this standard works for everyone :) I'll report after I try a few things. – electblake Mar 17 '11 at 14:55

If a set of settings are related then putting them in an array makes sense. For example if you are doing several variable_get's sequentially. It gives you some flexibility as well as being potentially a little faster.

However this will make it difficult for other programs to edit your settings manually via something like drush vset or strongarm. In these cases long variable names can actually be helpful.

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.