Content moderation workflow changes against one language affect translations too

Marking #3117751: Unpublished revisions of multilingual node rollback unpublished revision of another language to default revision as duplicate.

I can confirm, if you will try to change moderation state which affect node status for original language content, will be made one new revision for every entity translated language.

Linking #3095414: Add the concept of workspace providers which is probably the long term way to fix this and all the similar issues in the core queue.

This is a duplicate of #3020387: Moderation state is the same for all node's translations in edit page

Hey everyone,

Any updates on this issue? We're facing the same problem here as well.

@rafaelrs, what version of Drupal do you use?

I am facing this EXACT same issue. Are we sure this is not independent of the supposed related issue?

Drupal core: 9.4.8

I am facing same issue but randomly. Published contents of the 'default language' is being reverted when non-default language is being published.

Drupal core: 9.2.21
Core features: Workflows, Multilingual
Contributed: Paragraphs

This issue should not be closed mapping to a Fixed issue.

Of possible interest, we solved this issue on our suite of sites by applying the patch found at: https://www.drupal.org/project/drupal/issues/2845144#comment-14574850

Regarding #19

We are also experiencing an issue, I believe it is what you are referring to. This is obvious on our site as there is a contextual filter set to create anchor links to paragraphs on each node. Occasionally a content manager will try to recover their work from an unpublished revision after the translation has been published by clicking "revert" on the revision they want. This borks the view, as the latest revision is becomes unpublished, and the view does not display unpublished content.

Steps to reproduce

• Content manager creates a new revision of default language and moves it to a non-publish workflow state.
• While the default language revision is still in non-publish workflow state, secondary language updates are requested for same node. Content manager creates secondary language updates and places them in non-publish state
• Secondary language updates are approved and published. By publishing the secondary language, existing default language revision is no longer classified as the "latest revision" and the content manager essentially loses their work.
• The revision is still in the revision history, so the content manager goes to the revisions screen and clicks on "revert" to revive the deleted default language revision.

All in all, this makes multilingual workflow very cumbersome and hard to follow when you are fielding multiple edits to a translatable node at the same time in different languages and have no way of knowing what the client will want published first.

There's no code started here, so this is more accurately "active" not "needs work". All issues should target version 11.x for now, and will be backported to the right branch(es) as needed by the core committers.

Sounds like this is still an issue, although based on #21 this might be duplicate with #2845144: Users without 'bypass node access' permission can't reference unpublished content even if they have access to it? Adding to the pile of related issues.

Regardless, tagging to be smashed...

We are a bit puzzled by the suggestion that this is a duplicate of #2845144: Users without 'bypass node access' permission can't reference unpublished content even if they have access to it as it does not seem related at all. Just in case, we tried the patch from there and it did not resolve our issue.

Yes I do think this is a critical issue, still active. Last and current project still have same exact problem.

I wanted to post again to try to be more succint and to describe it from the content manager's perspective.

Assume you have two languages, EN and ES, you have workflows, moderation states, translatable entities, etc:

1. Save a draft of a node in EN.
2. Save a draft of the same node in ES.
3. Publish the ES draft.
4. Content manager no longer has access to edit the EN draft in step 1, because it is no longer the "latest revision". They can still see this draft in the revision history but it's not editable. They essentially lose all their work.

Hope this helps.

@mdranove I see, thanks, that does sound like it relates to #2845144: Users without 'bypass node access' permission can't reference unpublished content even if they have access to it but I think that's not the same as the issue here.

Our issue is simply with the publish status of translations being updated. If you have a node with two translations, updating the publish status of one translation has unexpected effects on the other.

There are a few ways that this plays out, depending on whether publish status is translatable, but it doesn't relate at all to editors being able to access the content or not.

I am also facing this issue with D 10.2.4. Can anyone help us to fix this problem.

Steps to reproduce the issue:
1. Multi-lingual site with Custom Languages , enabled Workflows module to have draft, published & Unpublished states.
2. Create English content as published.
3. Translated English content to Portuguese and Published.
4. Trasnlated English content to French and Published.
5. Made some changes to Portuguese content saved as Draft.
6. Made some changes to French content saved as Draft. Portuguese Draft content changes are not showing now, showing published content.

If anybody else is banging their head against this issue, here was my quick fix, assuming that you only want unidirectional updates from English to other languages:

/**
 * Implements hook_ENTITY_presave().
 *
 * @param \Drupal\Core\Entity\EntityInterface $entity
 *
 * @throws \Exception
 */
