The specified translation cannot be removed, when trying to change the default language of the node or creating a new translation

Hello @dimr:

This seems more major than critical. Thanks!

Cool.

Next step would be adding test coverage. The issue that added this change made a change in \Drupal\Tests\entity_reference_revisions\Kernel\EntityReferenceRevisionsCompositeTest::testCompositeRelationshipWithTranslationNonTranslatableField to test it.

What we need to do now is also trigger this scenario there. You could for example do that by changing the $node language to de and then save again at the end of the existing test.

Also a comment above the condition would be useful, to explain that we can not remove the translation if it is the default translation language.

I just found this issue today in our new site and applying the patch sorted the issue. Reviewed and ready to be merged imho!

@Andy_D The issue states correctly that it needs tests. We have a strict policy that bugfixes need test coverage and that's why it works so nicely stable for (almost) everyone.

Sorry, I have no idea how I should adjust the test, but patch in #6 works for me too.

Patch #6 works for me.

Works for me as well.

+++ b/src/Plugin/Field/FieldType/EntityReferenceRevisionsItem.php
@@ -324,7 +324,7 @@ class EntityReferenceRevisionsItem extends EntityReferenceItem implements Option
- if ($entity->hasTranslation($removed_langcode)) {
+ if ($entity->hasTranslation($removed_langcode)  && $entity->getUntranslated()->language()->getId() != $removed_langcode) {

Sorry, but maybe outbraking buerocracy in this case to wait for a test, in my opinion. This issue even affects user accounts who try to turn back to their original interface language > WSOD (no-go). This should be fixed immediately.

Can we please agree that in cases of needed ASAP fixes, advanced users are willing to provide these tests instead of commenting that tests are needed, especially in a major issue with many positive feedback regarding the patch? To wait until a newcomer has tackled down to write tests (and became a year older) can cause more user reports of broken sites and frustrated D8 haters.

I strongly recommend to let this in. The more stability argument because of tests is kind of ironic in the momentary situation, because D8 contrib has too many of such broken corners needed to get fixed ASAP. And many of them had tests. And are still broken.

BTW: Patch applied cleanly and no flaws yet in a complex set up.

@diqidoq That's not how Open Source works. As a maintainer and co-maintainer of i-dont-know-how-many modules we could spend all the rest of my life until i die with resolving major or maybe "critical" problems of others. And there will always come up something new, likely twice as many things as we resolved.

With composer you can even easily manage to use a module + a patch for your projects if it's critical to you and you need a temporary solution.

If we commit bugfixes like this, no one will later write tests because there's again something else that will be more major / critical that needs another quick commit...

With thousands of installations of Paragraphs, in case this is a "critical" problem for so many of them, there should be enough contributors that will immediately show up here and help fixing it, right?

As a CEO you can solve this problem! If something is urgent to you, hire someone qualified who can solve it for you in a way that sustainably supports the maintainers (like providing test coverage). Maybe consider working with the maintainers. Creating pressure or complaining without providing any incentive won't boost speed.

This is not how Open Source works.

I know how Open Source works ;-) At first it does not work the way saying "how it works". ;-)

But let's calm it down. You got me the wrong way, there was no complaining at all. Maybe because of not my native tongue. Maybe I choose the wrong words. Like we all do sometimes ;-) ... I usually am on the position explaining it like you do to me now :) But things are not fix. Principles are only as good as those smart people how are able to decide when these principles are helpful, and when not. Not saying in this case (that's why I've put it in question marks) but not too seldom enough, not to be considered. The comment function is there for discussion and thinking about the best way and to make individual decisions. And we do not so rarely broke our principles in core issues to get on more quickly for a moment ;-) ... Don't take it too personal when questions like this arise. Don't forget that all the motivation is for the project(s) (in my case at least, since I/we do not use this project we are talking about here).

And there is no need to explain to me how I/we can push things as a CEO. This is a lil' bit odd and people who know what I/we do (for Drupal), will find it odd too. If my comment put you under pressure, I apologize, since that was not my intension. My intension was speeding up Drupal 8 stability development from the users experience POV in both worlds: core and contrib.

Creating pressure or complaining without providing any incentive won't boost speed.

Agreed. You too? ;-)

This issue was simply not on my radar and we meanwhile discussed the problem and agree that it qualifies for priority critical, thus making it a release blocker.

@digidog: I was working on this together with @dimr at the DrupalDevDays Lisbon, she wanted to work on the test but didn't find time. I'm not expecting/waiting on anything, I simply didn't have time myself to work on this again since then.

#7 had pretty detailed instructions on how to write a test for this and I'm pretty sure it would have required less time from you to write a test than to write those long comments that don't benefit anyone.

HI, I've tested the patch and it looks fine!

Committed, thank you! :-)

@Berdir: I am expecting nothing eather. Only a little bit empathy for new users was my intension here. Sorry for the confusion, but advising me on this afterwards doesn't help eather. There is a complete misunderstanding here on the order of events. The long comment was a follow up explanation because my initial intension was something completely different (more positive) than that, what it was made of afterwards. It was just a suggestion in regard of the known uncertainty of new users regarding tests. And from the read of the comments before I wanted to stand up for them. Nothing else. No comlaints, nor any requests regarding the time of the issue, or if somebody is working on it or not. Just to support new users. Nobody can know who works on it if nobody tells. And as we can see now, you and somebody else worked already on it. But nobody knew that and would have maybe spend time to try hard in the same time than you while being new and uncertain with much more time spent than you maybe did. There was a very good comment on this kind of situations from a board member (I can't find the link no more) regarding how we should pick up new users in such cases and that was my initial intension. If this caused confusion, I apologize. All I wanted to do is (maybe on the wrong place) to prevent discouragement or shakiness of new users who do not know how to write a test, while being aware of the overhole time situation on the other hand. I didn't had the time by myself to write a test and writing comments costs not really much time and cannot be compared the way you did on me, who tries to be kind and explanatory and illustrative. But never mind. Thanks @all who worked hard on this issue!

Nobody can know who works on it if nobody tells.

We are always updating the issue queue when working on an issue. If it's a bigger task, a first update is provided after a few hours to avoid duplicate work. There was no ongoing activity in the period of silence. Being inclusive to new contributors and providing a clear situation is of highes priority to us.

Thank you for reminding us about the priority of this issue and the feedback. We apologise for the misunderstanding.

@miro_dietiker: And I sincerely apologize for the confusion, I have maybe caused. That was not my intension. Thanks for your and @berdir's time and infos and the integrating words. Very much appreciated.

Updated the title to include the additional problem of creating a new translation of a Node.

I had this same WSOD do to the can't remove translation error while simply creating a translation for a node today. Updating to V1.6 of this module fixed it.

Just trying to make sure people know it fixes both types of problems.