Creating dynamic allowed values options for an entity field

By shane
Thu, 2015-04-09 07:59
4 comments

Share with Others

If you are building out a Drupal 7 site you may some day run into a situation where you need to have more dynamic options for a field attached to a content type (or any other type of entity). If the default allowed values text area will not work for your situation, then you have come to the right place. In this tutorial, we will discuss two different ways to create a more dynamic options list for extending your allowed values.

Method 1: Entity Reference

The first and most common reason you will need a dynamic options list is to reference some other type of entity or content on your site. This is easily manageable through the Entity Reference module. You can use the Entity Reference module to create a field to reference to any other type of entity. I have many other posts/videos on the Entity Reference module so I won't spend much time on it, but it's a great module for any Drupal site builder to become familiar with. I use it on almost every complex Drupal site I work on.

Method 2: Change the allowed values function of your field

The method requires a little module development/PHP skills. This is useful if you need to pull in your options value from some other database table (maybe a custom built one or one created by a contrib module).

In order to easily follow along with this you will need to be using the Features module to export your field to a Feature module. I have many posts/videos on the Features module and an entire section of my 5 secrets ebook that covers how to use Features on your Drupal websites.

So the first step is to create your Feature module making sure to select the field that you want to create dynamic options for. Once that is finished you will have to make changes to some of the exported Feature module code.

What! Change the Feature module code?

You might be thinking "It doesn't seem like a good idea to change the code generated by the Features module". You would be 100% correct in this thinking. It's typically not a good idea to change the code of a Feature module. However, the Features module does a pretty good job maintaining custom changes you make (depending on where you make the changes).

For instance, I commonly use the .module file generated by the Features module to add simple helper functions or form alter functions that are directly related to the exported Feature module. This allows me to keep the related code with the related Feature. I have seen a lot of developers create a Feature module and a custom module for the related code. While this typically works OK the main problem with this is that now you have a custom module that depends on the Feature module, and the Feature module that might depend on the code of your custom module. This gives you a strange circular dependency situation. To avoid this, just add your code to the module file (just don't remove the includes line of code at the top). Trust me... it's safe to do this and sometimes it makes a lot of sense.

To change the allowed values of a field, you will need to find the file that was created and ends with .features.field_base.inc. So if your module is called my_feature_module you will need to open my_feature_module.features.field_base.inc.

Search the file for the field you created and whose options you want to control. It should look something like this:

// Exported field_base: 'field_my_feature_module_options'
$field_bases['field_my_feature_module_options'] = array(
  'active' => 1,
  'cardinality' => 1,
  'deleted' => 0,
  'entity_types' => array(),
  'field_name' => 'field_my_feature_module_options',
  'locked' => 0,
  'module' => 'list',
  'settings' => array(
    'allowed_values' => array(),
    'allowed_values_function' => '',
  ),
  'translatable' => 0,
  'type' => 'list_text',
);

You will notice there is an allowed_values_function element in the array. In this case, you will want to change that to a PHP function that you will need to create. So in this case we are going to create a function called _my_feature_module_options_list (this could be any function name you want). Also make sure your allowed_values element is set to an empty array.

'settings' => array(
  'allowed_values' => array(),
  'allowed_values_function' => '_my_feature_module_options_list',
),

You are now ready to create your function. Simply open up your .module file (in this case it would be the my_feature_module.module file) and add your function. If you want to create static values, your function will look like this:

function _my_feature_module_options_list() {
  return array(
    'option1' => t('Option 1'),
    'option2' => t('Option 2'),
    'option3' => t('Option 3'),
    'option4' => t('Option 4'),
  );
}

If you wanted to pull values from a database table it might look something like this:

function _my_feature_module_options_list() {
  $results = db_query("SELECT value, label FROM {my_custom_table}");
 
  $options = array();
  foreach ($results AS $result) {
    $options[$result->value] = t($result->label);
  }
 
  return $options;
}

In order to get this to work you will need to make sure your Feature module is enabled on your site and ensure it gets reverted back to the default state. Once you do this, your values should be dynamically created by your custom PHP function.

Summing up using the allowed values function

From my experience, I have never had an issue with the Features module overwriting my allowed_values_function setting. It's a pretty rare situation where you will need this as most use cases are covered by either a static allowed values list or can be handled by the Entity Reference module. If you do find yourself needing a dynamic list of options controlled by a PHP function, then the method presented above provides an easy solution.

So go ahead and make those allowed values dynamic and let me know what you think.

Comments

I already use Features on all my projects so it was easy to make this small change. I haven't used hook_field_info_alter but it looks like that also might get the job done. If that does work, it might be a little bit cleaner of a solution as I would not need to directly modify the generated Feature module.

Thanks for the suggestion.

Hi Shane, that's an interesting approach... I'm just wondering why you work with the Features module and not with a contrib module? Cheers!

We use the Features module on all of our projects for deploying changes from dev to stage to prod environments. I am not sure I understand the rest of the question. I tried a few different approaches and this was the easiest that I could find. However, using hook_field_info_alter was also offered as a solution which might be an even better option.

Post new comment