[Design] Media Services

[sebastienros]

Before I even start thinking about the design of this feature, I want people to comment on the existing implementation (Orchard1) or suggest changes.

The issue includes these topics

• The file storage abstractions to store Media items
• The way we manage media items (content items, admin UI, edition)
• Media transformation (profiles in Orchard1)

Some open questions to start the discussion:

• What did we gain and lose by making Media a content item? Should it be challenged?
• Is anyone using Profiles, or is it sufficient to just create custom ones when rendering the media directly (using the specific shape), or is it necessary to support url based transformations (image.png?size=300x200)
• How can we make the current UI even better?
• Should we remove the "Import from custom providers" step to make the UI simpler?
• Keep support "per user" media and media file replacement out of the box?

Overall I think what is in Orchard 1 is perfect, but I also think some features are not really as useful or popular as I had imagined (profiles, import sources).

/cc @Piedone @bleroy @anoordende @jeffolmstead

[Piedone]

I've never used Profiles or have seen them be used, but that doesn't mean it's useless...

I'd made the Media import workflow easier: currently it's create folder if not already > Import > do stuff > OK. If it would be just a drop zone and upload button in the folder view that would be much simpler. This also relates to extensible Media import, what I have never used or seen being used either (but we could still keep it, just make the most used local import a more obvious one).

I'm OK with the abstractions and Media items being content items. not sure what you mean by "per user media".

[sebastienros]

The "per user media" is the special folder of Media items that are only editable by the current user.

[sebastienros]

Drupal is very flexible, but man I was lost after half the article. Not even sure how beneficial this is compared to what we have in O1 https://www.webwash.net/manage-media-assets-drupal-8/

[DaRosenberg]

I never use profiles either, and haven't seen them used. But as @Piedone says, doesn't mean they're not useful, maybe people are just not aware, maybe they are not discoverable enough?

Storage abstractions are super important. Custom import providers I think should definitely be there - for example, the Azure Media Services solution would not be possible without them.

How can we make the current UI even better?

Well, "even" better... :) The current UI is really bad. It completely breaks down when the media picker dialog happens to be invoked from within something that is already a dialog, with nested dialogs and iframes and multiple close buttons etc. To make it acceptable, we should solve this problem in a different way, and not nest dialogs in dialogs. Perhaps instead design these dialogs as "blades" and stack them horizontally like the Azure Portal does?

Making media content items was a good move IMO, and personally I think we should keep it:

• It allows media items to be customized/extended
• It allows separation between media items and their underlying storage
• Not every file in the storage needs to become a media item

The biggest problem in O1 media management is that items are embedded by resolved URL into content. For OC my biggest wish would be to change this, so when you insert an image into Markdown or HTML, we use a special syntax to identify it by its content item ID, and use a filter to resolve it to the actual URL at rendering time. Inserting absolute URLs into content causes so many problems around portability of content, continuous integration, etc.

@sfmskywalker might have some design notes on this somewhere - I looked for an issue where we outlined the design we came up with for this, but couldn't find it. There is an old issue however on this (OrchardCMS/Orchard#1880).

[sebastienros]

Keep support "per user" media and media file replacement out of the box?

I am suggesting to just rely on "Manage Own Media" to prevent a user from editing media items that are not his own. Users can create personal folders if they need. All media items can be selected, even with "Manage Own Media" only.

As a reminder, the scenario is for a multi-blog site, each user might want to organize it's media independently. Or we might not want someone to edit existing media that are not theirs.

[sebastienros]

To simplify the UI, I am suggesting to keep the current screens for Media management, but when we need to select media use a specific media selection that would only allow Image creation on the fly. Any other complex media operation would require to go to the media management screen instead. Then there would be a single dialog to select a media or drag and drop an image. Other screens would be full screen.

[agriffard]

Will there be a possibility to add files in the Media directory on the disk and have an action from the admin UI to 'import as content' the files that are in the physical folder but not yet appearing in the Media library?

[agriffard]

BTW, Media upload doesn't work for me anymore.

I managed to upload an image when I tested the first commit of the media branch.
Now, the file is uploaded to the folder, I can see in debug that a content item is created but nothing is saved in the database anymore and the UI doesn't display the uploaded file.

[sebastienros]

It should work with the latest commit, I can create and delete folders too.

