Original language entity content got overwritten when updating translated entity for multilingual site

Changing to critical as this bug deletes node, paragraph contents.

Thank you so much to the OP for creating this issue report I broke my site a month ago and could not figure out which update it was.

For anyone with this issue, until their is a patch, use the alpha2 version by using

composer require drupal/conflict:2.0.0-alpha2

Glad it helped @mattea.turnbull! We were affected while updating one of Acquia's distribution lightning/workflow.

Rewriting title for easier understanding.

Thanks @mattea.turnbull. Downgrading to alpha 2 worked. We are using acquia/blt-project and with latest upgrade we moved to alpha 3 introduced issue.

I think I may have found a solution around the problem highlighted in this issue.

I am including a patch file for those that wish to use this immediately.

Basically, the proceedure conflict_entity_load() attempts to clone an entity that has yet to have been fully loaded. The problem is this entity is only partially complete when compared against the RouteMatch Object the form uses in certain instances. Imagine a Node or Taxonomy Term which is built using multilingual mechanism.

While inspecting the source of the complete object vs the cloned object I noted a lack of translation elements.

By ensuring the entity being loaded is in fact of instance TranslatableInterface we actually get a better cloned entity. Thus, resolving these incorrect conflicts.

Fixed the patched file. Seems to now want to apply properly.

Is there a category higher than "critical" ?

Would be nice to have automated test coverage for this but ya, critical fix that needs to go in asap, I suggest to put the fix in and follow up with a new issue to add automated test coverage.

Confirmed this is happening on several of our sites as well. Thanks for catching this, it took me some time to find out the conflict module was the culprit.

Confirmed patch #10 fixes the issue.

The patch works well however due to the lack of support in this project we've chosen to uninstall the conflict module instead of patch it.

I have sent a message to three project maintainers about this critical issue. I also sent messages to maintainers 2 months ago as well. This is a repeat.

@dww, @drumm and @hchonov have been notified of the severity of this issue. It absolutely must be resolved asap. Patch 10 works perfectly.

If this is so urgent and ready, why is the status only “active”?

I’m unavailable for the next few days, but I hope to take a closer look later this week.

@dww, it's RTBC+ by @wilco , @Martijn Houtman and myself. I assure you this is a critical fix that is needed and that patch 10 is the correct solution. It was a very tough issue to figure out and plagued two of the projects I worked on for several months before @wilco figured it out. I found a workaround which was to enable the editorial workflow on media entities. With that said, no one should be forced to use a workflow in order to prevent data loss.

Test scenario setup steps:

1. Install Drupal core 9.5.8
2. enable the content_translation module
3. Enable translation on a node bundle
4. Enable translation on a media bundle
5. composer require drupal/conflict
6. install the "conflict" module
7. DO NOT use workflow, do not install the workflow module
8. add a node of the translateable type, translate the media entity
9. add a media entity of the translatable type, translate the media entity
10. publish the media entity
11. publish the node entity
12. edit the node translation and publish it
13. edit the media translation and publish it
14. edit the node translation again, notice that it clobbers the other language
15. edit the media translation again, notice that it clobbers the other language
16. Delete your node translation, it will clobber the entity
17. Delete your media translation, it will clobber the entity

so, why is this critical?

• data loss on edit translation
• data loss on delete translation

To fix the problem:

three choices:

1. Uninstall the conflict module
2. Rather than uninstall the conflict module, use patch 10
3. Rather than use the patch, install the workflow module and add the entity into a workflow (workaround, but still breaks taxonomy term translation also).

The best fix is patch 10.

@dww , three lines of code is all that is needed, please have a look at patch 10.

FYI , all my projects no longer use this module because of this issue is being ignored. This is a critical issue that needs to be fixed and it's only 3 lines of code.

What does this module do and what are the consequences of uninstalling it. This was a major high stress event when this broke and I'd like to evaluate if I should drop it vs applying the patch.

@mattea.turnbull, either option use patch or uninstall the module will fix the regression. If you uninstall this module you won't have the regression however if you apply the patch you'll benefit from automatic conflict resolution if two people publish or edit a draft content at the same time.

Meanwhile I have put in a request to take over maintainership of this project.
#3381341: Offer to maintain the conflict module →

My offer to maintain this project has been ignored for more than 6 weeks after several attempts to reach the maintainers.

Pushing offer to the ownership queue.
#3381341: Offer to maintain the conflict module →

The current patch is altering in which language the entity is being loaded as snapshot in conflict_entity_load(). The cause is to be searched at the place that is using it and not loading it. This is only covering up the bug that might come up at a harder place to search for later. So please check about the usages of $entity->{EntityConflictHandlerInterface::CONFLICT_ENTITY_ORIGINAL}. If we would accept the current change then $entity->language() and $entity->{EntityConflictHandlerInterface::CONFLICT_ENTITY_ORIGINAL}->language() will return a different language which would be inconsistent.

Until this is resolved, maintaining recommendation to uninstall this module when using more than one language as this is a critical bug causing data loss.

There was a core commit made today that "might" improve this situation, I haven't tested it.

🐛 Creating a new translation may delete translations with drafts Fixed

With the patch I had been getting constant, 'you have a conflict' statements and stuff not saving in drupal 10.01. I have uninstalled conflict and that resolved those issues (previously in drupal 9.5 I never saw that dialog or had issues).

I also had to uninstall autosave_form (unrelated to this but it seemed to break in drupal 10.0.1 with multilingual site).

I am having issues where after I save French (my secondary language) it takes up to 5 minutes to display the saved changes onto the front end of the site (if you have any clue what updated with drupal 10 that would cause that?)

Mattea

I'm currently testing content_lock module as an alternative to using the conflict module.

We are currently trying to use #10 🐛 Original language entity content got overwritten when updating translated entity for multilingual site RTBC patch with Drupal 9.5.11. But it breaks jsonapi responses that check access to individual resources or unpublished translations, for example, with ERR_EMPTY_RESPONSE or '50x' server status code.

So I've improved it by using the 'entity_upcast' context to fix this, based on the jsonapi module code.

Hi mattea.turnbull, I went here because I already use Content Lock module coupled with Conflict module. Because Authors need to have ability to lock translation revision, not locking entire node. And I also have this problem.

Patch #31 seems like a very safe change to make with the extra validation compared with patch #11

joseph.olstad → credited Eduardo Justino → .

oops somehow authored by incorrectly credited, it was Wilco that did this patch, I got wilco and serg.linkin in the comments.

https://www.drupal.org/project/conflict/releases/3.0.0-alpha4 →

d.o removed the automatic author option, I must have put the wrong id in

Committed #31, tagged and released

Automatically closed - issue fixed for 2 weeks with no activity.