function my_module_node_presave(EntityInterface $entity) {
  // Don't let non-english content disrupt any other languages.
  $active_langcode = $entity->language()->getId();
  if ($entity instanceof NodeInterface
    && $entity->isTranslatable()
    && !$entity->isNew()
    && ($active_langcode !== 'en')
  ) {
    $translations = $entity->getTranslationLanguages();
    foreach ($translations as $translation_langcode => $translation_language) {
      if ($translation_langcode !== $active_langcode) {
        $translation = $entity->getTranslation($translation_language->getId());
        $translation->setRevisionTranslationAffected(FALSE);
      }
    }
  }
}

Hey All,

Is there any patch available to fix this, because we are facing the same problem here as well?

A client reported this issue on a production website. It was certainly working "before", but i don't know which update triggered this.

One thing, it happens for me even as admin, so at least for my case it's not related to the user without "bypass node access" related issue.

edit: maybe related to paragraphs (and Paragraphs Asymmetric Translation Widget). I wasn't able to reproduce the issue when saving drafts in one page in both languages (fr and de). But as soon as I added a paragraph to the german draft it "pubilshed" a new revision of the previously published french page.

It seems that the "root" cause may come from any module which "wrongly" affect translation data on save.

I've added #3412626: Difference between the 'Paragraphs (stable)' widget and the 'Paragraphs Legacy Asymmetric' widget as related, since after switching my paragraphs fields to the Paragraphs Legacy Asymmetric widget, I can't reproduce the issue on new page/content.

I think I'm having this problem - although I'm not sure whether it's a bug with Drupal core revisions, translations, content moderation or paragraphs.

It's a major issue because it is causing draft unfinished content to be unexpectedly published when somebody edits a published translation.

Steps to reproduce:

1. Have two languages on the site, e.g. en and fr.
2. Create a published page in English with content in a paragraph.
3. Create a French translation of it and publish it.
4. Create a new draft for the English page, edit the paragraph, and save it (the published page remains unchanged).
5. Edit the published French translation (change anything in it), keep as published and save.
6. At this point, both the French and the English page will get new revisions for all paragraphs and the English page will take the content from the previous revision (the draft), thus putting it live unexpectedly.

Is this the same issue reported here, or should I make a new issue?

I don't think it's anything to do with paragraphs widgets as the previous post implies, because it happens even if you just edit the title and don't edit/expand any paragraphs.

The problem appears to be that whenever you edit any translation, Drupal will create new revisions for all translations, containing the same as what was in the previous revision. That's not a problem most of the time, unless you have a published page with a new unpublished draft. I am not sure of the reason for why it has been designed this way, it results in a lot of duplicate data in the database but I'm sure there is a reason for it.

Hello,
We are also facing the same issue in our site. We are using Content Moderation, Workflows, Multilingual, Paragraphs, Paragraph Library, and Inline Entity Form modules.

Steps to reproduce:

1. We have three languages : English, Korean, and Japanese.
2. Create an English page that includes a paragraph already promoted to the library and published.
3. Translate the English content into Korean, including the same paragraph, and publish the translation.
4. Translate the English content into Japanese, again using the same paragraph, and publish the translation.
5. Edit the Korean page, modify the paragraph, change its moderation state to Draft, and save the page.
6. Now, edit the Japanese page, modify the same paragraph, change its moderation state to Draft, and save the page.
7. At this point, we observed that the Korean paragraph unexpectedly reverted to its previously Published version, losing the recent changes.

Any help would be appreciated!

I've also come across what I think is the same problem, I see this problem when I get several drafts deep.

To showcase this from field values, I have a rich text paragraph that is nested in another paragraph, on a content type with 2 languages.

