Possibility to show price difference/total price in attributes Select List / Radio Buttons

Must Have!

@elianhi, I meant to subscribe but I change the name of the issue to "Subscribe." I changed it back the best I could, sorry! I would like to have this feature too. You explained it well.

sub

I have been looking for functionality like this myself, or something close to this. I would expect that things like computers have custom attributes that can change the actual price of the product such as Apple's "build your own" Macbook (see screenshot).

Product attributes could have part numbers or a SKU which would be used for inventory and to be used as a pick list for the employees who are building out the product.

I may be making this too complex, but wouldn't part of this solution be that products should be able to refer to other products (or parts) which can then be used to create an attribute selection list?

The only way I have found to do this, is to put the price in the title of the attribute product, so that it shows the price in the attribute list. I have been trying to get a view to display the price based on which product is selected, but can't seem to get it to work. If anyone has gotten this to work, please post!

+1

Personally I would like to see the total price for each attribute shown.

I think showing the price difference is confusing (that is how I feel when I shop in online shops that do it). I also think it would be a bit more difficult to implement. However, showing the price of the different attributes before you select them is a must. I don't understand how it can be that this problem apparently ignored by Drupal Commerce which is extremely well thought through in most other respects.

from #1596250: Allow the showing of product price next to product title in product displays with multiple products - a duplicate issue

indeed could be a helpful feature, to have a formatter for the Product attributes with the Price included.
BUT there's a big IF.
What IF we have multiple distinct attributes fields for the product (color, size, material, etc.) so multiple selections to be made?

I've just changed the title as I'd put in a feature request

http://drupal.org/node/1596250

for the total price to be shown, which seems to be a subset of the functionality discussed here.

This is the one missing feature which made me choose ubercart over commerce; I'm sure I can't be unique in that.

These guys claims to have a custom code solution, which I tried here: https://gist.github.com/3884197, but that did not work for me. Maybe some of you guys are more clever.

