Unable to change non-translatable field value on translatable content with content moderation enabled

This 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

Per 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.

function MODULE_NAME_entity_type_alter(array &$entity_types) {
    foreach ($entity_types as $entity_type)
    {
        $constraints = $entity_type->getConstraints();
        unset($constraints['EntityUntranslatableFields']);
        $entity_type->setConstraints($constraints);
    }
}

Does this code not do what I think it does (remove the validation everywhere)?

I 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:

    $node = $form_state->getFormObject()->getEntity();
    $is_original_lng = $film->get('default_langcode')->value;
    if (! $is_original_lng) { //we are in a translation form
        foreach ($form as $key => $field) {
            if (substr($key, 0, 6) == 'field_') {
                if (! $film->get($key)
                    ->getFieldDefinition()
                    ->isTranslatable()) {
                       $form[$key]['#access']=false;
                }
            }
        }
    }

I think that I will stick with #3

I 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

#3 works for me.

I 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.

Discussion about "status" field is here:
#2983961: Error adding translations to already accepted content moderation handled nodes

#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:

1. make the entity reference revision field untranslatable
2. add the code in #3
3. save entities that contain the wrong data
4. remove the code from #3 again
5. now the entites can be save without an problems

#3 Works with me.

@dbgilbert Thanks a lot.

#3 also working here. Spent ages trying to problem solve this one.

Cheers @dbgilbert

Triaging 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.

Same 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.

I have this problem on 8.7.6 too. Can we reopen issue?

I'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.

+1 for reopening.

I've used workaround using:

/**
 * Implements hook_entity_bundle_info_alter().
 */
function MODULE_entity_bundle_info_alter(&$bundles) {
  $bundles['node']['article']['untranslatable_fields.default_translation_affected'] = FALSE;
}

After that I was able to successfully save the node and remove the workaround.

Premek -- 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?

#3 solved the issue for us. Does this fix have any consequences?
Is it safe to simply remove the constraints?

hey 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!

Hi @nkraft

We used a custom module and implemented this hook:

/**
 * Implements hook_entity_type_alter().
 */
function MYMODULE_entity_type_alter(array &$entity_types) {
  foreach ($entity_types as $entity_type) {
    $constraints = $entity_type->getConstraints();
    unset($constraints['EntityUntranslatableFields']);
    $entity_type->setConstraints($constraints);
  }
}

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.

I'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.

The 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.

#28 solved my issue :-)
Thanks

I 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.

Created 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...

#28 worked like charm.

I 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 :)

Hi,

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 ?

#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

#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.

Hi, 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).

#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)

Same 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.

9.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.

#3 fixed the issue for me, using 8.8.12.

Same issue in 9.x version.
#28 working fine with 9.1.4 version.

#3 saved my life, thx!!

I 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.

IMHO #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.

#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.

Yup, same error as @Bessonweb.

@Bessonweb, does it happen with a Media field?

What I noticed, is that setting the '#access' key to true does not disable '#element_validation', this issue should help you @Bessonweb

So 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

Translatable elements
 File
 Alt
 Title

-- 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.

Thank 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 !

@yahyaalhamad I have a media field but not only. I have not tested without media field.

I going to see your issue. Thank you!

I 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..

I 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.

This is raw decision for solution #a) (from description of this problem). Needs review this patch.

Some changes in patch. Fixed failed test issue.

The patch #69 works well for me on D10.1.4

I'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('...').

Phew, a couple of iterations and I got all the test green. This is now ready for review.

As a bug will need test coverage to make sure it doesn't break in the future.

Uploaded a patch for composer patches.

Fyi: The patch file is the history of all commits. Better is to use just the diff for composer-patches.