mysql> select * from paragraph_revision__field_p_rt_rich_text where entity_id='21147';
+-----------+-------------+----------+----------------------------+-----------------------------+
| entity_id | revision_id | langcode | field_p_rt_rich_text_value | field_p_rt_rich_text_format |
+-----------+-------------+----------+----------------------------+-----------------------------+
|     21147 |     1406283 | en       | <p>English V1</p>          | full_html                   | <—— English V1 draft (correct)
|     21147 |     1406286 | en       | <p>English V1</p>          | full_html                   | <—— Spanish V1 draft (correct)
|     21147 |     1406286 | es       | <p>Spanish V1</p>          | full_html                   | <—— Spanish V1 draft (correct)
|     21147 |     1406289 | en       | <p>English V1</p>          | full_html                   | <— English V1 published (correct)
|     21147 |     1406289 | es       | <p>Spanish V1</p>          | full_html                   | <— English V1 published (correct)
|     21147 |     1406292 | en       | <p>English V1</p>          | full_html                   | <— Spanish V1 published (correct) 
|     21147 |     1406292 | es       | <p>Spanish V1</p>          | full_html                   | <— Spanish V1 published (correct) 
|     21147 |     1406295 | en       | <p>English V2</p>          | full_html                   | <— English V2 draft (correct) 
|     21147 |     1406295 | es       | <p>Spanish V1</p>          | full_html                   | <— English V2 draft (correct) 
|     21147 |     1406298 | en       | <p>English V1</p>          | full_html                   | <— Spanish V2 draft (correct) 
|     21147 |     1406298 | es       | <p>Spanish V2</p>          | full_html                   | <— Spanish V2 draft (correct) 
|     21147 |     1406301 | en       | <p>English V1</p>          | full_html                   | <— Spanish V2 published (correct) 
|     21147 |     1406301 | es       | <p>Spanish V2</p>          | full_html                   | <— Spanish V2 published (correct) 
|     21147 |     1406304 | en       | <p>English V2</p>          | full_html                   | <— English V2 published (correct)
|     21147 |     1406304 | es       | <p>Spanish V1</p>          | full_html                   | <— English V2 published (incorrect)
|     21147 |     1406307 | en       | <p>English V3</p>          | full_html                   | <— English V3 draft (correct)
|     21147 |     1406307 | es       | <p>Spanish V1</p>          | full_html                   | <— English V3 draft (incorrect)
|     21147 |     1406310 | en       | <p>English V3</p>          | full_html                   | <— Spanish V3 draft (incorrect) 
|     21147 |     1406310 | es       | <p>Spanish V3</p>          | full_html                   | <— Spanish V3 draft (correct) 
|     21147 |     1406313 | en       | <p>English V3</p>          | full_html                   | <— Spanish V3 published (incorrect)
|     21147 |     1406313 | es       | <p>Spanish V3</p>          | full_html                   | <— Spanish V3 published (correct)
+-----------+-------------+----------+----------------------------+-----------------------------+

21 rows in set (0.01 sec)

This results in viewing "English V3" when viewing the published English node, when that field value doesn't exist in a published revision.

Any patch available to fix this issue?

I have a client that is seeing what looks like this issue on several sites. Intermittently what happens is that they start working on a node with En and Fr versions published. Then they edit the En and save it as draft, edit the Fr and save it as published. Go back to the En and find their changes are gone and need to revert them from a previous revision.

When the En draft content is lost, the revision that was created for the Fr seems to be marked revisionTranslationAffected in both En and Fr as shown below and the same vid shows on both the En and Fr revisions page - which I believe should never happen.

langcode status uid title created changed promote sticky default_langcode revision_translation_affected
en 1 1 TitleEn. 1520349494 1765834935 0 0 1 1
fr 1 1 TitleFr 1730222353 1765834935 0 0 0 1

I have a copy of their site with a node that does this 100% of the time. I tried the workaround in #28 and it worked - saving the Fr no longer wipes out the En draft. Not quite time to celebrate though - when I edit the En node now it won't save because its changed date is behind which triggers the EntityChangedConstraintValidator constraint and prevents the node form from being saved with the message, "The content has either been modified by another user, or you have already submitted modifications. As a result, your changes cannot be saved. " so I don't think the workaround is viable, but maybe it can give some insight on what is happening.

I have found a few instances where this will occur:

1. Adding a boolean field to a content type with existing nodes:
(a) create a new content type, set it to be moderated and translated
(b) add a node and publish the En
(c) translate the node and publish it
(d) create a draft of the node in En
(c) add a boolean field to your content type and DO NOT set it to translatable
(d) edit the translation and save it as published

Result: The draft En version will be superseded by the new translation revision which does not have the En draft changes.

I believe what is happening is that FieldItemList::hasAffectingChanges will do a count on the En and the translation items - the translation will return 1 and the original will return 0 so hasAffectedChanges returns TRUE, which will then incorrectly set the RevisionTranslationAffected on the En.

2. Adding the search_api_exclude module (my case) and enabling it on existing content - which adds a boolean field to the content-type thirdparty settings.
a) create a new content type, set it to be moderated and translated
(b) add a node and publish the En
(c) translate the node and publish it
(d) create a draft of the node in En
(e) enable search_api_exclude module
(f) enable search_api_exclude on your content type
(g) edit the translation and save it as published

Result: The draft En version will be superseded by the new translation revision which does not have the En draft changes.

I am not sure what other fields are susceptible to this issue, I testing with a plain text field that the issue does not occur. Also, if others find that what I am seeing is not the issue being reported here I will open a new ticket, if it is even a bug. I am not sure I have a workaround since modules like views_bulk_edit have problems updating moderated, translated content #3559935: Incorrect revision used to update moderated, translated content causes drafts to be published.