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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

BassistJimmyJam’s picture

Status: Active » Needs review
FileSize
701 bytes

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?

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

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. ; )