Implementation of the initial Media Management Proposal

Although you are linking 📌 [META] Track 15: Proposal for media management Active , I believe the description of your intended result is on 🌱 Proposal for Media Management in early versions of Drupal CMS Active , right? Do you have a checklist/summary of how much did you implement from that in this MR?

@gábor-hojtsy thanks, I have added that issue to the description. I believe we have implemented everything described there once snagging is done and in addition some of the maybes and nice to haves.

This issue / MR will contain

MVP:

• Image styles and responsive image styles optimised for Olivero and plumbed in with view modes. Formats as described and using focal point for crops.
• Remote video with small, medium and large view modes
• Documents

Additionally:

• Strong media support in CKEditor including selecting view modes for size / dimensions
• SVGs with view modes for small, medium and large scaling options
• optional local audio
• optional local video

Note:

The privacy compliant embedded media described there is already included, coming from the privacy track.

Reviewed this and I have two overarching concerns, one of which is commit-blocking and one of which isn't.

The blocking one is that media_base is constructed as an anti-pattern. It should not include any media types of its own; only things which may be needed by all media types. We probably will want the image media type to have its own recipe, built on top of media_base.

The non-blocking one is ZOMG I have never seen this many image styles in my entire life. Won't marketers find this overwhelming? This is an enormous amount of config, choices, and (seemingly) UI complexity to be introducing. How do we expect people to use this? I don't build sites for a living so I may very well be coming at this wrong, but this seems like it will be very intimidating for people. Should we streamline it?

@phenaproxima SVG image is a separate media type because focal point can't apply any crops. We could combine it for ease of use but if you use a portrait aspect image style with a landscape aspect SVG image you will render a small image with a gap. Therefore, when an SVG image is selected in CKEditor, the editor has a choice of small, medium or large to select from, but not aspect ratios. The editor profile is not in this MR because we were waiting for https://www.drupal.org/project/drupal_cms/issues/3486284 📌 Create a new text format/editor to replace core's Basic HTML Active .

We could split up the recipe by media type. There is not much shared (only enabling responsive_image and the small, medium and large view modes so the base would be small. Shall we go ahead and do that?

Unfortunately, interacting with the image styles will not be user friendly if editors try to do that, but out of the box this will give them good options to use in their content. These are the common options that we found are presented in competitor CMS.

@tonypaulbarker and I discussed this recipe on Zoom and how we think it should proceed. Here's what we landed on:

• We don't really need a media_base recipe. The only things that are shared between images and remote videos are the small, medium, and large view modes. I think it's perfectly okay for those to be duplicated if necessary.
• Let's have two recipes here: drupal_cms_image and drupal_cms_video.
• drupal_cms_images should be a maximalist recipe that contains everything needed for images to work as editors would expect them to. That means all image styles, crop types, responsive styles, view modes, etc. are contained in this recipe. It provides both the Image and SVG Image media types. Ideally those would be only one media type, but Tony explained that there are technical limitations around cropping that prevent that from working as we'd like. It's the kind of thing we could evolve in future versions of this recipe.
• drupal_cms_video will be a wrapper around core's remote_video_media_type recipe, adding the small, medium, and large view modes.
• The starter recipe will include core's audio_media_type recipe as-is, along with drupal_cms_image and drupal_cms_video.
• The starter recipe will also expose core's local_video_media_type recipe to Project Browser, for sites that want locally hosted video.

So, kicking back to "needs work" to reorganize this as we agreed. But truly this is magnificent and robust - I'm amazed by the diligence and thoughtfulness that went into this.

@phenaproxima

Thanks so much for your time it was great to chat this through.

Just couple of suggested adjustments to the above - let’s call the recipe ‘drupal_cms_remote_video’ to distinguish from the other video media type that uses files
Shall we make hosted audio from core optional the same way as hosted video? Not everyone is using that either.

Sure, that sounds good. I'll adjust my comment.

Known blockers are resolved.

We didn't get to complete this yet, because we need to work out how to show these up in CKEditor once they have been added: "The starter recipe will also expose core's local_video_media_type and audio_media_type recipes to Project Browser, for sites that want locally hosted video and audio." I will create a new issue to follow up with that.