Media Library features similar to Orchard 1

[tidou]

Dear development team, hello! I have a request, I don't know if it can be implemented, the new version is very good, not enough media manager is not perfect, can you add Orchard.MediaLibrary module like orchard1, so that the added media files can record data and edit in the database. And achieve the relevant authority control, thank you!

[scleaver]

I have to say I agree with @tidou - I haven't really looked at version 1 of Orchard but I really do think that media files need to have some additional data stored against them as just having the file is a bit limited.

All media:

• A title field - the ability to give the media a title. This is needed so that images can be sorted, searched and easily found for site admins. Without this it will be hard to manage files. If you create a list of files, like a document list then you don't really want to store the document title separately from the file.
• Description - a field for further describing the media. Again for assisting with search and other activities.
• File type - is this field a image, video, document or other file. This is so when I add a media field to a content type I can then say "only allow images to be used in this media field".
• File size - so that you can display file size to the user without having to interrogate the file on the fly.
• The ability to replace the file but keep the above data. Say as a user I want to to upload a new version of the image and replace it wherever it is used.
• The ability to change the file name.

Some file types might need some additional fields:
Images

• Default alternative text - image should have a stored alternative text so that when you use the image

Video

• Video still - ability to associate a still image with the video

Also I think the media field should associate the media item by ID rather than path if possible. The relationship should be removed if the media is deleted.

[arkadiuszwojcik]

I also think that media item should be identify by ID, with option to have some metadata fields. That might be usefull to implement responsive images #3273 , one of such field could hold paths to numerus images of different sizes.

[sebastienros]

Assets are files on purpose. The idea is that when we don't have custom metadata on a file we should not have to load a content item from the database to render it.

But it's still doable, just create a type named Image and add a media field to it, plus any other metadata you need. Then you can use the Content Field Picker to select an Image like this.

You can even organize then with Taxonomy, or tags...

[matiasmolleja]

Yes. Many of the features suggested can be achieved by wrapping the field in a content part
A video content part, image content part, etc...
We should keep the field simple I think

[scleaver]

@sebastienros - so the uncomplicated nature of media at the moment is a performance decision? eg. no DB lookup so better performance?

[sebastienros]

Correct, most sites don't need to overhead of image metadata. And it's still doable on a per usage basis.

[tidou]

The general CMS website does not need to record media files such as jpg, doc, pdf, MP3, etc., but if you do a document management system, uploading files directly to the database will be convenient and intuitive, just like the windwos manager, I feel Orchard1 Orchard.MediaLibrary is very good, uploading document records data, and can do permission control. Strongly request the development team to consider adding this function module. Those of us who do the management system will be very grateful for your contribution!

[Skrypt]

I would probably favor the use of some .json file or a single database row with JSON that would store files metadata for making import/export easier than in 01. I know that in 01 we needed to have a media sync button that would reimport all files missing to the database and that would create a single row per file in the database which made this awkward for retrieving a specific media item by it's Id. Somehow it is easier to just be able to copy/paste a file in the media folder to get it accessible from your website frontend than to require to do a SQL query to retrieve it with it's metadata. And we could simply cache that JSON data on runtime.

Also for identifying a media item we could run a MD5 checksum and store it in that JSON.
Simple as doing this :

using System.Security.Cryptography.MD5;

using (var md5 = MD5.Create())
{
    using (var stream = File.OpenRead(filename))
    {
        return md5.ComputeHash(stream);
    }
}

static string CalculateMD5(string filename)
{
    using (var md5 = MD5.Create())
    {
        using (var stream = File.OpenRead(filename))
        {
            var hash = md5.ComputeHash(stream);
            return BitConverter.ToString(hash).Replace("-", "").ToLowerInvariant();
        }
    }
}

This could be a good way to also identify files that are duplicates.

[sebastienros]

I will never repeat it enough, if you really want it, it's 4 clicks away, create a content type and add aefia field, or two, or three, plus text fields, ...

One day we might work on some predefined solution, as predefined content types, but building block is already there. Bonus, you don't have to delete the media types that don't match your needs.

[Skrypt]

Yeah I agree with that too.