Yes, I think the Media Import should be part of it. But not sure we need it for a v1, unless someone does it for free. Would be better to have it as part of the Import Media tab that we'll have after the common features are implemented. The code is already in the Update module for O1.And it only applies to the FileSystem provider.

[jersiovic]

My two cents.
Yes we use profiles, I think they are very convenient. We provide same theme for different tenants. Using Profiles allow admin of each tenant to set the size of images used on different areas of the web without contacting us.

[Hazzamanic]

My two cents, which seems to be resisting the general wisdom, though I'm sure I can be converted...

Moving to content items
I didn't much like this change.

• Although not an argument against the theory of db backed media, O1 really was a half-assed effort (as others have already pointed out). We moved to content items then stuck direct urls into content? It really made the whole move pretty pointless.
• Performance. Having to fetch a content item from the db just to display a thumbnail felt a bit crazy. And it made things noticeably slower on projections with lots of items with thumbnails etc. When you have to write a hack because a thumbnail is grinding your site to a halt you have to wonder if there is a fundamental design issue. I'm almost glad direct urls were chucked into the body, 50 get content requests to load as many images would have made me cry.
• Complicated. Making media into a content item just added the complicated nature of content items onto displaying an image. They look crap out the box because they display additional parts, meaning you need to dig into placement for an image. You have the field template, then the item template and then the part template that finally displays the media. Makes finding the url of the media item a real pain. I have had to explain to people countless times how to display media. It turns people off a system.
• Extensibility. I remember being excited for this, being able to display captions for images etc. But it hasn't really changed much to me, it has probably been more annoying. Take captions for example, people add their image and type in their caption. Yay. Another dude uses the image, but changes the caption. Doh. I also know the guy who was responsible for this particular site after me had a lot of headaches with people writing localized text on images and overriding the original. I don't know if media items support localized items? But yeah, in my experience either a media item was used once or if it was used multiple times, having additional fields and data attached to it was liable to change from use to use.
• Uploading. This isn't the end of the world for sure, but it forces you to use the inbuilt uploader, involve another manual step to create the content item after upload (orchard has no inbuilt way of doing this save using the Update process each time so that'd be nice for O2 to have) or another programmatic step after the upload to create the content item. I'm not necessarily against this, but I do believe it is a trade off that has to be worth it.

Regarding the WAMS integration, I'd be interested in hearing how much use this has received and how important it being baked into media area has been. Genuine questions. Because as you say, media content items are required to make that kind of integration. It's the only implementation of its sort I've heard of; are there any other modules extending the media module like it? My last job involved building streaming websites within Orchard and we opted not to use the media module to handle our videos (our videos were content items) because we would be writing such a customized pipeline for uploading (as did the WAMS module I imagine) that using the media module didn't really bring any benefits, only constraints. I also felt videos and images/downloads were separate, though this stemmed from the nature of the sites I guess, being specifically for video streaming.

Profiles
I love these. Use them all the time. Have extended them with my own providers several times. They are great, please keep them.

UI
I'm going to be douche here and agree with Daniel Stolt. I don't think the existing UI could be much worse. I also think we should use an existing uploader like dropzone or the like (or make it possible to drop in different upload mechanisms) because the current one has crashed on me too many times.

Providers
I think these have potential still, and can be kept while making the upload process more streamlined. But yeah, someone just needs to build the providers ^_^

Per user
I have never used this but I think it is a great feature to have, lots of scenarios come to mind.

The Rest
I think the whole media in Orchard has suffered from a massive lack of documentation for both its features and its extension points. It has a decent image editor that I've heard zero about, profiles seem almost unknown to people.

Maybe controversial but I don't think putting time in to support the upload and display of video or audio is worth it. People use external providers because they offer real functionality. People can always add support if they want it...

The relevant discussions about media management in O1 might be helpful too? http://orchard.codeplex.com/discussions/359624 http://orchard.codeplex.com/discussions/402143

EDIT: clarity

[agriffard]

For th UI, I like the way http://jeremyfagis.github.io/dropify/ allows to replace and enhance a fileupload.

I think Profiles (or transformations as you seem to call them) has to be taken from O1 but a MediaPickerField should have options like:

• Allowed file types.
• Default Upload Location (tokenizable)
• Maximum number of files allowed to be selected.
• Sources (from where can I pick a file)

A FileUploadField should also be something available ootb to be used in Front-end Forms.

The next two features I am expecting are:

• Publish through XmlRpc from Open Live Writer.
• Upload or Select File from the WYSIWYG Editor.

