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.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | commerce-product-form-language-1835708-1.patch | 701 bytes | BassistJimmyJam |
Comments
Comment #1
BassistJimmyJam commentedPatch attached.
Comment #2
rszrama commentedI'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...
Comment #3
rszrama commentedJust 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.
Comment #5
peterjtracey commentedThe expr?:expr2 syntax is new in php 5.3, shouldn't be used when 5.2 works for almost everything else IMHO.
Comment #6
rszrama commentedNo worries, I changed it before I committed. ; )