Home / Comment permalink

The future of multimedia in D7 or "You don't want me to kill the monkey do you?"

Hey folks,

Did you know that Drupal 7 will have a amazing multimedia capabilities due in large part to the Media module?

Hi, my name is Jacob Singh.

You may remember me from such kick-ass projects as Acquia Search (ApacheSolr), Drupal Gardens or GUI updates in core.  You may also just be dying to know what's going to happen to the monkey.  Either way, I'm here to tell you about what I've been up to along with many of my colleagues and Drupal buddies.

The Media module provides a rich interface for:

  • Managing files
  • Uploading new files or adding them from the internets
  • Browsing existing files
  • Embedding files in WYSIWYG editors
  • Adding fields and meta-data to files
  • Generally making Drupal suck less when it comes to files.

But don't take my word for it, watch me stumble through this demo (about 5 min of fast paced monkey-on-baby action)

and then vote for my media session at Drupalcon

Content | Site-Install.png


Posted on by tstoeckler (not verified).

First off: Great stuff!
Can't wait to get my hands on that.

The fact that you can add a Media field to e.g. a node, which is in turn fieldable (and shows those fields in the node), sounds a lot like Fieldable Fields.
Over at #695636: Figure out whether Fields API and Multigroup module can coexist that was discussed as a possible successor of the Multigroup functionality in CCK 3.x. Maybe you could leave a short note there about the approach Media module has taken and how that worked out.

Posted on by yched (not verified).

Re Tobias Stöckler :

The only similarity is that both would be 'reference' fields, i.e fields whose values are ids of other objects - 'node' for noderef, 'taxo term' for D7 taxo fields, 'file' for D7 file and image fields, 'media' for Media field...

Fieldable fields (as a possible approach for the infamous 'combo field' request) boil down to nothing else than a 'ghost-entity reference' field : i.e., a field whose values are ids of entities of a specific, dedicated type. Those 'ghost entities' hold the values in the 'combo field'; unlike nodes, taxo terms, files, media..., they have no visible existence in you site (display, edit form) other than being 'embedded' into the display and edit form of the parent entity. The field values appear as if they belonged to the parent entity, when in fact they belong to a 'sub-entity' through an indirection.

None of this is ready yet, and right now there is no guarantee that it will be at some point. As far as I remember, the tricky bits notably reside in this 'form / subform' area, and also in the way this approach would translate in Field UI.

In short : 'fieldable fields' relate to 'Media fields' only to the same (limited) extent than they are to good old noderef fields. I'm not sure the specific case of Media fields carries interesting knowledge on that regard.

Posted on by Jacob Singh.

Hi Tobias,

Thanks for the comment. I agree while writing it I said to myself.. hmm this would be better represented as some kind of entity reference API... but I like to build APIs after building working products, so looking forward to seeing what kind of integration will make sense there. The Acquia focus has been on WYSIWYG and usability thus far, but there will be a big push to the data driven side soon as we start supporting a slicker file browser as well as galleries.

Let's get in touch at DrupalCon. To chat about it.


Posted on by scmeeven (not verified).

Curious what the monkey alludes to :-)

Posted on by Jacob Singh.

Vote for my DrupalCon session or my daughter eats the monkey.

htt p://cph2010.drupal.org/sessions/rich-multimedia-drupal-7

Posted on by Crell (not verified).

Cool stuff.

One of the big questions I have with Media, though, is scalability of the interface. The media browser currently appears to give one big list. That's going to fall flat once there are a few hundred or, god forbid, a few thousand entries in the library.

Moreover, I've had cases where I've needed to say that certain users can use certain media but not others. Or a certain node can only use media that has a given flag, or is in a given nodequeue (D6 approaches, anyway). I'm unclear how Media module would handle such more robust use cases. (If it does, that will be awesome.)

Posted on by arlinsandbulte (not verified).

Yes, I would really like to know this as well.
The browser interface really needs some sort of organizational structure, IMO. Like a folder/directory structure. Not that the files themselves need to be stored in the same directory type structure. Rather, tags, fields, and/or taxonomy attached to a media item could be used to give the media items an organizational structure which could then be used in the media interface to organize the presentation of media items as well as limit the media items available to certain users.

I get the feeling that this is possible, but requires custom coding or additional modules.

Posted on by Robert Douglass.

Views. I want to be able to filter by views. No more, no less. That solves every use case that there is.

I can imagine a dropdown that has all the views that are meant to act as media filters. Then, each view can have its own exposed filters. We can package some standard views/filters that make sense, like "my files", "files by tag", etc.

Robert Douglass
Senior Drupal Advisor, Acquia

Posted on by Jacob Singh.

We're actually hotly debating this very topic :)

What would you like to see in filters? Here are the various approaches:

1). Folder based. Everyone knows and love/hates it.
2). Tag based. Gmail did it, kinda worked. Doesn't work in lots of other places.
3). Text searches and filters - ala Finder or views exposed filters.

Any other ideas?

Btw, the current design actually pages as you scroll, so it does scale, it's just hard to find stuff.


Posted on by sun (not verified).

...by "Jacob" and "Singh", actually :P

First name and last name, that is. Of course, it's all views. But we need to think about (potentially endless) drill-down and abstraction of exposed Views filters to make things really useful.

Yes, we absolutely need to filter by files that are used more than once. (New file usage API to the rescue.)

Oh, and that said, filter by where a file is used? Entity type, at the very least?

It's going to get complicated. Don't even want to think about UIs here, although we have to. admin_views module shipped with admin_menu already provides a nice preview on the topic -- if all your administrative listing pages are views, you actually, really, totally, awesomely want much more, immediately!

However, changes are applied persistently, for everyone. You can't just go ahead and, for now, quickly filter all nodes to only match those that are assigned to taxonomy term 123, or assigned to any term in vocabulary id 6. But you absolutely want to!

Simply installing admin_views blows your mind makes you believe that you're actually sitting in front of the CMS of the future. But the day you're starting to use the äwesomesauce, you're going to ask for more. Permanently, or just quickly for the next required maintenance task you're facing.

Refreshed possibilities create new bugs. :)

Daniel F. Kudwien
unleashed mind

Posted on by Jacob Singh.

Hey Daniel,

I've not seen admin_views, nor does it seem documented so I'll have to take it for a spin when I get time on Monday/Tue. You're absolutely right about views as a potential backend. But for an end user who just installs the mod, some reasonable defaults with nice looking UI is a must. What are these default filters?

To your other point about tracking used files. Yes, this is great and it is also kinda impossible with embedded media :( I wish there was a nice solution for that. It is possible of course to track it whenever textfields are saved or loaded, but then you run the risk of getting out of date when dealing with API level changes or direct DB updates. I'm not sure really what the recourse is there when you can embed in any text area.