Cart form attributes selects do not work with translated taxonomies/products

Here's a patch that seems to fix this issue. When loading the options, it checks if the entity translation module is enabled, and if so it takes the mild performance hit of loading the taxonomy terms as entities and pulling the names from there.

Now with better error handling. :)

OK, sorry for the re-testing, but I figured the problem had to be with the test suites, and was running it to see if it passed.

However, they seem to be passing for other patches. I'm more than a little confused, and if anyone's got any insight in why the tests are failing here, I'd love to know.

What's failing is the check for whether the order object was created and saved - my patch doesn't go anywhere close to saving order objects, but only tweaks the display of add-to-cart forms. And the tests all pass if I run them in SimpleTest in my environment - both in a real site using entity translation, and in a minimal Drupal install with entity translation disabled.

I'd really like to bring this in to Commerce (and know if it fixes the problem for other folks), so anyone smarter than me, I'd love to hear from you.

I've tried the patch and it seems to work. I would be great if it could be commited.

Super! #8 worked for me

Hello,

I tried patch #8, it didn't change anything. I have no idea why it does work for Sakhmed and mmtt and not for me.

Looking forward to more experiences from other people.

Best regards,
Mariska.

Not sure why this caused test failures; probably the target version. Updating.

I can reproduce the issue. Some additional info:
- The taxonomy vocabulary needs to use i18n_taxonomy translation, not entity_translation.
- The term reference field needs to be a product attribute.
- I'm using latest dev from everything.

The patch in #8 does not work for me. The attached patch does. The issue is related to EMW's buggy language handling.

+++ b/modules/cart/commerce_cart.module
@@ -2099,7 +2099,10 @@ function commerce_cart_add_to_cart_form($form, &$form_state, $line_item, $show_q
+            $column = reset($columns);
...
+            $used_options[$field_name][] = $field_value[0][$column];

Reviewing this, but based on other code examples, we could just do $columns[0]

+++ b/modules/cart/commerce_cart.module
@@ -2099,7 +2099,10 @@ function commerce_cart_add_to_cart_form($form, &$form_state, $line_item, $show_q
             if ($product_wrapper->{$field_name}->raw() != NULL) {
...
-            $used_options[$field_name][] = $product_wrapper->{$field_name}->raw();

Actually, various places use the "raw" value check. We should fix these for consistancy.

Here is a patch that removes usages of the product entity wrapper. Using the following core methods to retrieve the field value, the entity wrapper's "raw" method is no longer being used.

            $columns = array_keys($field['columns']);
            $field_items = field_get_items('commerce_product', $product, $field_name);
            $field_value = $field_items[0][$columns[0]];

+++ b/modules/cart/commerce_cart.module
@@ -2088,7 +2090,7 @@ function commerce_cart_add_to_cart_form($form, &$form_state, $line_item, $show_q
-                if ($product_wrapper->{$used_field_name}->raw() != $form['attributes'][$used_field_name]['#default_value']) {
+                if ($field_value != $form['attributes'][$used_field_name]['#default_value']) {

I see. This call on raw was from a different field, causing failures.

Here is an updated patch to fix that test failure.

#26 looks better and works just as well as #19 for me. The taxonomy terms appear translated now in the product attribute select.

However, the product fields (like price) are not updated when selecting another term if the language is not English. This might be a different issue though.

Getting rid of all product EMWs fixes the aforementioned issue too.

This looks good, marking it RTBC and assigning to rzrama for feedback on the decision to use things like reset($product_field_value[0]);. I don't see any other way, since it could be an option field, taxonomy term reference field, or entity reference field, which all have different value keys, but all have the value as the first key.

The approach seems reasonable, and in local testing with both an options field and a taxonomy term reference field as attributes, it all still functions properly. For maintainability, though, I think we should standardize on using a variable named *_items to hold the field_get_items() response and ones named *_value for the reset value. (The patch was only doing that in one place, so I updated it to do it in all of them.)

I'm a little nervous about hardcoding the 0 array key, buuuut we're talking about attribute field values that by nature should only be single value. If someone comes up with a failing scenario, we can just add an intermediate reset() to extract the first item from the items array. I'm only aware of items arrays being non-zero indexed in the event a multi-value field has some values removed without resetting the delta array.

We'll see what happens. : D

Tests passed. Committed.