I have created a product type which has integer and float fields. I would like to store my data as the correct data type and allow users to make decisions about which product to buy based on those fields. These are ineligible to become part of the commerce "Add to Cart" as defined by the following commerce function:

function commerce_cart_field_attribute_eligible($field) {
  // Returns TRUE if the field is single value (i.e. has a cardinality of 1) and
  // is defined by a module implementing hook_options_list() to provide an array
  // of allowed values structured as human-readable option names keyed by value.
  return $field['cardinality'] == 1 && function_exists($field['module'] . '_options_list');

It looks like the concept of implementing hook_options_list is hardcoded into a few places, including the field config forms:

if ( ... && function_exists($form['#field']['module'] . '_options_list')) {
  // Enable this field to function as an attribute field on Add to Cart forms.

By looking at how this has been setup, it seems reasonable that if you want commerce to cooperate with a field type, it must implement the hook.

I have considered implementing this hook for the "number" module and returning the entire dataset of values defined on the website for the specific field (this seems to work without any issues from what I can tell with 5 products).

I'm not sure if this will cause issues with Commerce or core down the track, perhaps with:

  • Too much data grinding things to halt.
  • The core "options" module not playing nicely with float/int fields.
  • Other modules assuming the field is a list of data?
  • The weirdness around implementing another modules hook.

Looking for some advice on the best way to move forward with the problem.

1 Answer 1


I ran into the same problem (and asked a similar question which I ended up answering myself here)

Basically with the knowledge you gave I was able to implement a new module which installs a widget for the "list integer" and "list float" types that uses a textfield for input and on POST it sanitizes and adds the value of the textbox to the "allowed_values" setting on the field allowing it to pass the standard list field validation and use the standard list field storage.

This allows you to enter and display a "number" and use the value as a product attribute. Best part is I did not have to alter another modules code, which addresses the majority of your concerns as:

  • The core "options" module not playing nicely with float/int fields.

The options module defines the widget, since you are doing this, you don't need to worry about it.

  • Other modules assuming the field is a list of data?

Since you defined your own widget and are not using the standard "options", other modules will not know it exists so you don't have to worry.

  • The weirdness around implementing another modules hook.

Again, by adding the sanitized field into the allowed_values setting on POST you pass validation and this allows you to use the "LIST" modules standard implementation of hook_options_list and you don't have to modify someone else's code

As far as your first point on too much data, this is possible that you will have a problem here if you have a multitude of products OR if you are added and removing products all the time (which would continuously add to your "allowed_values" list). For the first point, you could probably also implement a field type in your module and do your own implementation of hook_options_list to follow your logic and just return all the values in your database (i don't have that much so didn't bother). For the second point, you could implement hook_cron and clean up on the allowed values setting based on the values for the field in the database.

hope this helps and if you have any questions let me know!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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