Problem/Motivation
I hope I am not hunting ghosts because the steps to reproduce are quite simple for no one ever coming across this.
The source of this issue comes from #2644468: Multiple image upload breaks image dimensions, which fixed a bug with the image dimensions leaking.
However, it does cause an issue with multilingual sites when using the "Flag other translations as outdated" checkbox under certain conditions (see below).
EntityUntranslatableFieldsConstraintValidator compares each untranslatable field's submitted value against the stored one via FieldItemList::hasAffectingChanges(). Since image fields store the dimensions, we get the "Non-translatable fields can only be changed when updating the original language.".
- The previous fix should not be reverted - fixes a genuine issue as far as I can see.
Steps to reproduce
- Install language and content_translation; add a second language.
- Enable translation for Article. On /admin/config/regional/content-language, tick "Hide non translatable fields on translation forms" for Article - this is what makes isDefaultTranslationAffectedOnly() TRUE, which the validator requires.
- Make field_image untranslatable. (note that you may simply create a new node type instead and a custom field anyway)
- Create an article. Add an image. Save.
- Create a translation for the article. Change the title (translatable). The image should not show in the form. Save. That passes fine.
- Edit the original language. Click the "Flag other translations as outdated". Press Save (this translation). No need to alter anything
Expected outcome:
Entity is saved. No changes are detected.
Actual outcome:
Non-translatable fields can only be changed when updating the original language.
Proposed resolution
I am normally very reluctant in just adding a class in core for something that basic because as I said, it is weird to me that this has gone undetected (IF I am correct). But I think a new item list for the image field should be created that handles the values it needs to check for comparison.
Issue fork drupal-3620837
Show commands
Start 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:
Comments
Comment #2
dimilias commentedNote, that there is a second issue hidden here that we faced in our project. The problem is also coming up in another case, and that is if you save a node programmatically, and in the image field, you only submit the
target_idandaltwhich makes the title to be stored as NULL. There is no database exception for this or any validation issue but during the comparison, there is an array filter that filters out null values. And then the value from the form is just ''.My biggest concern though is that I am not sure if a constant is a good way of filtering on which properties to compare. That will exclude any custom module's custom defined properties :/
I am giving it a first shot as it is.
Comment #4
dimilias commentedComment #5
claudiu.cristeaComment #6
claudiu.cristeaI have some remarks in the MR https://git.drupalcode.org/project/drupal/-/merge_requests/16994
Comment #7
ironnuts commentedComment #8
ironnuts commentededit: The current steps to reproduce mention the article content type which has been removed from standard profile installation. Either mention running the drush command to run the recipe that installs the article type or search and replace 'article' with 'node'.
We also need to apply the IS template.
Comment #9
dimilias commentedFixed remarks.
Comment #10
ironnuts commentedCode comments have been resolved. RTBTC.
Comment #11
ironnuts commented