When viewing a collection of images in the Media Browser I am only seeing 'image-x-generic.png' as the thumbnail. I might be missing something obvious but it appears that there is no way to get the Media module to display thumbnails for image files in the browser.

I would love to have the ability to display thumbnails in place of the generic image icon.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jayroberts created an issue. See original summary.

jroberts’s picture

jroberts’s picture

Issue summary: View changes
jroberts’s picture

Issue summary: View changes
jroberts’s picture

This is a shim I'm using to show thumbnails in place of icons for image files in the Media Browser. I'd love to be able to accomplish this without the shim.

jlarrubia’s picture

Hi jayroberts,

the Media module relies on the file entity module. As any file is considered as an entity, it handles how images are displayed in the Media Browser using the file entity type "Image" and the view mode "Preview" (/admin/structure/file-types/manage/image/file-display/preview).

It seems you are using as enabled display the option "Large filetype icon" and that's the reason why the thumbnails are displayed as icons. Changing it to "Image" and selecting one of your image styles will solve your problem. The Media module creates the thumbnail style "Media thumbnail (100x100)" to be used for this purpose.

Cheers

joseph.olstad’s picture

Category: Feature request » Support request
Status: Active » Needs review

I've seen this before, its caused by the media module referring to a missing image style. The missing image style in your case is called "square_thumbnail". The way to fix it is to manually add the image style at /admin/config/media/image-styles/add , only do this of you do not have one called square_thumbnail , set it to scale to 180x180.

not sure why this sometimes happens, probably related to a problem upgrading between one of the beta or rc releases , if you do a fresh clean install you'll probably not see this. It would be possible to correct this with a patch. For now, try the workaround

joseph.olstad’s picture

I just tested in simplytest.me , this issue does not affect new installations.

In a freshly installed system the referred image style is called media_thumbnail and it works out of the box.

So, the remaining issue here is to figure out why this happens to those upgrading from beta2 or other versions of media. At that point perhaps we can patch or make a hook_update to resolve that.

Meanwhile the workaround is explained here: https://www.drupal.org/node/2860962#comment-11993778

joseph.olstad’s picture

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

please provide info about the previous version you upgraded from. What version of media did you upgrade from, and what version of media did you upgrade to?

marco-s’s picture

