@mejo- @max-nextcloud @vinicius73 @juliushaertl

This is now based on latest master which includes the material icon PR 😁.
⚠️ compiled code is not included.

Before moving forward, do we agree on the following aspects?

1. We could just rename image related entries in the menubar s/image/media/ as we want to let users insert any kind of file via: the menubar, the paste event, the drop event
2. Images and Medias (any other mimetype) can be handled by the same controller/service on the server side?
   • We could rename ImageController => MediaController
   • We could rename ImageService => MediaService
3. We have to choose how to write media files in the markdown content (and then make the magic happen in Tiptap's parsing mechanism)
4. We will handle the media display in a dedicated node (pretty much like ImageView). It could look like the file list items in Files.

What's been implemented for now:

• It's possible to upload any kind of file
  • If it's an image, it's done like before
  • If not, then it's almost inserted like an image except the link target ends with #media
• ImageView calls different endpoints when the link target ends with #media
• We now have 3 endpoints to serve image/media stuff:
  • one to get an image (it existed before), it provides a preview if possible, the real image content if not
  • one to get a media file, it provides the file content
  • one to get a media file preview, it provides a file preview if possible, the mimetype icon URL if not

What's weird but not definitive 😜 :

• There's no styling when ImageView display a media file as it will be done somewhere else later
• The attachment cleanup does not work anymore because the trailing #media breaks it. It will be adjusted when we decide how to write media files in the markdown content

TODO

• Implement server side logic
• Implement the parsing magic for media attachments
• Implement a MediaFileView node to display media attachments
• Adjust the attachment cleanup methods
• Implement some PhpUnit tests
• Implement some Cypress tests

Let's go!

I like this approach, looks future-proof.
What do you think about change MediaHandler/ImageHandler to AttachmentHandler @eneiluj?

Some news

• Media attachments are inserted just like images in the Markdown content
• There are 3 new API endpoints to load a media attachment file content, a preview and metadata
• The image loading fallback mechanism can now handle any number of fallback targets
• We attempt to load a media file if loading as an image has failed
• Media attachments are rendered by <ImageView>. It is still possible to delete with the trash icon. It looks like that:
  

Some problems

• For now we can't point to a media file with a relative path using the dav API. It just works for files in the attachment folder.
• The current implementation produces multiple requests for each media attachment. In the worst case:
  1. one checking the dav API (failing)
  2. one checking the image attachment API (failing)
  3. one checking the media attachment API (yay success)
  4. one last to get the metadata (yay again)

TODO

• What do we do when clicking on a media attachment?
  • Download?
  • Show in Files?
  • Open in the Viewer if possible?
  • All that and more?
• Rename ImageService, ImageResolver, MediaHandler etc...
• Think about having a single attachment endpoint returning the mimetype, a preview and some metadata

@eneiluj the delete icon looks a bit off, it seems to be a community one from materialdesignicons.com (please try not to use that, only when the official site has no icon) – use this instead :) https://fonts.google.com/icons?selected=Material%20Icons%3Adelete%3A

Regarding the layout of the element itself, it would be a bit nicer if the element doesn’t go full width. The size info could go into the subline of the element, using color: var(--color-text-maxcontrast);, and the delete icon on the right of it immediately. Since the delete icon is only shown on hover/focus it is fine to have it at different positions.

Example mockup like it is in Mail:

/compile

/compile

I wonder if the cypress failures are due to this... maybe because the urls changed now that the parameters are in there...

/compile