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

Comments

Berdir created an issue. See original summary.

berdir’s picture

Status: Active » Needs review
StatusFileSize
new9.75 KB

Haven'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.

Status: Needs review » Needs work

The last submitted patch, 2: entity-browser-2784199-2.patch, failed testing.

The last submitted patch, 2: entity-browser-2784199-2.patch, failed testing.

The last submitted patch, 2: entity-browser-2784199-2.patch, failed testing.

berdir’s picture

Status: Needs work » Needs review
StatusFileSize
new9.73 KB

Didn't apply because my patch was on top of the delete button.

samuel.mortenson’s picture

Status: Needs review » Needs work

As 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:

  1. @@ -151,6 +143,7 @@ class FileBrowserWidget extends EntityReferenceBrowserWidget {
           '#type' => 'select',
           '#default_value' => $this->getSetting('view_mode'),
           '#options' => $this->displayRepository->getViewModeOptions('file'),
    +      '#access' => $this->entityTypeManager->getDefinition('file')->hasViewBuilderClass(),
    

    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?

  2. @@ -54,13 +55,6 @@ class FileBrowserWidget extends EntityReferenceBrowserWidget {
       protected $configFactory;
     
       /**
    -   * The image factory service.
    -   *
    -   * @var \Drupal\Core\Image\ImageFactory
    -   */
    -  protected $imageFactory;
    -
    -  /**
    

    Nitpick, but we'll need to remove the import for ImageFactory as well.

  3. +    // Had the preview column if we have one.
    +      $current['#header'][] = $this->t('Preview');
    

    Nit, comment needs to be indented, and s/Had/Add/, and move above if statement to match the next comment.

  4. +      if ($display) {
    +        $current[$entity_id]['display'] = $display;
    +      }
    +      // Assume that the file name is part of the preview output if
    +      // file entity is installed, hide this column in that case.
    +      if (!$has_view_builder) {
    +        $current[$entity_id]['display'] = ['#markup' => $entity->label()];
    +      }
    

    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.

samuel.mortenson’s picture

The 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 :)

The last submitted patch, 6: entity-browser-2784199-6.patch, failed testing.

The last submitted patch, 6: entity-browser-2784199-6.patch, failed testing.

slashrsm’s picture

Issue tags: +D8Media

Patch needs re-roll after recent commits.

berdir’s picture

Status: Needs work » Needs review
StatusFileSize
new13.46 KB
new4.58 KB

1. 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.

Status: Needs review » Needs work

The last submitted patch, 12: entity-browser-2784199-12.patch, failed testing.

The last submitted patch, 12: entity-browser-2784199-12.patch, failed testing.

berdir’s picture

Status: Needs work » Needs review
StatusFileSize
new10.14 KB

Lets try that again.. interdiff should be correct.

slashrsm’s picture

Status: Needs review » Fixed

Committed. Thanks!

  • slashrsm committed e3e2715 on 8.x-1.x authored by Berdir
    Issue #2784199 by Berdir, samuel.mortenson: Improve display and settings...
glynnr’s picture

StatusFileSize
new55.12 KB
new19.1 KB

Hate 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:

$element['preview_image_style'] = [
      '#title' => $this->t('Preview image style'),
      '#type' => 'select',
      '#options' => image_style_options(FALSE),
      '#default_value' => $this->getSetting('preview_image_style'),
      '#description' => $this->t('The preview image will be shown while editing the content. Only relevant if using the default file view mode.'),
      '#weight' => 15,
      '#access' => !$has_view_builder && $this->fieldDefinition->getType() == 'image',
    ];

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.

Dave Gray’s picture

Thanks glynnr

I seem to have the same problem of no preview image on the edit form widget.

berdir’s picture

Please 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.

Dave Gray’s picture

Thanks 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

Status: Fixed » Closed (fixed)

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