Document the Drupal core version dependency for Commerce 1.4

This error comes when missing entity_language method in includes/common.inc file.

For me it was solved just adding this method after the archiver_get_info() method:

function entity_language($entity_type, $entity) {
  $info = entity_get_info($entity_type);

  // Invoke the callback to get the language. If there is no callback, try to
  // get it from a property of the entity, otherwise NULL.
  if (isset($info['language callback']) && function_exists($info['language callback'])) {
    $langcode = $info['language callback']($entity_type, $entity);
  }
  elseif (!empty($info['entity keys']['language']) && isset($entity->{$info['entity keys']['language']})) {
    $langcode = $entity->{$info['entity keys']['language']};
  }
  else {
    // The value returned in D8 would be LANGUAGE_NONE, we cannot use it here to
    // preserve backward compatibility. In fact this function has been
    // introduced very late in the D7 life cycle, mainly as the proper default
    // for field_attach_form(). By returning LANGUAGE_NONE when no language
    // information is available, we would introduce a potentially BC-breaking
    // API change, since field_attach_form() defaults to the default language
    // instead of LANGUAGE_NONE. Moreover this allows us to distinguish between
    // entities that have no language specified from ones that do not have
    // language support at all.
    $langcode = NULL;
  }

  return $langcode;
}

Linked to this post from http://www.drupalcommerce.org/discussions/4627/error-message-language-af...

Bojanz was nudged on this issue from within IRC and had this to say...

jostie: there is one reference in the bundled product module
As far as i could find thats the only one.
And I don't use kickstart for site creation
I don't know the core update policies all that well, but isnt te core api supposed to be locked after release?
bojanz: no. API additions are allowed
you're right, we added entity_language() to Commerce, so a note on the project page should be fine
there was a security release after 7.15 anyway, so everyone should have updated anyway (otherwise entity_language is the least of their problems)

Updated the project page and the release node.

Reprioritizing this as Bojan is right - with security updates, people should be updating, but it is a feasible update strategy to only patch the security holes. That said, there isn't a great way to declare core Drupal version dependencies - the only solution involves breaking sites that may be deployed from Git or Drupal 7.x-dev. The release notes for Commerce 1.4 are still forthcoming, so I'll be sure to document the requirement there - we had another one for hook_field_widget_form_alter() anyways.

If we really want to support earlier versions, we can revert that line from using entity_language() to $product->language, but I'm not sure we really want to support versions of Drupal the pre-exist security releases. We can discuss further.

Of course we don't want to support Drupal versions from before security releases.

As I said a few days ago, I think it would be fine to declare a specific dependency on a Drupal core version (so > 15 or something like that).
We've always had it (7.2, then 7.4 then 7.8 if memory serves me), but it was never explicitly defined.
Sure, it will cause problems for people using Drupal core straight out of git, but I think those cases are very rare today.

Web shops where money is involved don't want to have well known and publicized security holes either, so your point is moot. The last security release will always be an acceptable minimal dependency.

Hi

It's Drupal version problem . entity_language function not use in some low level drupal version like Drupal 7.13.
If you use Drupal 7.16 then function entity_language($entity_type, $entity) by default in includes/common.inc file. but Drupal 7.13 version module missing entity_language method in includes/common.inc file.

So add below function for includes/common.inc file after function entity_label

/**
* Returns the language of an entity.
*
* @param $entity_type
* The entity type; e.g., 'node' or 'user'.
* @param $entity
* The entity for which to get the language.
*
* @return
* A valid language code or NULL if the entity has no language support.
*/
function entity_language($entity_type, $entity) {
$info = entity_get_info($entity_type);

// Invoke the callback to get the language. If there is no callback, try to
// get it from a property of the entity, otherwise NULL.
if (isset($info['language callback']) && function_exists($info['language callback'])) {
$langcode = $info['language callback']($entity_type, $entity);
}
elseif (!empty($info['entity keys']['language']) && isset($entity->{$info['entity keys']['language']})) {
$langcode = $entity->{$info['entity keys']['language']};
}
else {
// The value returned in D8 would be LANGUAGE_NONE, we cannot use it here to
// preserve backward compatibility. In fact this function has been
// introduced very late in the D7 life cycle, mainly as the proper default
// for field_attach_form(). By returning LANGUAGE_NONE when no language
// information is available, we would introduce a potentially BC-breaking
// API change, since field_attach_form() defaults to the default language
// instead of LANGUAGE_NONE. Moreover this allows us to distinguish between
// entities that have no language specified from ones that do not have
// language support at all.
$langcode = NULL;
}

return $langcode;
}

Then above fetal error will not come in drupal commerce

The release notes and project page have been updated to indicate the dependency.

@joostpluijmers No problem if you update drupal in future then this functions are available in drupal latest version.