I'm not sure if I'm right here, but I have the same issue. I've installed file_entity 2.0.0-beta3 and media 2.0.0 (Drupal 7.54). The thumbnails of my existing files look like the screenshot in #2 (in the media browser and the file entity edit view). I'm able to solve the problem for a single file entity by saving it once. If I add a new file manually the thumbnails is going to be created correct. I think it is more a file entity issue than a media problem. We need to have a update mechanism to create the thumbnails for existing files. (#7 doesn't solve the problem).

joseph.olstad’s picture

@marco-s
right click the broken image, inspect the element, please copy and paste the path to the image
this will tell us what style it's looking for, the style is in the path of the broken image
the solution is to create the image style that is broken, please provide details , I'm curious which image style is missing or broken.

marco-s’s picture

FileSize
21.95 KB

It isn't a missing style, it's always a placeholder.
<img src="http://my-drupal-page.com/sites/default/files/media-icons/default/image-x-generic.png" width="180" height="180" alt="">

After saving the file entity, the style is correctly set to "media_thumbnail".

Furthermore the file type isn't present until I save the file entity manually.

Snap_2017-04-12_2860962

joseph.olstad’s picture

here's a list of the file_entity patches I use with file_entity 7.x-2.0-beta3 , let us know if they help.

projects[file_entity][patch][2000934] = https://www.drupal.org/files/issues/allow_selection_of-2000934-35.patch
projects[file_entity][patch][2198973] = https://www.drupal.org/files/issues/file_entity_override_widgets-2198973-01.patch
projects[file_entity][patch][2318519] = https://www.drupal.org/files/issues/select_a_file_type-2318519-4.patch
projects[file_entity][patch][2846795] = https://www.drupal.org/files/issues/file_entity_argument3_passed_to_file_entity_add_upload_must_be_array-2846795-3.patch
projects[file_entity][patch][2421609] = https://www.drupal.org/files/issues/file_entity-entity-malformed-exception_2421609_51.patch
marco-s’s picture

Thanks. Unfortunately the didn't help.

But... I did some tests and I could isolate the reason. The problem is the missing file type. In the table 'file_managed' the 'type' is set as 'undefined'. If I change the value from 'undefined' to 'image' manually and load the backend page after that, the thumbnail is generated. This is logical, because without a valid file type Drupal doesn't know how to handle the file. (for example to generate a thumbnail for an image).

joseph.olstad’s picture

hmm, not sure how the file_managed 'type' would get set to 'undefined' , I've never had this problem.

what is your database version? is this postgres? or sqlite?

joseph.olstad’s picture

did you upgrade from media 1.x ? perhaps this is related to upgrading .

marco-s’s picture

No, I didn't upgrade from media 1.x. I had a Drupal installation without file_entity and media. I installed both modules for the first time (file_entity 2.0.0-beta3 and media 2.0.0) and since then I have the new column 'type' in 'file_managed' which is 'undefined' for all files. I work with MySQL 5.7.11.

joseph.olstad’s picture

Ok, make sense. So installing for the first time, we should probably update the file_entity table , a bit surprised that this wasn't the case already. the code would go into file module.install function media_install
Any suggestions on making this work so that it doesn't make your PDF files type image and vice versa?

should this be optional post install? or during install?

I haven't looked too closely into this issue, feel free to pitch in some more.

marco-s’s picture

There has to be a function to store the correct file type, because after saving a file entity, the file type is set correct. I will dive deeper into the source code of file_entity as soon as possible.

joseph.olstad’s picture

Status: Postponed (maintainer needs more info) » Active

Please follow up with solution and/or patch

marco-s’s picture

I have more information:
file_entity queues all files during the install process using the Queue API. Existing files get their file type determined during the first cron run. The files will not have a file type until the queue has been processed!

In my case/project I have round 300'000 files. Perhaps the cron run has been stopped unexpectedly.

Furthermore, file_entity implements hook_file_presave() and checks among others if a file type exists. If the file type isn't already assigned, it will be assigned to it.

marco-s’s picture

I did an other test and re-installed file_entity. As I mentioned, I have 300'000 files in my file_managed table.
Problem 1: The queue process during the file_entity installation stops at 160'000 records. Therefore, round 140'000 files are missing.
Problem 2: I started the cron run to test what happens with these 160'000 queued files. After the cron run is finished, the queue process is still running very slow in the background. The user has no knowing about this process and may close the browser window.

But that's a file_entity issue. I will open an issue in that project.

joseph.olstad’s picture

@marco-s

Easy solution 1:
modify your php.ini temporarily, increate the timeout php exec to a very high value, like several hours or something rediculous like 72 hours.

Then once you have done that, restart your web server service and repeat the upgrade procedure.

Alternatively you can use drush batch operation, programming skills required.

//not real functions, just giving you the idea about drush batch.
  if (!function_exists('media_something_xyz')) {
    drush_print('module_load_include(\'inc\', \'media\', \'media.admin\');');
    module_load_include('inc', 'media', 'media.admin');
  }

  $operations = array(
    array('media_something_xyz_batch', array(!$xyz, $field_name, $copy_all_languages)),
    array('media_something_xyz_switch', array(!$xyz, $field_name)),
  );
  $operations = $xyz ? $operations : array_reverse($operations);

  $t_args = array('%field' => $field_name);
  $abcdefg = !$xyz ? t('Doing some operation for %field field', $t_args) : t('doing something else for %field field', $t_args);

  $batch = array(
    'abcdefg' => $abcdefg,
    'operations' => $operations,
    'finished' => 'media_something_xyz_batch_done',
    'file' => drupal_get_path('module', 'media') . '/media.admin.inc',
  );

  batch_set($batch);
  $batch =& batch_get();
  watchdog('batch', '$batch=' . print_r($batch,1) );
  $batch['progressive'] = FALSE;
  drush_backend_batch_process();
joseph.olstad’s picture

@marco-s sorry for the inconvenience, the upgrade path should have been making full use of the batch api , unfortunately that was an oversight, however I provided you with two options that should help in your case (300,000 + files).

but yes, that is a file_entity issue.

joseph.olstad’s picture

rick_p’s picture

I was not able to delete my original comment so I've deleted the text because none of what I originally posted turned out to be fact. I am able to recreate the problem but unable to fix it with any method consistently. The following error under Reports/Status may be a factor...

Your sites/sitename/settings.php file must define the $config_directories variable as an array containing the names of directories in which configuration files can be found. It must contain a sync key.