Media Library

[Karmalakas]

As I'm not only a developer, but also a hobbyist photographer, I can't stop thinking about some media library (probably not only images). I've been searching quite a bit, and so far I see only one remotely acceptable approach, but it has some limitations (can't easily remove from Pages listing for one) and at the same time lots of overhead (unnecessary configurable options).

So I was giving some thought and with my current knowledge of Grav, I always end up with an idea, that media library could be almost exact same thing as Pages. Should be located at user://media-library and have almost exact same structure as Pages - media items with folders and subfolders (directories). Folder, same as Page could have Title, Content and Media Order. Also folders would be multi-lingual as Pages are now - no need to invent something new.

It also should come with a new input field to (multi) select files from Media library. Could be auto-complete probably, but maybe simple select with <optgroup> as a folder could be a start. Basically it could be same as pages type field, but with different root.

The only drawback I see currently - no multi-lingual metadata for media files. Saw some topics on this too, but I guess this could be achieved at some point.

I would try to implement something like this, if Pages was a plugin, but now it's a part of core, so not sure how to approach this as a plugin or even as a core change.

Hopefully we'll get media lib sooner than later :) I really believe it shouldn't be that difficult to implement by taking Pages and just stripping them down.

[Karmalakas]

Just had a thought, such implementation would make users, who already use Pages structure, to move to this new library very easy by just moving file structure :)

[OleVik]

This is the domain for extensions; user://media-library is just a stream-wrapper for a folder, and there's nothing preventing a 1:1-mapping of folders like in user://pages. It just needs to be replicated on an applicable event from Admin, such as when Media is added, and the blueprint needs to send the files there instead.

The field to select Media can replicate the currently existing ones, adapting them as needed. There's nothing preventing a solution like in #323. This isn't apt for a Core-change, as Page and Pages are ultimately the most stable and utilized part of Grav. The Media-instance is currently bound to a Page, but that could and should be further decoupled. It's not necessary for a media library though, as they can be bound programmatically.

Which is to say, as a change to Core it would be backwards-incompatible with virtually all current installations of Grav and a vast array of extensions. As a plugin it only requires overriding some functionality in Admin, as it doesn't need to change anything in Core.

[phmg701]

Hello!
I am really interested in the Media Libray topic, as I am an hobbyist photographer and programmer.
I am currently trying to achieve a media library through Flex Objects and partially succeeded.
Of course lack of multilanguage support in Flex Object for the time being is a big limitation, although I believe that given the path to Grav 2.0, Flex Objects is the future.
My approach is to code a photos.yaml blueprint using standard Grav features. This Object has a single image/* attachment fileld, Title, Description, Caption.
What I am struggling with is Tags and Category, mainly because standard Grav Category and Tags are not fully implemented in Grav (yet) and neither is selectize field type (yet). Solving Selectize handling (with autocomplete function like it happens with standard Category and Tags) will open so many possibilities.
I also wanted to work with multi-language image metadata, and it somehow worked. Then shifted to Flex Objects, more future-proof in my opinion.
Please do not pay attention to my code styling as I am not a real programmer!
Thanks!