@rszrama: are there any plans appear in the future versions of the DC attributes as in the Ubercart? I mean described in this topic the problem. This functionality is very lacking :(

It's just waiting on a patch; I'd be happy to put it in whenever. Probably the main difference that's kept one from appearing is the fact that our attributes are dependent on each other, whereas in Ubercart an attribute option could only make an independent alteration of the product price.

Yup, for each option in the widgets you'd need to figure out which product you end up with if you change just that value. Not impossible, but fiddly!

I've been thinking a bit about how this could be done. Here are the steps I came up with:

1. For the selected product, find all possible singular option divergences and the resulting product for each.
2. For the set of products found in #1, pass each through rules to calculate the sell price.
3. Modify the attribute options form elements to display the price differentials.

All of this seems quite doable, but perhaps may not be very performant. I wonder whether we could store some kind of pre-computed product-option matrix in cache to significantly speed up #1. Number 2 doesn't seem like a good candidate for caching since pricing rules may depend on environment-specific variables such as user roles. I suppose we could price out all referenced products on initial page load, and then cache them temporarily so that they wouldn't have to be re-calculated with each subsequent request. Number 3 should be straightforward.

For a couple attributes each with a couple options, I'd expect this to be reasonably performant even without caching. But if we're talking hundreds of possible combinations, adding this in could really bog things down.

subscribing

I'm doing this in a form_alter:

/**
 * Implements hook_form_commerce_cart_add_to_cart_form_alter().
 */
function CUSTOM_form_commerce_cart_add_to_cart_form_alter(&$form, $form_state) {
  // Add prices to attribute selectors.
  if (isset($form['attributes'])) {
    $entity = reset(entity_load($form_state['context']['entity_type'], array($form_state['context']['entity_id'])));
    foreach (element_children($form['attributes']) as $field) {
      foreach (field_get_items($form_state['context']['entity_type'], $entity, 'field_product') as $product) {
        $product = commerce_product_load($product['product_id']);
        $attribute = reset(field_get_items('commerce_product', $product, $field));
        $attribute = $attribute['value'];
        $item = reset(field_get_items('commerce_product', $product, 'commerce_price'));
        $price = commerce_currency_format($item['amount'], $item['currency_code'], $product);
        $form['attributes'][$field]['#options'][$attribute] = $attribute . ' ' . $price;
      }
    }
  }
}

there's a re-work of the previous solution (#20), which works only for "field_product" product reference field and for field attributes that has "value" property for its value.

/**
* Implements hook_form_commerce_cart_add_to_cart_form_alter().
*/
function CUSTOM__products_form_commerce_cart_add_to_cart_form_alter(&$form, $form_state) {
  // Add prices to attribute selectors only if there is only one defined.
  if (isset($form['attributes']) && count(element_children($form['attributes'])) == 1) {
    $product_attributes = element_children($form['attributes']);
    $entity = reset(entity_load($form_state['context']['entity_type'], array($form_state['context']['entity_id'])));
    foreach (element_children($form['attributes']) as $field) {
      foreach (field_get_items($form_state['context']['entity_type'], $entity, $form_state['context']['field']) as $product) {
        $product = commerce_product_load($product['product_id']);
        $product_wrapper = entity_metadata_wrapper('commerce_product', $product);
        $attribute_value = $product_wrapper->{$field}->raw();
        $price_item = $product_wrapper->commerce_price->value();
        $item = reset(field_get_items('commerce_product', $product, 'commerce_price'));
        $price = commerce_currency_format($price_item['amount'], $price_item['currency_code'], $product);
        if (isset($form['attributes'][$field]['#options'][$attribute_value])) {
          $form['attributes'][$field]['#options'][$attribute_value] .= ' ' . $price;
        }
      }
    }
  }
}

this will require a little patch for Drupal commerce (attached to this comment), will pass the product reference field name.
this should be work no matter of the fields names or types,
BUT only if there's only ONE product field defined as attribute - i can't imagine how this should work for multiple attributes.

i'll be back very soon, with a patch for this issue for Drupal Commerce - Cart. module

and here is the real patch for Drupal Commerce - Cart module:
- add new settings to the product's field instance, cart settings: display_price, display_price_position, display_price_separator
- use this settings in commerce_cart_add_to_cart_form() to add the price to attribute selection, according with them
- it will work for a single attribute only.
- it keeps the previous, even it wasn't needed here (but useful for other alterings).

here is a new patch that adds new value to the to form context : entity bundle.

these new values for the fom context are useful for other alterings: so we can get all the data about the field/instance/entity/displays settings, etc ...

ex. possible use : #1667642-1: Quantity decrease/increase functionality to be set in add to cart form formatter or .

A few notes here:

1. I'm not sure if this should be a setting in the attribute field itself. Other settings that affect the appearance of elements on the Add to Cart form appear in the display formatter settings of the product reference field. I can see an argument either way for whether or not to include the settings in the field form or the display formatter settings form. On the one hand, it makes plenty of sense for it to be a form level setting since you can only use the price values if you have one attribute field anyways. On the other hand, I could see a site using attribute fields that don't need all of them to differentiate price (i.e. fabric might but color wouldn't). It's an unknown... so maybe it's best to just leave it as is in the more flexible configuration place.
2. When adding new settings to info arrays, we need to be sure to use empty() or !empty() to check for their values. Right now, if I added your patch and didn't re-save my attribute field forms, I'd expect to get an undefined index notice in this if statement: if (count($qualifying_fields) == 1 && $instance['commerce_cart_settings']['display_price']) { because $instance['commerce_cart_settings']['display_price'] doesn't exist.
3. I'd probably do some cleanup to the way you've rewritten $used_options; in this case, if the variable is available in scope, we should probably just call it $options.
4. We've been slowly cleaning up the $cart_context variable that we're building to pass in to the Add to Cart form builder function. The more data we put in there, the quicker our form cache table bloats. I'd typically prefer to pass distinct directives into the form builder function regarding how the form should be built; that might be an argument in favor of making the appearance of prices here a form level feature instead of a field level feature.
5. Finally, I think it may just be too complex to make the separator and positioning configurable as is. Would it hurt to just use a tokenized string here? Or even just to use a default pattern in t() that could be translated to something else if desired?

thank you Ryan
let's try another patch that should have some answers to your last directions:

1. Move to Add to cart formatter - done
2. not anymore available
3. use $options variable instead of $used_options
4. Not yet - still there, used for other patch #1667642-5: Quantity decrease/increase functionality to be set in add to cart form formatter or .
5. Tokenizer Indeed - i think you were so right about it. So now there a token replacement so any of product data could be used.

Others:
- I kept the "Available only for single referenced product type with a single attribute defined".
- i create new helper function "commerce_cart_product_type_attributes" for getting the attributes fields of a product type.
- maybe some work about Token module : with and without.

and here is the patch

indeed there was some token code used, without checking is exists (& enabled).
here is a new patch that should correct this.

it seems that the formatted price (ex. [commerce-product:commerce_price] token) it's not available (working) without Token module.

i'm afraid that previous (2) patches are limited to one product type referenced.
What if there are several product types and only one product display for all of them?
And every product type has a different field defined as its attribute, then the solution above will not provide the response for this.

So i think the Token "formatter" should be moved to the attribute settings (field instance settings).
What else could be done in the "Add to cart formmater" it's maybe an extra option for the attribute display: default formatter or token formatter.

i'll be back soon with the attribute - Token formatter patch.

and here is a new patch that puts the attribute "Token formatter" in the product field instance attribute settings.

Questions:
- should the new "commerce_cart_product_type_attributes()" helper function introduced in #25 be kept?
- is there anything needed for the "Add to cart form" formatter, related with the attrbitutes "Token formatters"?

do you happen to have a screenshot of how this would look after its implemented? thanks!

back to #25 (#26) approach : use the "Add to Cart form" formatter settings.

i re-work the #26 patch.
The main change is the use limitation.
Previous : Available only for single referenced product type with a single attribute defined.
New : Only for multiple product reference, except for single referenced product type with multiple attributes defined.

Actually i think the tokenzing of product select options should be customizing alternative to products Attributes.
So maybe the limitation should for "single referenced product type with attribute(s) defined.

New patch attached.

It seems the "show_single_product_attributes" is used only with attributes, probably was better is we had
"show_single_product_options" as the machine name of the setting and use it also for no attributes case.

however, there is a new patch that use this setting also for product references without attributes defined,
for product selection.

i also changed the setting title/description to include both "product options" and attributes widgets.

I developed a patch that displays pricing for each displayed option (that isn't the equal to the current product). It should work for multiple attributes.

I applied patch #31 and get this error on my node page now:

Warning: in_array() expects parameter 2 to be array, null given in commerce_cart_add_to_cart_form() (line 2102 of .../jtea/sites/all/modules/commerce/modules/cart/commerce_cart.module).

version = "7.x-1.9"

Also, if the product attribute is missing, it shows up as a [product] field on the add-to-cart form, instead of displaying nothing.

there is a new patch that should cover the #34 and #35 issues.

@slavojzizek : thank you Sir

i don't think the failure of tests are related with this patch.

all the patches didn't worked for me.
something new?

@berin : what do you mean by the patches didn't work for you? please detail.
thank you.

Hello,

I think this patch not support multi currency yet?

Thank you.

Updated patch for HEAD on commerce.

Rerolled #44 against latest 1.x-dev #f830856

Reroll on latest 1.x-dev (3d898163)