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.

#1 commerce-product-form-language-1835708-1.patch701 bytesBassistJimmyJam
PASSED: [[SimpleTest]]: [MySQL] 3,570 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


BassistJimmyJam’s picture

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

Patch attached.

rszrama’s picture

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?


rszrama’s picture

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.

peterjtracey’s picture

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

rszrama’s picture

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