When saving a translation of a content entity that has a untranslatable viewsreference field present, it seems that its possible that the massageFormValues method can lead to translations not being savable and always resulting in EntityUntranslatableFieldsConstraint hitting.
Specifically, in massageFormValues you have a call to serializeSettingsValues => https://git.drupalcode.org/project/viewsreference/-/blob/8.x-2.x/src/Plu... where you retrieve the views reference settings plugin definitions which are available. It appears that these definition can be returned in an inconsistent order (I'm actually not sure about this, but I don't know how else to explain this).
Below is a screen grab of two viewsreference field item values being compared (in this case, original entity field value compared against translation field value):
My current line of thinking is that the source translation of the content was saved at a time when the plugins were retrieved in one order, but down the line after a few cache rebuilds someone attempts to add a translation of the content (where this field is untranslatable and the field widget is hidden), they save, the aforementioned methods are invoked and a different plugin order is returned, thus resulting in a different serialized string compared to the source translation's version, and since the field is untranslatable this will trigger EntityUntranslatableFieldsConstraint.
Currently can't provide steps to reproduce.
A couple of options:
1. The best option probably is to extend EntityReferenceFieldItemList with your own implementation that specifically overrides the equals method in FieldItemList, and create your own comparison logic which is capable of breaking down the serialized string and comparing the array rather than a string.
2. In the views settings plugin manager, always sort the definition alphabetically before returning them.
Implement resolution 1.
None.
None.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | viewsreference-3238360-6-EntityUntranslatableFieldsConstraint-can-cause-issues.diff | 3.71 KB | briantschu |
| image-20210921-174948.png | 34.78 KB | lpeabody |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
lpeabody commentedSee the merge request for first stab at addressing this. It solved the problem for me. I'm not super aware of any side effects which might be incurred by recursively sorting the data property.
Comment #4
lpeabody commentedSetting to major since this can cause errors with no real way of working around it through the UI.
Comment #5
abrammWe've faced the same/similar issue while translating the node with an untranslatable Views Reference field inside Paragraph.
The most odd thing is that Drupal displays errors for sibling fields so it's hard to understand the issue is actually caused by a Views Reference (which is not even displayed on a form).
@lpeabody Thanks for your research and the patch, this have saved at least a half of my day :).
The PR #12 have solved my issue so setting RTBC status.
Comment #6
briantschuThis solved the issue for me as well. I'm uploading a patch file, so I can deploy this without the risk of potential further changes to the MR introducing issues.
Comment #9
seanbMerged, thanks!