Scalable & Sustainable Media Management for Drupal Websites
Everyone knows media management in Drupal has been, shall we say, problematic. From the pre-CCK days of a simple upload field on a content type, to the CCK days of a dedicated file and/or image field, to Drupal 7's built-in file and image field, it has never been “done right”. For me, the two pain points are: reusability of media assets (using the same image in more than one location for example) and media being deleted if it is not attached to any page on the site (even though you may need it later on, so may wish for it to remain in your library).
When working on a large website last year which had about 20,000 media files (images, audio, video, pdfs, etc), I was asked as a solutions architect to come up with a way to manage these in a sustainable manner. This meant being able to categorise the files, search through them, retrieve them at will, and reuse wherever was wanted on the website. Also, the files should be available (and new ones be able to be added to the library) even if they were not being immediately used. Basically, kill both pain points. Time to get serious about media management I thought and started to do some research.
Media Module
The most popular option being used (by a huge factor) is the media module, but it didn't seem right to me in this case. Yes, it meant I could reuse media in different contexts and I could browse through a media library, but there was very little tagging of items. This would mean a flat list of 20,000 assets to scroll through to find the one I wanted. (I know, we could add fields and exposed filters and make it do what we wanted, but ...). Another problem was that if a media item was only on one page and that page was deleted, the media item also got deleted - “Where did our 2011 annual report go?”.
Asset and Scald Modules
Next I thought about creating my own content type or entity type that could be referenced by any other entity and displayed via view modes. Sounds simple? It's not. After more sleuthing, I came across two modules that seemed to work as I would like them to: Asset and Scald. Asset looked very promising (still does) but didn't have a stable release at the time (still doesn't). Scald had been used on some very large media websites in France and looked like it ticked all the boxes. Coming with a very slick media browser, a drag and drop interface for embedding media, and a custom fieldable entity type (called “atoms”), I was smitten.
I installed the Scald Galaxy distribution on SimplyTest.me to kick the tyres before installing it on my own computer. I then previewed it to our client, showing them how it works and how it can be extended to include lots of providers such as Twitter, SoundCloud, Instagram and more. The client loved it and gave me licence to keep investigating things like migrating from a legacy file management system to Scald and organising the exposed filters in different manners.
Getting Scalded in Prague
So where to next? Prague, of course. For DrupalCon. And now I had a mission: to take part in an all day “Birds of a Feather” session on media management. Who was at this? Well, the creators of Scald amongst others - they had just given a session on media management. The session was very full on with lots of very, very clever ideas – getting right down to the core of “what exactly is a media asset in the first place?”. This became the starting point for a “media management in Drupal 8” working group (that's us in the photo, just to prove it!). Let's just say, media in D8 is going to be a huge leap forward.
Scald it was going to be. However, choosing a solution and implementing it are two very different untamed beasts. In the next part of this series I will focus on installing and configuring Scald – exporting the configuration and creating custom Scald contexts (that's where it gets tricky).
In the meantime, if you want to discuss anything about media management in Drupal, feel free to get in contact using the link below.
If you want to discuss Annertech helping you build our contact form.