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.My use case:
I have a node type that configured to be non-translatable. This node type has a translatable field (the field is used on other node types and has to be translatable). Nodes of that non-translatable type are being created/updated automatically using entity API module. Simplified code looks like
if ($new) {
$node = entity_create('node', array('type' => 'my_node_type'));
}
else {
$node = entity_load('node', $id);
}
$wrapper = entity_metadata_wrapper('node', $node);
$wrapper->field_my_field->set($value);
On a new node language will be LANGUAGE_NONE. But value for field_my_field will be set with langcode 'en' (if default language is English). It is all because of the new condition in EntityTranslationDefaultHandler::getFormLanguage()
public function getFormLanguage() {
if (!empty($this->activeLanguage)) {
return $this->activeLanguage;
}
// For new entities the active language should match the default language.
// The language stored with the entity itself (for example, $node->language)
// may not be reliable since the function creating the entity object will
// not know which language "Entity Translation" is configured to create the
// entity in.
elseif ($this->isNewEntity()) {
return $this->getDefaultLanguage();
}
else {
return $this->getLanguage();
}
}
This method is called through a chain of calls from entity API module.
But when the same code updates existing field the method returns LANGUAGE_NONE since $this->getLanguage() is the language of non-translatable node. So, I get 2 'localized' values of the field on non-translatable node. This causes various problems (you see one value on edit form but another on a view).
In previous version in such case I had the value set on the field with langcode LANGUAGE_NONE. I'm not sure it is correct behavior, but at least it doesn't use same langcode for creation/update. So I decided to get back that logic by checking if the entity is translatable. Below patch solves problem in my case.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | 2864510-translatable-field-on-non-translatable-entity-2.patch | 676 bytes | sergei_brill |
Comments
Comment #2
sergei_brill CreditAttribution: sergei_brill commentedComment #3
sergei_brill CreditAttribution: sergei_brill commentedComment #4
stefanos.petrakis@gmail.comAnother way to tackle your specific problem (which is rather edgy) would be to explicitly set the entity translation's default language for your content type.
Could you have a go at this?
Comment #5
hoporr CreditAttribution: hoporr commentedJust for reference if somebody has the same problem:
We have seen this problem appear as part of a rule ( project rules), and the result was that the text format of that field was NULL.
We have a non-translatable CT, and within that CT the body field is shared and translatable.
When a new entity is created using the rule, the node was created as UND, but the field had the langauge of the user, such as 'en'.
This was the actual problem we saw: the text format of the body field was set to NULL!
The result was, that the display of the node showed an empty body field, but the edit form showed the body field filled in.
As a workaround, we did this in the rule:
1) Set the node to have an explicit language
2) Set the text format explicitly for the body field.
Comment #6
hoporr CreditAttribution: hoporr commentedPatch #2 above tested and it works.
This is a MAJOR problem.
We found several instances of this in our system; some are sneaky to find as some fields are not-required.
The problem only occurs at the first save. When you edit an existing node with that field, it then saves OK as 'und'.
The patch above also has a test in it for entitynew, so it addresses the problem.
Comment #7
hoporr CreditAttribution: hoporr commentedComment #8
jrusse27 CreditAttribution: jrusse27 commentedI'm having a similar issue where the I have some translated and some untranslated fields, the node view is working correctly, but the node edit form is always showing the default language field values.
This condition in getFormLanguage is not returning (no activeLanguage set):
if (!empty($this->activeLanguage))and so the form language is always returning the default language (language of the node):
The above patch does not fix the bug I'm experiencing, as is it is caused by $this->activeLanguage not being set.
Comment #9
joseph.olstadthis issue seems related to:
#2863794: Translated content is lost when cloning
we are using a patch from the said issue and no complaints yet. However I'm thinking of swapping it out for the RTBC patch #2 (above)
Comment #10
joseph.olstadI'm marking #2863794 as a duplicate of this one.
I prefer this RTBC solution. seems to work well
Thanks!
Comment #12
stefanos.petrakis@gmail.comThere has been an update to the code base that should fix problems of such nature, namely, when fields are shared between translatable and non-translatable entity bundles #2877074: Refactor the entity_translation_language() callback to make it bundle-specific.
I tried to reproduce the problem using the following code, with and without the changes coming from #2877074: Refactor the entity_translation_language() callback to make it bundle-specific.
Without the changes, I was able to reproduce the reported problem.
With the latest dev, the problem is not reproducible.
Marking this as outdated, thanks for reporting this!
Comment #13
joseph.olstadYes I believe this is likely fixed now. The environment that I originally observed the issue on has gone through an entity_translation_upgrade since I last reported on this issue and meanwhile many fixes have gone into entity_translation. I've now unable to reproduce the issue, however my test environments have changed since so it would take me more effort to change back my environment to retest and confirm. I'm agreeing to close this.
if someone notices an issue again they can always open a new issue and link it.