Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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 CreditAttribution: BassistJimmyJam commentedPatch attached.
Comment #2
rszrama CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: 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 CreditAttribution: rszrama commentedNo worries, I changed it before I committed. ; )