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.Hi again!
Looks like incompatibility with Entity Reference module appeared at some point in temps of re-writing Entity Translation.
Let's install Drupal 7.16, Entity Translation 7.x-1.x-dev (2012-Oct-15), ctools-7.x-1.x-dev (2012-Oct-12), entity-7.x-1.x-dev (2012-Sep-07) and entityreference-7.x-1.x-dev (2012-Oct-05). Now we'll create "Test" node type, with multilingual support set to "Enabled, with field translation", and with one additional field, "field_testref", of type "Entity reference". It must use default "Autocomplete" widget, it must allow us to add "Unlimited" number of values, and it's target bundles can be limited to "Article" node type, but latter is not necessary to reproduce this bug. "field_testref" should not be translatable, but Body field of "Test" node type should. We have to add at least two nodes of type "Article", let's say it'll be "Article1" and "Article2".
Now we'll try to add new node of type "Test". Let's set it Title to "Test title" and it's Body to "Test text". But BEFORE we will set "field_testref" values, we should switch "Language" from "Language neutral" to "English". AFTER that we should add two references with our "field_testref" field to "Article1" and "Article2". Now we can try to submit our node, and it'll be saved, but there will be no data at "Body" field. And if "Body" field would have default value assigned, there will be that default value, not user-entered data. If we'll edit this node, we can put to "Body" field any data we want, it will be saved correctly.
Only translatable fields are affected (including Title field, provided by Title module), untranslatable fields hold their values just fine. Only "Autocomplete" Entity Reference widget causes problems. If node language was changed after setting Entity references, there will be no problems. If there are fever Entity references, than x+2, where x is a number of pre-defined values (at Entity reference field), there will be no problems. I.E. in an example above we can set ONE reference (say, to "Article1"), and Body field will hold it's value. And in case we assigned reference to "Article1" as a pre-defined value for Entity reference field, we can make TWO references and all will be OK, problems will arise only if there are at least 3 references at one field.
It should be noted, that if we'll install Entity Translation 7.x-1.0-alpha2, there will be no problems.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | et-multiple_fields_broken-1819844-5.patch | 1.83 KB | plach |
Comments
Comment #1
bforchhammer CreditAttribution: bforchhammer commentedHm, strange bug. I was able to reproduce it, but I'm having a hard time figuring out why this is happening.
Comparing
$form_statevariables for a normal vs. the buggy form submission, fields are not properly processed for the buggy one, i.e. field values are not added to$form_state[values]. My guess is that it has something to do with processing the language change inentity_translation_field_attach_form(); on the other hand it's also rather strange that it only happens for >=2 references (what's so special about multiple values compared to single ones?) Could it be a bug in the entityreference module?.I will have another look later...
Comment #2
renat CreditAttribution: renat commentedNo, it's not Entity reference bug - I found out, that other fields with unlimited values allowed (in case we add new rows for new values with "Add another item" button, and not enter all of them in one row, for example) causes this problem just as well. It's, for example, core Text field. I checked other fields from the very beginning, but it was before I discovered all the shamanism you need to reproduced that bug, so didn't notice the problem. But, actually, it's there. So this bug is much more severe, than i thought initially.
Comment #3
plach:(
Comment #4
plachI was able to reproduce this with only core + ET, based on the OP. Working on a fix.
Comment #5
plachThis was caused by changing the form language on the wrong submit (the "Add another item" one). The attached patch moves the update of the form language to the proper place (just before processing submitted values).
Comment #6
bforchhammer CreditAttribution: bforchhammer commentedAwesome. Committed and pushed, thanks! :)
Comment #7
plach@renat:
Could you confirm the issue is fixed for you?
Comment #8
renat CreditAttribution: renat commentedYes, it is fixed, so I should really thank you and @bforchhammer.
Moreover, this patch also eliminated last problem, appeared after upgrade to ET -dev, which was not reported, because I assumed it was directly connected with this issue. Looks like there will be no more issue reports from me before beta1 release ;)