Problem/Motivation
The file browser widget already made quite a journey. It started in file_entity, then it was copied to file_browser and changes were made so it works also without file_entity. Support for an image preview style, showing the filename column and more.
But the logic there isn't very reliable when file_entity is not installed (doesn't check if a view builder exists, hardcodes assumption that view_mode == default means to show the image preview instead).
And when file_entity is installed, then you have the filename duplicated, as that is, at least in our case, also shown in the rendered entity preview.
There is also a bit of unnecessary code, e.g. parsing the image to get width/height when that information is already available on the field item.
Proposed resolution
1. Switch view_mode == default check with a !$has_view_builder check. Also check that one exists before calling ->view() (e.g. for file fields).
2. Hide filename column when there is a view bilder
3. remove image factory
4. Build header and rows dynamically as amount of columns can vary now
Especially 3 and 4 make the patch quite big as I have to move around a good amount of code.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 8.1.0-alpha9.png | 19.1 KB | glynnr |
| #18 | 8.1.0-alpha8.png | 55.12 KB | glynnr |
| #15 | entity-browser-2784199-15.patch | 10.14 KB | berdir |
| #12 | entity-browser-2784199-12-interdiff.txt | 4.58 KB | berdir |
| #12 | entity-browser-2784199-12.patch | 13.46 KB | berdir |
Comments
Comment #2
berdirHaven't tested this yet without file_entity (both file and image fields should be checked), but for file_entity, this seems to work fine now.
I'd be fine with waiting on having test coverage for this, I just need a patch to fix the regression in the UI for our client (mostly the duplicated filename). Or we could commit it after manual testing and mention in the other issue to test with and without file_entity.
Comment #6
berdirDidn't apply because my patch was on top of the delete button.
Comment #7
samuel.mortensonAs I'm not a File Entity user I haven't run into a lot of these issues, but the code in the patch makes sense to me so far. I'll need to manually test with File Entity, Core, and existing sites using complicated modules like File Browser before RTBC'ing. For now I did a short review:
We do this hasViewBuilderClass check a few times, can we move it to the top of the function and put the result into a variable?
Nitpick, but we'll need to remove the import for ImageFactory as well.
Nit, comment needs to be indented, and s/Had/Add/, and move above if statement to match the next comment.
I think this block can be consolidated, from reading this it seems like there could be a $display present, but if there's no view builder the entity label is used instead, which I think is unintended. Maybe just an else would work? I would also be happy with any additional change that makes the conditionals more readable and condensed, this widget has a lot of variations.
Comment #8
samuel.mortensonThe manual review went well, I don't see any issues so far when using this patch. When testing File removal, make sure you apply #2786851: Removing entities in FileBrowserWidget is broken first as the remove button is currently broken in Entity Browser HEAD (but works in 8.x-1.0-alpha7). Once my review is addressed I can RTBC :)
Comment #11
slashrsm commentedPatch needs re-roll after recent commits.
Comment #12
berdir1. Yes, I could see that you prefer local variables :) It is exactly 2 times in this method, personally I find that's not enough to require a local variable but changed now.
2. Fixed
3. Fixed
4. The code had a bug which made you think it can be just an else but no, I don't think that is possible. There are 4 cases to support bascially (two are the same). with/without file entity and file/image field type:
1. file_entity + image: show rendered file only
2. file_entity + file: show rendered file only
3. no file_entity + image: show preview *and* filename
4. no file_entity + file: show filename only
The tricky case is 3, where we actually show two fields. My mistake was to use the display key twice. I fixed that now, also dropped the $display variable and I'm just assigning it directly now. That does mean one if less.
Comment #15
berdirLets try that again.. interdiff should be correct.
Comment #16
slashrsm commentedCommitted. Thanks!
Comment #18
glynnr commentedHate to have to revive this, but this patch seems to have caused an issue.
I have a Content type with an image field configured with file_browser that has been working fine for months. Then I updated to the latest version of entity_browser - 8.x-1.0-alpha9 and suddenly I could not see the preview image in the edit form.
I tracked it back to $has_view_builder, and specifically this element which now doesn't appear:
Rolling back to 8.x-1.0-alpha8 fixed it, but I really don't want to be stuck with an out of date, fixed version in my composer.json.
note. I do not have file_entity installed.
Comment #19
Dave Gray commentedThanks glynnr
I seem to have the same problem of no preview image on the edit form widget.
Comment #20
berdirPlease open a new bug report.
the file entity in core has no view builder. Whatis the view builder class name when you load it? maybe you have something custom there.
Comment #21
Dave Gray commentedThanks Berdir
I initially opened a bug report at: https://www.drupal.org/node/2801163.
But then later found the comment from glynnr here which replicates what I've found.
It is tricky to work out whether to post the report In the Entity Browser or File Entity Browser issue queue.
I'm not doing anything custom. Just testing File Entity browser on a standard image field on a node using Drupal 8.2.0-rc1
The form display is setup as:
Preview with default
Entity browser: Browser for files (modal)
Selection mode: Append to selection
I can browse and add an image file with no problems. However the preview thumbnail is blank on the node add form and on the node edit form.
Thanks for your time.
Cheers
Dave