Problem/Motivation
There are cases where editing the entity can change the displayed information:
a) Changing the node title in a node reference field (Fixed in #2773043: Update the field widget after the Edit modal is closed)
b) Cropping a file in a image field
Proposed resolution
Refresh and update the edited row when the user finished editing.
Not sure how complicated this is, it is also not extremely important, just a nice to have.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | edit_button_should-2781131-8.patch | 1.35 KB | mbovan |
Comments
Comment #2
leksat commentedFixed in #2773043: Update the field widget after the Edit modal is closed
Comment #3
leksat commentedOr is this something different?
Comment #4
berdirI think so too. Thanks!
Comment #5
slashrsm commentedI tested it and it seems that we fixed this for entity reference field widget, but not for file/image one.
Comment #6
berdirCould be because we're missing the necessary attributes, which #2781125: Delete button in file browser widget not working might fix?
Comment #7
slashrsm commentedDoesn't seem so.
Comment #8
mbovan commentedProviding a patch that fixes image updates (in edit mode) such as file name. It's the same code from #2773043: Update the field widget after the Edit modal is closed.
However, not sure if the goal of this issue is to update the image on editing form (after cropping). Maybe not related, these are the possible issues:
FileBrowserWidget(entity_browser) is used to display the image and it's data. It provides "File view mode" and "Preview image style" options that are used to render the image on Edit form. Is this the enough to solve the problem or we would need to extend the list with "Use cropped image" option?Also, updated the issue summary.
Comment #9
slashrsm commentedEntity browser should update its widget to reflect latest state of the entity.
As far as I remember yes.
Entity browser shouldn't care if there was crop or not. It should simply reload entire row when edit has happened. If there were changes to a relevant crop it is up to IWC to make sure image will be rendered properly. As far as entity browser goes all changes are equal (crop, replacing image, changing filename, ...).
Comment #10
berdirYes, the HTML updates. The problem is that the browser is "too intelligent" and doesn't reload an image that was already fetched.
I don't see how we can solve that part in entity browser, the only reliable way is to find a way to alter the image style URL. We'll look into that.
Tested this, works.
Comment #12
slashrsm commentedOk. Committed.
Could we solve thumbnail issue with some javascript? However, let's do that in a separate issue.
Comment #13
berdirI lost one comment where I had a link to a JS based solution to do that. http://stackoverflow.com/a/22429796/560329. It's surprisingly complicated (you need to create an iframe and reload the image in there or something like that). And I have no idea which module would implement it... we have a combination of crop, image widget crop, file entity and entity browser here, most of those aren't supposed to know anything about the others, so who would provide JS for this special case.
I've re-activated #2658268: Cache persistence after derivative creation, lets try to continue there, it even already has a starting point for the alter-url approach that we need to try.
Comment #14
mbovan commentedAdded a patch https://www.drupal.org/node/2658268#comment-11617859 in #2658268: Cache persistence after derivative creation issue. Tested with entity browser, but doesn't seem to fix the problem with updating the image...