[agriffard]

@sebastienros Can please merge the Orchard.Media Module branch?

I will try to make the MetaWeblogHandler to allow supportsFileUpload.

[sebastienros]

@Hazzamanic Thanks a lot for the extensive feedback.

UI

Can we agree that the issue is the current stacked modal dialog implementation that is super hacky?
I have another implementation right now in O2 that is only based on Vue.js and is reused "exactly as is" for both the main media management page and the media selection.
Daniel was somehow explicit about his issues with it, but I could use more details about yours.

I don't think we should be able to plug different upload libraries. We need one that works with Orchard. If there are bugs with one library, we should switch to a better one. I am using jQueryUpload (https://github.com/blueimp/jQuery-File-Upload) in O2 too, and would love to know what doesn't work with it. I found dropzone that you mentioned, I am glad to use it if it's better (https://github.com/enyo/dropzone). At least make it more obvious that we can drag and drop files.

Content Items

I totally understand your concern. I might have an idea then. What about have a Media section just to manage files, which would look a lot like the current media management, but not based on content items. And then at the same time create some content types like Image that would have a Media Picker field and select one media, and optionally define custom content. This one would be draftable and localizable, with custom fields or taxonomies.

Then in your content editors (body, markdown, ...) where you need to insert a file, the picker would expose the Media, not the content items. The content items would be used with a Content Item Picker if you need to reference more that just files. This would also solve the issue that we have to load a content item right now to be able to inject an image url. We would still use a specific tag to reference a relative file path, like {{{ media 'kittens/kitten1.jpg'}}}.
Having some event when files are added would allow custom modules to create Content Items automatically if they need (only when added from the UI).

Another option would be to keep Media as content items, but have the content editors use the file system directly, but that would require two different pickers, more work.

Profiles

Profiles (as in predefined named sets of filters ) can be done later, as long as we can already apply filters when we insert a media, or use them from a view (using a tag helper). So from a body we would have something like {{{ media 'kittens/kitten.jpg' 350x120 resize }}} and from a Razor View <media src="kittens/kitten.jpg" width="350" height="50" action="resize" />.

I think we could also leverage the File Picker by exposing templates for it, and even expose <picture> and srcset (https://www.html5rocks.com/en/tutorials/responsive/picture-element/).

[anoordende]

Forgive me for not having had a moment to check out the O2 media branch yet, but here are my 2 cents worth based on O1.

Content Items

I have dearly missed some functionality ever since the move from MediaPicker to MediaLibrary:

• The ability to upload zip's
• The ability to just populate a folder with Gig's of media and O1 picked it up, rather than having to go through the interface

With regards to still needing Content Items, just thinking out loud:

• If we could set at a minimum a Title against the file itself, then we may have most use cases covered (populating an alt attribute, a title, etc.) without needing a Content Item. Setting a Title could be a Storage Provider-specific implementation. Devices with Media libraries (Music, Videos) use file attributes abundantly.
• 3rd Party Modules like Sliders should depend on e.g. a "Slide" Content Type with a Media Picker Field, so any links, titles, translations, etc. can be set on the Slide rather than extending the Image Content Type, further reducing the need for Content Items.
• Renaming files: How would this work with media tags? I'd draw the line at this and let the 404 (gracefully!) take over.

User Experience

End-user experience with uploading and organising media has been a drama in O1. Of course, this is end-user "error", but I'm sure we can do more in terms of configurable features that make uploading media more transparent (read: very, very facebook-style easy) to the novice end-user:

• Cleaning file and folder names (spaces and other crap),
• Automatic file renaming based on the Content Item (e.g. Title) against which the file was uploaded (when uploaded through editing a Content Item). This could be a setting on the MediaPickerField.
• Automatic organisation (folder creation) based on Content Item (e.g. Title), @agriffard mentions a tokenizable default upload location,
• Rejecting unsupported formats (TIFF, unsupported by filters, etc.).

Injecting Media URL's

I've always argued that URL's injected by the picker et al should be relative (or a tag as being described above) and be rewritten to the local media path, CDN, blob storage, etc. based on the environment settings. This is also crucially important when moving domains and is WP's horrid achilles heel.

The tag solution as described by @sebastienros sounds perfect in what it can achieve, especially if a hook can be included for 3rd party modules to transform the final element rendering.

In addition, I would also consider that, in the WYSIWYG editor, images can be resized and may have to get cut down to that size (See discussion)

SEO

• We should populate an alt attribute which is not the filename, which needs to be stored somewhere,
• We should also still be able to set / override the alt attribute both in a body and a razor view,
• We should be able to always serve the image relative to the site's domain, regardless of storage medium, and add the rel=canonical HTTP header,
• The ability to generate meaningful filenames (as mentioned above),
• The ability to move domains with blanket 301's.

Storage

We should be able to plug in any (3rd party module) storage provider, from local file system to cloud-based (central storage is crucial for a load-balanced environment), and, depending on the storage provider's capabilities:

• Media can be served directly from the provider (and also relative to the site*), or
• is only used for storage, media is served relative to the site*.
• On top of this, we should be able to configure a CDN.

Import & Upload

To ease the pain of uploading (especially on a slow connection), I would suggest renaming O1's "Import" to "Upload" and re-purpose "Import":

• Upload: as is, drag & drop individual, multiple, etc.
• Import: Using "Import Providers"

Import Provider modules could provide, for example, the following functionality:

• Local Zip Import
• DropBox Import
• OneDrive Import
• WeTransfer Import

Profiles and Filters

I'd be perfectly happy not to have profiles at all, as long as we can specify an array of filters (in order!) to be applied, together with parameters, something like {{{ media 'kittens/kitten.jpg' 350x120 resize='max' watermark='my-watermark.png,bottom-left' }}}

Filters should specify something like a SupportedFormats property so that the service can fail gracefully and produce a meaningful error before even attempting to run the filters.

We use profiles extensively, but the O1 workflow is not very atomic when used in views. Before deployment, you first must make sure the profile exists, names match, sizes match the attributes, etc. Anything that can be under source control has my vote.

Per User

Indeed we should differentiate between managing your own, publicly accessible media and per-user secured storage. The latter has recently become a requirement for us, but this is being solved outside of Orchard. Having said that... killer feature :)

