I'm carrying an issue where I have 2 fields images and the second image get the first images and when I the content it override the second image for the first one.

I'm trying a way to replicate the problem, but at least I could start describing my setup.

I've this modules installed and enabled.

- paragraphs
- embed
- embed_entity
- entity_browser
- file_browser

I start creating the paragraphs types. I create two types. First the Image Item, where the fields is an image with the widget form "file browser". And a second paragraph that relate the first paragraph to add many images. Then I add a paragraph field in the content, lets say Article form the standard installation profile. When I click to add two images it work perfect. But when I edit the node the second image fetch the first image and if I save that the second image get override in the process.

What could be the issue with it? Before I didn't have this problem but I'm not sure if with the last update something start to get messy with it. What could be ?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

killua99 created an issue. See original summary.

slashrsm’s picture

Status: Active » Postponed (maintainer needs more info)

I don't completely understand your problem. Could you attach few screenshots? Which version of entity browser are you using? Try -dev if you didn't already.

killua99’s picture

Yes all the modules are in dev, and Drupal 8.0.3

killua99’s picture

Well the effect is like this.

jonathanshaw’s picture

I think you may be right in your comment on #2631590: After previewing an entity with nested paragraphs, EntityChangedConstraintValidator sometimes leaves a node entity un-saveable that this issue is related to that, and is therefore a Paragraphs issue not an Entity Browser issue.

However, when I try I can't reproduce the issue you're describing (which is typical of #2631590: After previewing an entity with nested paragraphs, EntityChangedConstraintValidator sometimes leaves a node entity un-saveable).

Can you provide exact and tested steps to reproduce the behaviour you see using simplytest.me?

It would be a huge help if you could. We could then confirm whether or not the issue is with Paragraphs, and move issue to that module's queue.

killua99’s picture

Yes I tried to use simpletest.me but the issue is, File Browser use a few JS library to be able to work, so the module doesn't install it self.

I deactivate the widget "File Browser" I'm using a field Image, and File Browser (module) add an extension to use entity browser on a image field. So recapping, when I deactivate the widget File Browser in the Form View, the images start looking right. So I'm guessing isn't the paragraphs it self doing something wrong. Might be a Mix with Entity Browser and File Browser.

slashrsm’s picture

As @jonathanjfshaw already mentioned it would be great if you could provide clear reproduction steps. This would help us to make sure we are all on the same page and we all understand this issue correctly.

killua99’s picture

I guess I found the issue I add another issue here.

#2681227: Entity Browser in adition with File Browser doesn't handle well the render cache.

My thought in my investigation are the Storage tag is always the same with fields like paragraph with the same name are called so we get the duplication render.

reekris’s picture

I also have the issue of image fields getting duplicated and populated automatically from other references when adding new ones. I get this issue when there is an image field using the entity browser widget in a Paragraph entity and also when using Inline Entity Forn to reference entities containing image fields.

You should be able to reproduce the issue following the steps below:

1. Fresh install of Drupal with Entity Browse (dev), Entity Browser Example and IEF (dev) installed
2. Create a field on Article referencing "Entity browser test" items. Set unimited number of items and form display to IEF complex.
3. Create a new Article node and add a new "Entity browser test" entity by clicking "add new node". Populate the first "files" field with an image and save the node.
4. Save the Article node.
5. Edit the Article node again.
6 Click "edit" on the referenced node created in step 3.
7. Click "Cancel"
8. Click "add new node" to start creating another "Entity browser test" entity.
9. The new reference will now have the "files" field prepopulated with the image from the first entity.

This was the easiest way I could find to reproduce the issue. Hopefully it's clear enough :)

@kilua99 Have you gotten any further in your investigation of the issue?

killua99’s picture

Status: Postponed (maintainer needs more info) » Needs work

No that much I'll like to continue debugging this.

I did a small debugging and I saw the CacheStorage for the Render doesn't have the proper name. Fields always have the same name so if we have the same field for example: field_image so the CacheStorageTag will be, paragrah.field.field_image so when it get call it again it render that Cache Tag, we need something like uuid field for that form to write the CacheStorageTage.

I saw a PR in github that said something about "context" no idea if that PR could solve this issue.

Also I'm going to put this as Needs Work because the bug is confirmed and with instruction to replicate it.

Links to keep on track.

https://www.drupal.org/node/2678866#new
https://github.com/drupal-media/entity_browser/pull/145

jonathanshaw’s picture

I can reproduce using the steps in #9.
I tried to reproduce without entity browser, to see if it was an IEF issue, but I could not.

javivf’s picture

Status: Needs work » Needs review
FileSize
1.35 KB

I solved with this patch, I used entity data insted form_state data

reekris’s picture

The patch in #12 seems to work for me. Since applying it I haven't been able to reproduce the issue. Great job @javivf!

arknoll’s picture

Category: Support request » Bug report
Status: Needs review » Reviewed & tested by the community
FileSize
1.32 KB

Patch worked for me. I updated for some code quality changes. Marking RTBC.

jonathanshaw’s picture

Ralf Eisler’s picture

This patch from #14 worked for me as well.

Could it be implemented in future releases?

chr.fritsch’s picture

Works here as well. +1

slashrsm’s picture

Status: Reviewed & tested by the community » Needs work

Hunk that we're changing here was added to fix another bug: #2667448: Field widget can potentially lose information about selected entities in case of unrelated AJAX requests. This patch re-introduces it.

+++ b/src/Plugin/Field/FieldWidget/EntityReference.php
@@ -282,7 +282,9 @@ function formElement(FieldItemListInterface $items, $delta, array $element, arra
     // IDs from a previous request might be saved in the form state.
     elseif ($form_state->has(['entity_browser_widget', $this->fieldDefinition->getName()])) {
-      $ids = $form_state->get(['entity_browser_widget', $this->fieldDefinition->getName()]);
+      foreach ($items as $item) {
+        $ids[] = $item->getValue()['target_id'];
+      }

It is strange that we do empty check on form state and load values from $items after that.

Would another elseif work?

killua99’s picture

We're using this patch since we found it and submit it, and we're not having that lose data on any ajax callback. How could we test it??

slashrsm’s picture

See the issue that I linked. There are steps in there.

dawehner’s picture

FileSize
2.21 KB

Here is an alternative patch which should not reintroduce the problem described in #2667448: Field widget can potentially lose information about selected entities in case of unrelated AJAX requests

The idea, @slashrsm and myself talked about using simply a more unique key in form state.

dawehner’s picture

Status: Needs work » Needs review

.

ooystein’s picture

I'm using the patch from #21 and it seems to work fine for me!

  • slashrsm committed 3d86431 on 8.x-1.x authored by dawehner
    Issue #2671378 by dawehner, arknoll, javivf, slashrsm: Make sure form...
slashrsm’s picture

Status: Needs review » Fixed

Committed. Thanks!

Status: Fixed » Closed (fixed)

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