Expected Result:
As an Admin, when I edit a translated version of a page with a collapsed paragraphs field, I should see a collapsed paragraph unless there is an issue with the item I referenced.

Actual Result:
When I edit a translated page with a paragraph reference field that should be collapsed, I see an open paragraph with a warning that the current item cannot be referenced even though the item in the field is a valid selection and the id doesn't match what is in the warning. The item id in the warning is actually the item selected for the default language translation of this page, not the translation I am currently editing. This warning does not stop me from publishing the page and everything else on the form works as expected.

Configuration:
This is on a multi-lingual site with a paragraph type with an entity reference filter in the following form:
- Content Type
-- Paragraph Entity Reference Field - Not translated (as is required by the paragraphs module)
--- Paragraph Type
---- Entity Reference Field with Entity Reference View Filter restricting to page language* and content type - Translated

To reproduce, create a page in the default language and translate it to a new language, setting valid items in the Entity Reference Field for both translations. When you edit the page in the secondary language you should get a warning as described above.

What is happening:
This appears to be a bug in paragraphs/src/Plugin/Field/FieldWidget/ParagraphsWidget.php in the formElement function, where this validation occurs:

if ($item_mode == 'closed') {
   // Validate closed paragraphs and expand if needed.
   // @todo Consider recursion.
   $violations = $paragraphs_entity->validate();
   $violations->filterByFieldAccess();

That bit checks to see if there are errors on any of the fields that are collapsed and then expand the paragraph form if there is an error. (Further down in this code the paragraph is set to open if there are violations).

The code seems to incorrectly validate the fields in the collapsed paragraph for the default language not the current language - This may be coming from the language set on the paragraph entity reference field which is the non-translatable paragraph (as is required by the Paragraphs module.)

So, when $paragraphs_entity->validate() runs, the item in $paragraphs_entity is the default language version of the paragraph, not the current translation. So the validation error messages are set and the paragraph is set to be opened when the form renders.

When the rest of the form renders, the paragraph is open but, at that point, it is no longer using the item loaded into $paragraphs_entity and is instead using the field in the form data itself which is the correct translated field.

To rephrase - during this whole process Drupal is accessing the paragraph fields twice:

  1. To validate them in a collapsed state to know whether to report an error and open the form or leave it closed
  2. To render the form if the paragraph is in edit mode

BUT due to when that validation noted above happens, Drupal is loading the object twice instead of loading it once and using the value in both places.

That is where the confusion comes in - the first time is incorrectly loading the default language version of the field and throwing the errors but the second time is using the form data directly and correctly has the translated field.

This is what results in the error message reporting on the default language value but the form still properly loading the current translation of the field.

NOTE: This improperly loaded default language data is only used to generate the warnings and open the form. Once the form loads the correct field data, the bad data is not included in the form submission - the form validation works properly and allows you to save / edit the form.

Proposed Solution:
Solving this is probably easier than describing how we encountered the problem. I haven't had a chance to dig into where / how the langcode is getting loaded here but it seems this just needs to be reworked so the code in the formElement function that loads $paragraphs_entity is aware of the language of the fields that will be loaded into the edit form.

Comments

amitchell-p2 created an issue.

miro_dietiker’s picture

Great extensive description, thx for the investigation.

What is maybe more work than fixing it, is writing a test. I would recommend starting with this test, expressing expectations and thus failing as long a the issue is not yet fixed.