*Serving Media Relative to Site

This is our favourite internal recurring topic and difficult to solve, although we did have a solution in O1, it was difficult for various reasons. The end-goal is that, no matter where media is stored, it will (also-) always be available under http://my.domain.com/Media/Tenant/..

The O1 implementation of storage providers, such as Azure Blob Storage, turned the blob storage more into a CDN than just storage. I'd suggest to put this right and only use this as storage backing, with the media still being served under the site.

If a particular setup still wishes to use the storage provider directly, it can be done by setting something like a PublicMediaBaseUrl config to anything other than blank. The same for using a CDN. In turn, the CDN can be configured to use the storage provider directly as a source, or the site itself.

Some CDN's have the ability to automatically set the rel=canonical HTTP header based on the source, but perhaps it makes sense to to add this in Orchard by default? In any case, it would be very easy to add on most webservers.

[sebastienros]

Thanks @anoordende that's very informative.

Not sure you watched the video from two weeks ago as I talked about some of these points and came to the same conclusion as you. We will go back to a file based media screen that will reflect the actual files on the FS. Also use relative path to link to media, or apply transformations using tokens.

We are keeping the possibility of having content media items, but this will be optional, and kind of natural like any other content type, by using a File Picker in a custom type.
We will also introduce a new concept, Attachments, that will let you create media items embedded in your content types, and define the metadata here. Then if the content item needs these to render something (slides, body, ...) the items and their metadata will be available in memory already.

The CDN s. Azure blobs makes totally sense, as I came to the same conclusion. I was wrong when I designed it. So now the Azure Blob will just be a file store, and the image filters will use an independent cache storage. CDNs will query the server based url, and the server will transform the image live, while the CDN can then cache the result, and we can also store it locally (not in the same media files folder) if we don't want to rely on a CDN.

[sebastienros]

The Attachment Part can be done after beta.

We can have custom tags/filters to depict the differences from a media that comes from

• the Media Library like {{ 'kittens.jpg' | media_url | resize: '100x200' }}
• the media content items {% assign mycontent = 'contentid or alias' | content %} {{ mycontent.Path | media_url }}
• the attachment {% assign mycontent = 'contentid or alias' | attachment %} <img src="{{ mycontent.Path | media_url }}" alt="{{ mycontent.Content.ImagePart.AlternateText }}" />

[agriffard]

Can Media Design be closed?

Many features have been implemented.

If we plan to implement other features, we should create specific issues.