Unable to change non-translatable field value on translatable content with content moderation enabled, because of EntityUntranslatableFieldsConstraintValidator::validate
To reproduce:
1) Install D8.5.0 with the standard profile in EN language.
2) Enable content moderation on Article node type.
3) Enable 'Content Translation' (with dependent Language) module.
3) Add another language.
4) Enable translation of Article content type at Configuration --> Content language and translation, set all fields translatable, except Tags.
5) On manage fields, disable 'Users may translate this field' for Tags field.
6) Add new Article node, with e.g. 'Test' tag and publish content.
7) Create new draft on the created node and change Tags field - e.g. delete 'Test' tag, or add another one.
You wouldn't be able to save the node because of validation error:
Non-translatable fields can only be changed when updating the current revision.
Solutions:
a) the EntityUntranslatableFieldsConstraintValidator::validate() should check if the content isModeratedEntity() or
b) content moderation module should extend EntityUntranslatableFieldsConstraintValidator::validate()
Comment | File | Size | Author |
---|---|---|---|
#77 | 2955321-77.patch | 3 KB | tobiasb |
Issue fork drupal-2955321
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
amateescu CreditAttribution: amateescu for Pfizer, Inc. commentedThis is by design in Drupal 8.5.0. #2878556: Ensure that changes to untranslatable fields affect only one translation in pending revisions is the issue where this behavior was introduced, and these change records will help you understand what you can change to alter the behavior of non-translatable fields in entity forms:
https://www.drupal.org/node/2938191
https://www.drupal.org/node/2938193
https://www.drupal.org/node/2950608
Comment #3
dbgilbert CreditAttribution: dbgilbert commentedPer https://www.drupal.org/node/2938191 it should be possible to disable the validation that causes this error.
However I'm getting no luck with the below. Specifically targeting relevant entity_type (node) does not help either.
Does this code not do what I think it does (remove the validation everywhere)?
Comment #4
szato CreditAttribution: szato at Brainsum for Tieto commentedMy issue is about the original (EN) form. The new option 'Hide non translatable fields on translation forms' mentioned at https://www.drupal.org/node/2950608 solve mentioned issue. So it's not just 'Hide non translatable fields on translation forms', but fix validation on the original form too.
Comment #5
szato CreditAttribution: szato at Brainsum for Tieto commenteddbgilbert,
the documentation at https://www.drupal.org/node/2938191 is correct, it works.
You have wrong implementation regarding entity_type, you should have $entity_types[$entity_type] in foreach.I checked your code too, it works for me.
Comment #6
DuneBLI confirm that #3 is working well (I assume there is no side effect if content moderation is not used)
Before #3, I was hiding myself the translatabled field in form_alter with the following code:
I think that I will stick with #3
Comment #7
DuneBLI got the same problem in another site... this time it is with moderation content enabled.
As the option 'Hide non translatable fields on translation forms' is automatically checked (by content moderation), I had to use #3 to fix this problem...
I don't understand why we must remove this constraint manually when using content moderation.
I am not sure to get it... is it a bug? (I would think so because it is not possible to add a translated node)... but #2 say it is by design and is more knowledgeable than me...
I am lost
Comment #9
eloivaque#3 works for me.
Comment #10
maximpodorov CreditAttribution: maximpodorov commentedI also has this problem. I tried to dump the names of fields which trigger the error message, and the problem field is "status". In my configuration it is treated as non-translatable, and that is wrong.
Comment #11
maximpodorov CreditAttribution: maximpodorov commentedDiscussion about "status" field is here:
#2983961: Error adding translations to already accepted content moderation handled nodes
Comment #12
Lukas von Blarer#3 solved my issue of incorrectly translated entity reference revision fields for paragraphs. It seems that this approach can fix that by following these steps:
Comment #13
Omar Alahmed#3 Works with me.
@dbgilbert Thanks a lot.
Comment #14
danthorne#3 also working here. Spent ages trying to problem solve this one.
Cheers @dbgilbert
Comment #15
roadlittledawn CreditAttribution: roadlittledawn commentedTriaging in DrupalCon Seattle contribution sprint. Followed the reproduction steps in 8.7.0-dev and could not reproduce. Closing for now, but if someone else still experiences this, file an issue so we can take a look.
Comment #16
kirantej_p CreditAttribution: kirantej_p as a volunteer commentedSame problem with 8.7.6 version as well. Facing this error: " Non-translatable fields can only be changed when updating the current revision. " while modifying content for fields which are being used for translations.
Comment #17
ethomas08 CreditAttribution: ethomas08 as a volunteer commentedI have this problem on 8.7.6 too. Can we reopen issue?
Comment #18
nkraftI'm also experiencing this issue, though my issue seems to be centered around Paragraphs -- since the top level Paragraphs "entity reference" field cannot be set to be translateable (according to VERY specific instructions related to Paragraphs being translatable: https://www.drupal.org/docs/8/modules/paragraphs/multilingual-paragraphs... )...
Since that field CANNOT be made translateable, upon saving a a 'draft' using Content Moderation, I get the same error everyone else is reporting:
"Non-translatable fields can only be changed when updating the current revision."
This issue needs to be re-opened, please, @roadlittledawn ?
Additional notes: this is impacting my "Article" content type. So, I tried to make the entire content type no longer translateable... but I STILL get the error.
Comment #19
premek CreditAttribution: premek commented+1 for reopening.
I've used workaround using:
After that I was able to successfully save the node and remove the workaround.
Comment #20
nkraftPremek -- thanks for that tip!
Where did you add that code? In a custom module, or as a function in the *.theme file? This is the part that often isn't clear to me.
You said, too: "After that I was able to successfully save the node and remove the workaround." -- so once you removed that workaround hook/function you cited in your code block, you were still able to save the nodes of the 'article' content type without that translation validation preventing you from saving?
Comment #21
szato CreditAttribution: szato at Brainsum for Tieto commentedComment #22
apadernoComment #23
Falco010#3 solved the issue for us. Does this fix have any consequences?
Is it safe to simply remove the constraints?
Comment #25
nkrafthey Falco010 -- could you provide the exact code and method you used? IE, did you roll a custom module? Did you put it in your *.theme file as a function? A code example I could build from would be very much appreciated. Thank you sincerely!
Comment #26
Falco010Hi @nkraft
We used a custom module and implemented this hook:
EDIT: As an FYI, the above code is a very drastic workaround (and not advisable), as it simply removes (unset) ALL the "EntityUntranslatableField" constraints validation from every entity type.
Comment #27
chris.smith CreditAttribution: chris.smith commentedI'm uncertain what is causing the issue, but creating an example module with the entity_type_alter hooked as recommended above worked in my use case.
Comment #28
YahyaAlHamadThe way I solved this issue, I edited the original language and I saved immediately, then I went to translate the content. It might have happened to old content before we enabled content_moderation module.
Comment #29
Natom88 CreditAttribution: Natom88 commented#28 solved my issue :-)
Thanks
Comment #30
Sam152 CreditAttribution: Sam152 as a volunteer and at PreviousNext commentedI believe this belongs in content_translation.
It seems like potentially paragraphs should also have an issue filed to ensure, despite the fields translatable/non-translatable status, the widget should appear on node forms? It sounds like it would be an issue for all ERR fields.
Comment #31
orlando.thoenyCreated a module with the workaround, since it seems we don't have a solution approach for this yet.
https://www.drupal.org/project/remove_entity_untranslatable_field_valida...
Comment #32
mizage@gmail.com CreditAttribution: mizage@gmail.com commented#28 worked like charm.
Comment #34
Ghost of Drupal PastI believe this to be a duplicate of #3025039: New non translatable field on translatable content throws error or the other way around or whatever but I posted my patch there, so :)
Comment #35
apadernoComment #36
niknakHi,
I work with Content modreration and Content Translation. I have the same issue, I recreate a Drupal 8.9 site for testing the bug.
I have a content type "article", and just set the fields "title", "body" and "tags". Only "tags" field is translatable.
I create the source content but for my real situation, this content is not published. Drupal create a revision with the ID 47.
After this, I create the translation content (I change only the title and the body), and I publish. Drupal create a revision with the ID 48
For the moment, there is no problem yet.
Then I change the "tags" field, I adding a new value. I Still not publish this content source and the ID of this new revision is 49
this is where it gets complicated
If I use the fix code in reply #26 In the translated content, when I modified the node form, the field "untranslatable" is displayed. But the last value of the source content (in the last revision) isn't showed. The node form display the value of "tag" field from the revision 47 not 49.
And with or without the fix code, when I display the content translated (published) the value of "tags" field is the same of the content source revision corresponding to the first publish content translation (47) not the last change (49).
I am using content moderation badly or there is a real bug ?
Comment #37
niknakComment #38
joris_lucius#26 seems to be solving my problem with the error "Non-translatable fields can only be changed when updating the current revision.", thanks!
Top level I use Drupal 9, Paragraphs, 'Nested paragraphs', Content Moderation (the default 'Editorial'), Content -and interface translation modules
Comment #39
cristian100#26 solved my problem with the error "Non-translatable fields can only be changed when updating the current revision.", this issue started happening on a site that initially didn't had Content Moderation module enabled, and after configuration of the module, this issue appeared.
Comment #41
c.dodaro CreditAttribution: c.dodaro commentedHi, I have Drupal 8.8.8 and I received this error:
Non-translatable fields can only be changed when updating the current revision.
I received the error when saving a new revision in one language; I tried in other language and I received the same error.
So, I saw the "revisions" pages for each language and I found one of these pages (only of one language) with one anomaly: the page show me two "current revision".
I think that was what caused the error.
I cleared the cache, the second "current revision" has shown correctly like a (normal) revision, and than I could save the node (and the new revision).
Comment #42
itamair CreditAttribution: itamair commented#26 fix looks very drastic to me (and not advisable), as it simply removes (unset) ALL the "EntityUntranslatableField" constraints validation from every site entities, isn't it?
In my case, the fix was found according to the following Drupal.org comments:
https://www.drupal.org/node/2950608#comment-13664722
https://www.drupal.org/project/drupal/issues/2955321#comment-12644644
properly setting/checking 'Hide non translatable fields on translation forms" on the affected Paragraph type (as it seems to be a sort of forced condition by "Content Moderation" module on Contents, that should be manually replicated on Paragraphs types)
Comment #43
Civette CreditAttribution: Civette commentedSame issue with D 9.0.7
Unchecking "Hide non translatable fields on translation forms" makes saving the translation possible for all fields, translatabl eor not.
Having many fields for my concerned content type, "Hide non translatable fields on translation forms" option is really helpful.
I assume that discarding the constraints is not the right fix.
Comment #44
Civette CreditAttribution: Civette commented9.1.0 suffers same issue.
It becomes really annoying when content moderation is enabled as Hide non translatable fields on translation forms option is enabled and can't ne disabled.
Comment #45
smulvih2#3 fixed the issue for me, using 8.8.12.
Comment #46
ThirstySix CreditAttribution: ThirstySix as a volunteer and commentedSame issue in 9.x version.
#28 working fine with 9.1.4 version.
Comment #47
DarkteK CreditAttribution: DarkteK commented#3 saved my life, thx!!
Comment #48
s_leu CreditAttribution: s_leu commentedI agree with #42. The hook is an overkill and may have unwanted side effects. In my case the problem was due to having the moderation_workbench module enabled.
I was also able to fix it by enabling the "Hide non translatable fields on translation forms" for all content types and paragraph bundles. This seems much less invasive and can't do much harm it seems.
Comment #50
wranvaud CreditAttribution: wranvaud at Phase2 commentedIMHO #28 is the easiest way around the issue although it fixes only one node at a time. It's also probably the key to finding a definitive solution as well.
Comment #52
Bessonweb CreditAttribution: Bessonweb commented#28 was working for me before to upgrade in D9, but since my upgrade, it not work.
Also, the translated content say "[name of the field] field is required." and the content won't save
It's very bad.
I go to test the module in #31 to see if that fix the bug.
Edit : It not work!
I have also tested #19 and #26 with no success.
Comment #53
YahyaAlHamadYup, same error as @Bessonweb.
Comment #54
YahyaAlHamad@Bessonweb, does it happen with a Media field?
Comment #55
YahyaAlHamadWhat I noticed, is that setting the '#access' key to true does not disable '#element_validation', this issue should help you @Bessonweb
Comment #56
meangreen CreditAttribution: meangreen commentedSo with me, my use case was a little bit different than this ticket (with an image), but I was getting that annoying "Non-translatable field elements can only be changed when updating the original language."
I had enabled the image field to be translated (checked "Users may translate this field").
HOWEVER, when I scrolled down towards the bottom of the field configuration I had to check under "Translateable elements" the "File" and then 3 checkboxes checked below
-- I realize this might not directly relate to this ticket, but I just thought I'd post this, (in case some poor soul is frustrated because the translations won't save). In my case I had to track down this bugger and it cost me an afternoon to figure this one out.
Comment #57
szato CreditAttribution: szato at Brainsum for The International Federation of Red Cross and Red Crescent Societies (IFRC) commentedLast MR patch from New non translatable field on translatable content throws error (3025039) fixed my issue.
Comment #58
dollars0427 CreditAttribution: dollars0427 commentedThank you for #57 report. I had tried the #53 patch from New non translatable field on translatable content throws error (3025039), but I still cannot fix the problem :(
I am using paragraph 8.x-1.x-dev. Anybody get fixed of this problem too ?
Thank you !
Comment #59
Bessonweb CreditAttribution: Bessonweb commented@yahyaalhamad I have a media field but not only. I have not tested without media field.
I going to see your issue. Thank you!
Comment #61
xjmComment #62
liquidcms CreditAttribution: liquidcms commentedI tried the code from #26 and it "fixed" my issue but after hours of debugging, i realized it causes this issue: #3311304: Parent entity doesn't load (edit form) or save fields from latest paragraph revision if the fields are not translatable..
Comment #64
ratvas CreditAttribution: ratvas at CTI Digital commentedI highly recommend to avoid solution #3 (or #26) as removing constraints is not a solution, but workaround which can cause other issues.
Solution still needs to be found, or at least more precise log message in order to point developer in a right direction.
In my case, I was going through the /admin/config/regional/content-language list and check one by one entity and field so that brought me the result. I had some iframe field checked for translation and unchecking that field allowed me to translate content without issues.
Comment #66
bvakulin CreditAttribution: bvakulin as a volunteer and at GOLEMS GABB, Drupal Ukraine Community for GOLEMS GABB, Drupal Ukraine Community commentedThis is raw decision for solution #a) (from description of this problem). Needs review this patch.
Comment #67
bvakulin CreditAttribution: bvakulin as a volunteer and at GOLEMS GABB, Drupal Ukraine Community for GOLEMS GABB, Drupal Ukraine Community commentedSome changes in patch. Fixed failed test issue.
Comment #69
bvakulin CreditAttribution: bvakulin as a volunteer and at GOLEMS GABB, Drupal Ukraine Community for GOLEMS GABB, Drupal Ukraine Community commentedComment #70
brandonlira CreditAttribution: brandonlira commentedThe patch #69 works well for me on D10.1.4
Comment #73
jurgenhaasI've turned this into an MR and fixed some code style issues from the patch.
However, the PHPUnit tests are failing since the new code requires a service which is not available in the test context. I guess, this needs dependency injection instead of loading the service with
\Drupal::service('...')
.Comment #74
jurgenhaasPhew, a couple of iterations and I got all the test green. This is now ready for review.
Comment #75
smustgrave CreditAttribution: smustgrave at Mobomo commentedAs a bug will need test coverage to make sure it doesn't break in the future.
Comment #76
JeroenTUploaded a patch for composer patches.
Comment #77
tobiasbFyi: The patch file is the history of all commits. Better is to use just the diff for composer-patches.