I'm 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.
I've looked at all the documentation that I can find, and am wondering if I've missed a step or whether this is a bug.
Cheers
| Comment | File | Size | Author |
|---|---|---|---|
| #33 | file_browser.snip_.png | 78.63 KB | glynnr |
| #25 | interdiff-2801163-20-25.txt | 5.83 KB | samuel.mortenson |
| #25 | 2801163-25.patch | 14.75 KB | samuel.mortenson |
| #20 | interdiff.txt | 3.38 KB | marcoscano |
| #20 | 2801163-20.patch | 16.55 KB | marcoscano |
Comments
Comment #2
Dave Gray commentedAs a follow up I've just found a comment in the Entity Browser issues that is a duplicate:
https://www.drupal.org/node/2784199#comment-11626101
Comment #3
berdirMoving to entity browser.
Comment #4
slashrsm commentedI was able to reproduce. Problem is that we assume that there will be no view builder if file_entity isn't installed, but that is not the case. It seems that core adds \Drupal\Core\Entity\EntityViewBuilder if no other is defined. Attached patch fixes the problem, but I am not sure if it takes the best approach.
This could use a test :)
Comment #5
dddbbb commentedJust ran into the same issue. Rolled back from Alpha 9 to Alpha 8 to workaround for now. Happy to test any patches.
@slashrsm Are you asking for someone to write a test or for someone to test your patch?
Comment #6
slashrsm commentedThis patch is actually wrong. Should use
->getViewBuilderClass()instead of->hasViewBuilderClass().Both would be very helpful.
Comment #7
slashrsm commentedComment #8
slashrsm commentedThis should work. Test coverage is still missing.
Comment #9
marcoscanoworking on it
Comment #10
slashrsm commentedwidth/height attributes cause problems when the image is initially selected since they end up being 0, which seems to force image to be 0x0px in size. If we default to NULL that isn't the case.
Comment #11
marcoscanoCreated a test for the image field. Not sure if the coverage is enough though.
Comment #14
marcoscanoThe same but creating a new browser, in order not to mess with other tests.
Comment #17
marcoscanoargh sorry
Comment #18
marcoscanoTesting title and alt on the images as well.
Comment #19
slashrsm commentedJust few nitpiks:
Let's try to figure out a better name. Maybe something that indicates which plugins are used in it.
Newline missing
It might make sense to see if we could move this to core. Let's keep it here and create a follow-up.
Should better explain what we are testing (mention image field widget).
Comment #20
marcoscanoAddressing feedback.
Concerning
After asking some people about it, it looks like after #2763401: PHPunit browser tests should log all Mink requests is in, it should be easier to have the output log inside the tests, but I'm not sure to what extent we could abandon this helper function completely or just to modify it.
Comment #21
samuel.mortensonI would prefer not putting explicit module checks in the codebase (in this issue or #2807997: EntityReferenceBrowserWidget shouldn't expose an "edit" button if the entity is not editable), as we can't assume that File Entity is the only contrib module that enhances Files by adding view modes and an edit form. Why was the logic changed in #8 to depend on File Entity?
Comment #22
berdirWe discussed and agreed on this. My reason is that we know how file_entity works, while we have no clue about what it means when another module ads a view builder. We can change this if we see other actual use cases of people doing this.
Comment #23
samuel.mortensonSo there's no other way to check for the functionality that File Entity provides?
Comment #24
slashrsm commentedThis patch was initially checking for the presence of view builder on file entities, but it turned out that core add a default one, which made this approach more or less unusable. I am also not completely happy with the moduleExists() check, but it seems that this is the best option that we have.
Comment #25
samuel.mortensonHere's an alternate solution which seems to work for me. Instead of checking for File Entity, we check for the presence of View Modes. If there are any View Modes, there must be some system that allows for the configuration of those View Modes (i.e. File Entity). I've tested this manually with and without File Entity, and the logic is holding up so far. Let me know what you think.
Comment #26
samuel.mortensonAnd some quick validation with Drush:
Comment #27
berdirView modes can be deleted so there could be none. But, as you can't actually *select* a view mode when ther are none to be selected, that makes kind of sense ;)
Works for me.
Comment #28
samuel.mortensonAh, totally didn't think of that. If we go with this solution we assume that your don't want the full/default View Mode displayed as the preview, which was unintended when I wrote the patch but works for me as well.
Comment #29
marcoscanoComment #30
marcoscanoComment #31
slashrsm commentedCommitted. Thanks!
Comment #33
glynnr commentedDoes not work.
Using latest dev (as of 15 minutes ago, includes this patch). Not using file_entity module.
drush ev 'echo count(\Drupal::service("entity_display.repository")->getViewModes("file"))'2
Comment #34
samuel.mortenson@glynnr What contributed modules are you using? I haven't run into a site not using File Entity with multiple view modes for files yet.
Comment #35
glynnr commentedHere is output from "drush pml"
It's possible that I may have enabled file_entity module in the past, and then uninstalled at some point.
Comment #36
glynnr commentedMore info:
Comment #38
berdirIt's possible that I may have enabled file_entity module in the past, and then uninstalled at some point.
That's one option, another is that token_install() actually creates view modes for all entity types with a view builder now, which is now all of them. (I want to remove that, but didn't happen yet).
Didn't think of that before.
Let's just go with the module check. It's not perfect, but we know exactly what the check does and how it behaves.
Edit: Actually had a cross-post. Yes, so it is indeed both. file_entity installed once which added thumbnail and also token.module.
Re-opening this.
Comment #39
glynnr commentedThe patch in #20 is out of date and doesn't apply. If someone can re-roll that, I will be happy to test it right now.
Thanks
Glynn
Comment #40
samuel.mortensonGoing with the patch from #20 is the easiest solution at this point, the only other idea I have is to check that there's a way to edit the display mode for File entities, since that's more specific. The problem is that I don't know how to do that consistently, and if Field UI is disabled that may mess up any other logic I try to write.
Considering that, I'm OK with going with the moduleExists check. I assume that at some point in the D8 cycle File Entity will get into core, so this is really just making up for core's shortcomings.
Comment #41
slashrsm commented@glynnr I reverted previous commit and #20 applies again.
Comment #42
glynnr commentedConfirmed. Patch in #20 now applies to latest dev, and works.
Thanks for your quick response an this.
Comment #43
slashrsm commentedThanks! Committed.