On commerce_product_product_form the language code will be empty if the product is a new entity. The form used to take this into consideration with

$language = !empty($product->language) ? $product->language : LANGUAGE_NONE;

However, with the entity translation integration, it now expects to get the language from entity_language, which may return NULL.

$langcode = entity_language('commerce_product', $product);

A simple check for null with a fallback to LANGUAGE_NONE should be added to ensure that a language code is always set on the form.

Files: 
CommentFileSizeAuthor
#1 commerce-product-form-language-1835708-1.patch701 bytesBassistJimmyJam
PASSED: [[SimpleTest]]: [MySQL] 3,570 pass(es).
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new701 bytes
PASSED: [[SimpleTest]]: [MySQL] 3,570 pass(es).
[ View ]

Patch attached.

I'm fine to commit this, because it appears to preserve the previous behavior, but I wanted to run a simply sanity check by you in light of the comments on the API function. Can you tell from the inline doc block if that same issue applies to us?

http://api.drupal.org/api/drupal/includes%21common.inc/function/entity_l...

Version:7.x-1.4» 7.x-1.x-dev
Status:Needs review» Fixed

Just ran into this issue myself using the Entity API metadata wrapper with a NULL language code on a product that did not have the language set to 'und'. Going to go ahead and commit this so it's in Commerce 1.6.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

The expr?:expr2 syntax is new in php 5.3, shouldn't be used when 5.2 works for almost everything else IMHO.

No worries, I changed it before I committed. ; )