Hide label, thumbnail, etc. for default display of media file and image references

+1 for removing the formatter.
In this case, however, we may need to update the CR (or create a new one) because some contrib modules may be relying on it (I personally don't think many are, but just in case).

I have manually tested #4, everything works as expected. I was going to RTBC but just found that we have:

field.formatter.settings.media_thumbnail:
  type: field.formatter.settings.image
  label: 'Media thumbnail field display format settings'

inside media.schema.yml. Shouldn't we remove it as well?

I removed field.formatter.settings.media_thumbnail from the media.schema.yml.

Thanks @chr.fritsch! RTBC'ing in the assumption tests will pass.

+++ /dev/null
@@ -1,201 +0,0 @@
- */
-class MediaThumbnailFormatter extends ImageFormatter {
-

Is there a reason we couldn't fix the thumbnail formatter instead? The thumbnail is guaranteed to be a valid URI, so I don't see why it shouldn't be theoretically possible to render an img tag to that. In case it isn't, is there any value in the thumbnail in the first place, when you cannot display it? Could we remove it across the entire module as well? This would be a great simplification.

Default File & Image displays look broken + remove MediaThumbnailFormatter because it's broken

The usage of the word "broken"

Re: #9:
I may be missing the point (sorry if it's the case), but isn't the thumbnail a basefield of type image, and then, viewable by any formatter that can be applied to image fields?

Out of the box, we are indeed using the Tumbnail information in the Media listing in /admin/content/media:

so I see value in having the basefield, even if the formatter is gone.

Ah this makes sense now.

Indeed. And guess what: nothing uses the media_thumbnail formatter! Not views.view.media (/admin/content/media) which is shown in #10, nor the default File & Image displays.

Indeed, but maybe it should actually?

+++ b/core/modules/media/config/install/core.entity_view_display.media.file.default.yml
@@ -3,48 +3,22 @@ status: true
   field_media_file:
-    label: above
+    label: hidden

+++ b/core/modules/media/config/install/core.entity_view_display.media.image.default.yml
@@ -3,49 +3,25 @@ status: true
   field_media_image:
...
     label: hidden

Is there a reason we cannot go visually hidden? I assume it would be better accessibility wise to have the label still around.

I think this totally make sense.

One less thing site builders have to change to even make sort of a positive impact.

As I think @dawehner started to say in #9, please don't use words like "broken" and "useless". They create an unnecessarily negative tone and interfere with the progress of an issue.

Attaching screenshots of the configuration screen at Admin -> Structure -> Media types for the File and Image media types' entity displays, to illustrate the changes for the site builder.

In HEAD

File configuration:

Image configuration:

With the patch

File configuration:

Image configuration:

So I definitely agree with:

• Hiding the "File" and "Image" labels visually, but keeping them as visually hidden for accessibility.
• Removing display of the thumbnail for files, since the file plugin doesn't provide a meaningful thumbnail and the default thumbnail does not add information.

I'm less sure about:

1. Removing the author and created fields. In the case of embedding the rendered media entity in a media field, they are probably not useful. But in the case of administering site media (i.e. viewing the media entity directly), they could be useful information, in the same way that the node author is useful information. I'm confused by:

   creation date, author seem of little relevance, since most media are not actually created by the user who uploaded it

   How is this the case? If they seem to be created by someone else, that would seem like a bug? I tested and it seems to report the correct user.

   Edit: I guess this means that the file itself isn't necessarily created by the user who uploaded it, e.g. a content editor didn't take the photo that they're adding to the article. However, I think it's also very common for users to upload files that they created themselves. And, regardless, it's useful information to know who put that image on your site or who submitted the file. So this doesn't seem like a reason one way or the other to me. I think it's more about what's most commonly useful to site builders so that they have less to configure.
    

2. Removing display of the image thumbnail. (Note that the summary does not match the current patch. In the current patch, the image thumbnail is hidden and the default "medium" image style is displayed.) When Media is viewed directly, the site builder might want to see what the thumbnail will look like, and compare it to the full image. This is useful for e.g. an image gallery or user profile directory, where you might want to compare the thumbnail that will be used in a view to the style that will be displayed on the full page.

It probably still makes sense to go forward with those two changes as well, because the File and Image plugins are mainly intended as replacements for core file and image, and the 80% usecase is probably just displaying the normal file formatter and displaying a reasonably-sized version of the image. For creating advanced displays of the media, the site builder would probably be reconfiguring things anyway; the current display is not really well-suited to that usecase either. However, I did want to document the questions since I considered them.

Leaving at RTBC for the moment to think about it some more. The greatest advantage of doing this soon is probably that it makes #2831943: Use "rendered media" (not links) as default media field formatter; add modal to configure the used media view mode straightforward; using files and images in Media fields is probably much more common than viewing their entities directly.

Yes, I agree that the 80% use case is the normal file/image formatter. On most client sites I've worked on access to /media/x or file/x in case of D7 is rare, and when clients do find themselves there, they find it confusing. They're much more likely to use /media/x/edit or file/x/edit than the full page view.

Thanks @larowlan. That's confirmation enough to overcome my waffling. Committed and pushed to 8.5.x. I also backported it to 8.4.x since it's a strategic initiative, etc. and we've still a full week before the beta deadline.