 Okay, hey everyone. It's about 10.45, so we'll go ahead and get started. Hope everyone's been having a good DrupalCon so far on the first day. The keynote was exciting and it's good to hear from Dries. So this is the Drupal Media Session. My name's Dave Reed. This is Aaron Winborn. And we're going to kind of just dual and split this presentation into two parts. So without further ado, I'm just going to kind of hand this off to Aaron to kind of start the first part. Hi everybody. My name is Aaron Winborn. I have been a developer with Avamatic for about six years. And a contributor to Drupal. I'm one of the maintainers for the embedded media field, module, views, slideshow, media, media YouTube, media Flickr, all the media stuff. And I guess I should probably introduce myself too before you go. So I'm Dave Reed. I work for Palantir.net based out of Chicago. And I'm probably most well known as the module hoarder because I maintain probably about upwards of 70 to 90 modules. I don't know how I do it, but I do, and media is one of them. So yeah, I'm excited just to be involved in this project, be working with Aaron. So again, I'll turn it over again. First I need to address the elephant in the room. This is not the one about uploading large files. I was recently diagnosed with ALS, which is more commonly known as Luke Erick's disease. And like Stephen Hawking. Unlike Mr. Hawking, I do not have access to universal health care or gobs of money, which means that chances are even that I'll die in a year or two. And if I'm one of the lucky 10% to live the decade, it'll most likely be in locked in state. I'm just saying that so that I need to make sure that I have help throughout the week. I need help lifting things like my laptop, opening doors, even feeding me during lunch. And most importantly, if you can click it, it's also affected my hearing. And so I apologize in advance if I'm having difficulty hearing you. But if you want to speak with me, which I definitely want to talk to people during the week, please make sure that I can see you speak or at least provide subtitles. So without further ado, let's talk about the media module. Let's talk about the goals, what the media project has been going for over the last few years. The first goal is unified media file management. This has been a principal guiding us since the beginning. It's been a really big mess in Drupal as many people know for dealing with media. We've been looking for a way to treat all media and file streams the same from the perspective of the Drupal database. This goal allows us to store and to access image files from the same places YouTube streams, for instance. The next goal is files as fieldable entities. What does that mean? Well, that's by accomplishing this, it allows us to add a field to a file which has become a first-class Drupal citizen right along with nodes, comments, users, taxonomy. This allows us to, for instance, we can tag taxonomy terms right onto the file itself and display it where it's embedded in line or as a field. Another useful case for fields on files which we used recently in Palantir is having a date field on a file as a publication window saying that this site can only use this file starting two weeks from now and they are only authorized to use it for one week. So we store that as a date field on the file and it works. Next would be a single browser for editorial control. This is the UI side of the media module. This is where things are exciting for the user, at least for the editors. They get to have one unified GUI that is the same across whether it's on the administration side or selecting a field or selecting a file in a field. You'll have thumbnails for all your images, YouTube and video, audio, whatever, all right there in the browser itself which you'll see in a few minutes. And then what you see is what you get. It's the same browser, it really works really well. This allows editors to embed media anywhere they have a text area, ensures the file structure is the same everywhere, allowing for instance a caption field to be displayed with the image whether it's part of the field or embedded in node content somewhere. And let's now forget about views integration. A long-standing goal of the media initiative has been to allow the browser to be built to modify using views so that with the editor, the browser on the side of the editor, we can have a new tab and be able to filter your files by the taxonomy term or by the UID owning the file or whether it's a YouTube video or whatever. You can just create a new tab on the fly with views and add it straight on there. You have all the access of all the power views like exposed filters and whatever all. So what was handling media prior to Drupal 7 like? That's pretty true. Let's talk about this. For a long time in Drupal, the only reasonable way to handle media was as an attachment to a node largely using the upload module. The upload module has been retired for Drupal 7, hooray. The other way would have been to embed media directly by opening up your filters which is not a good thing. I hope nobody's actually doing that. Then before we had CCK, there were three modules that were created that occupied an awesome namespace, image, video, and audio. They become the code to solution for anybody wanting to attach images, audio, or video into their site. Unfortunately, they were largely 4.7 solutions which created a node around each media instance which on the one side has all the power that node brings and on the other side has all the baggage that comes along with nodes. Now to be fair, the video and the audio modules have both recently been overhauled and so they now expose themselves to CCK integrating, at least with the video module is integrating with the file field now. Please go on. So along came CCK, there we go. Along came CCK which that gave us fields which allowed us to attach our media to field which does open up a lot of new possibilities and it opened the way for developers to come in so we had file field, image field, embedded media field, video field, audio field. And that got us close to where we wanted to go but it still didn't allow us to separate the media content from the node. So there was no unified API for storage access or display. Yeah, they were all just kind of doing their own thing. And every module largely handled its own file or media storage sometimes even modifying the core files table for the nefarious purposes. Please go on. The situation has slowly improved allowing at least some way of embedding media in line to content with the WYSIWYG and related modules including some hybrid solutions like node embed which was created for the White House and Rem Browser along with node reference embedded in line media. So basically there were ways to do what we wanted with media. I guess that's the point I'm trying to make is that prior to Drupal 7 we had easily a dozen or two dozen fairly good modules all tackling the same problems from a different direction and it was a real mess for anybody wanting to figure out what do I use and how do I get media into my content. Well and it was a fun process because you get it all set up for how you want to work with images and then, oh well we want to add YouTube videos to our site too. And you have to go back and install three more modules, configure it up and it's just an exhausting process. So it's not a good situation for developers in Drupal 6 and it's even worse for the administrators, the end users with no unified experience and a complicated UI. We've barely scratched the problems with Drupal 6 in media and there's some very interesting and creative solutions such as Media Mover for handling media across servers for processing storage and display. So let's jump ahead. In 2008 I had just published Drupal Multimedia and Arthur Folscher sent out a plea to several established developers in the media realm. He basically, he had a vision where let's go ahead and click it. He proposed a two-tier API to handle a mess. One side of this would be a resource manager for creating unified data storage for media content and the other side would create an extensible browser for editors. Having such an API would allow developers to more easily plug into the work and mining to reinvent the wheel for every solution. He initially called it Rich Media Guy or RimeG and after the first or second sprint in New York we settled on the name of Media. Robert Douglas donated the namespace and that began this process over the last four years now. So there was a flurry of initial activity. There was a lot of excitement in the community. The original proposal was out to about five or six developers and we had about two dozen people by the end of the year that were involved in the project. We called up the ongoing media sprint. We met several times throughout 2009. We added some patches to Drupal Core for an improved file API and stream wrapper registration system. We had a large number of sprints over the last few years now. We've had sprints that have been sponsored by several companies including Avamatic, ZivTech, Acquia, Palantir. We had Civic Actions and Sony. Lots of people. Denver Old Blue Media, the Drupal Association. So many people that have been involved now too. I don't even want to name everybody. You can look on the project page if you want to look at the list of maintainers. Hopefully a large number of you are here today. I don't know everybody by face. We had D7UX, the Drupal 7 user experience, jumped in at some point and they created some mock-ups which helped to visualize where we were headed. You can switch to the next slide. I've already talked about a lot of this. This brings us to the present day where we have the unofficial media initiative that Dave is headed up. We also have Thomas Spencer who has joined us today. He is doing a lot of work behind the scenes too for getting people in the media, the bug squad. It's helpful to get a good perspective on this vast history of where we've been. We've got to understand our history to know what can we prove on today. That's where we are now. We had a lot of big momentum pushed into the module. Acquia with Drupal Gardens and Drupal 7 usability, that really got a nice big push and got the module into beta for Drupal 7. Then a bunch of us at Palantir got involved too. We were starting to use a lot of media clients with public media, American public media and getting involved with that. We were like, hey, why don't we help out too? Last September we organized a sprint in Chicago and we made another really huge push. It was great to have everyone out there too. What we're going to head into now is the fun stuff that you get to see what you actually get to use now and can install yourself. We're taking advantage of all these improvements to Drupal 7 and pulling it all together. Now we have the new version of media. This part of the presentation contains more cats too. As a result of the sprint in Chicago that we had last fall, we finally pushed the module out of the beta status and we're now in release candidate. It kind of sucks that it's been so long since Drupal 7.0 came out and that we would still be in beta, but we're starting to finally get into a stable status. Hopefully we're having a little sprint on Friday, which you may see mentioned a couple of times. Hopefully maybe we'll get a 1.0 release out then, which would be really nice. One of the other major things that came out of the sprint in September was that we had a lot of really cool improvements that we wanted to make, but we didn't really want to delay an official release, cause more breakage, make more upgrade pains for people. This is where we started making another version before we even finished the first one. A lot of people might be like, why did you guys do that? It just made sense to us. But I'll kind of help distinguish the two right now. So there's a 1X version and a 2X version. The 1X, like I said, is in a release candidate phase and the 2X version right now is unstable. It's a nice, great name to show, hey, we're working with crazy stuff here. You want to try it out? Sure, but you're kind of on your own. We have a little wiki page linked there, which we'll have the presentation linked on the session page too with all these links that you can click on. That kind of details some of the differences between 1X and 2X. Basically, 1X right now is feature locked, so we're not adding anything new to it. We're basically only fixing bugs. And so new stuff like views integration, changing the way the UI works, that's all going to go in the 2X version. I will add a note that those adventurous people that do like hot sauce, we're using the 2X version in production right now, cause we're crazy. But also if anything breaks, I'm kind of on the hook for it at Palantir, so I'll fix it if something breaks. So that kind of helps differentiate the two versions. So if you need something stable that you want to launch a site and you maybe don't have the time to dedicate to keeping up with updates, that kind of thing, totally just use the 1X version of media. It's great. It's got most of the features that are in 2X. It's just going to not get the new stuff. I'd like to point out that you don't necessarily have to be scared of 2X, that there are a lot of production sites using it. I just try to be overly cautious with people. But if you have the resources for it, go ahead. And kind of we wanted to add another goal to the media project out of the sprint. Denver is a green city, because we wanted to make the media module green as well, because we had this media library that was written and it lists files and displays them and filters them. But it was all code we had written ourselves in the module. And so we're getting to thinking, there's a module out there that does this job really well of listing things and filtering things. Why don't we just use that? And to be fair, with the work that Acquia did with Drupal Gardens, views at that time was not at all ready either. So that was a business decision they made and they had to make it. And I don't blame them at all. And so what we basically did in the sprint was convert the media browser, which you'll see in not too long, to basically just be powered by views. So we added some filtering capability and we didn't really change that much from what you see, but the underlying part is just kind of really nice because you can add stuff to it and you can change it. You can add another tab based on a view. You can have multiple tabs for views. So we're trying to keep this new goal of not trying to write our own code if something else does it well and we're using it. It's something we're trying to use with core and symphony too. Let's just use it. It does what we want to do. Let's integrate it. And we can learn from each other and improve. So this is kind of what the media stack looks like right now. So at the bottom of the pyramid, we've got Drupal 7 core. We've got stream wrappers, file entities, all that good API stuff, file and image fields. And so for the media stack, we have a C tools dependency, so that's kind of the next level. And then we have what's called the file entity module. And so what this does, it's kind of more of an API to help round out what core does with files and make it more reusable because it used to be included in the media project itself with 1x, but for 2x we moved it out into a separate module so that other modules can use it too. It seemed kind of silly to hold onto that module just for ourselves. Why not share it? So we moved it out to its own separate project. Then the next level, we have the views integration, which is new for 2x as well. On top of that, we kind of have media, which kind of brings everything below it together. And it provides the UI, the media browser, the widgets, the WYSIWYG integration. And then of course you have all the extra stuff like media, YouTube, all the extra media modules that integrate with the base media module that are separate. They kind of just put the cherry on top. So I kind of want to explain a little bit more what file entity does, because that's kind of somewhat of a confusion. Basically it provides the API and the UI for viewing, editing, and deleting files as themselves. So you can go to file slash one, file slash one slash edit, file slash one slash delete. And it also provides a way to manage the fields for file types, which right now are defined as kind of standard audio, image, video application for stuff like PDF. And this also allows files to easily be extended since we provide a UI for this file entity. So people can do translation with files. You can enable rules with files. There's a lot of cool stuff. We've got a few to highlight later. So what does it not do? It does not allow you to change how those file types are defined. This is something that we have on our goals to be able to let you change. But for the most part, people just, you know, a PNG file, that's always going to be image. .mov file, that's always going to be a video. So for most people it's fine, but there are advanced use cases where you want to change that. We want to provide a file access API, because there's currently not really any... You have to give your user role the edit files permission, which allows them to edit any file on your site, which is not ideal at all. So that's one of the big things we want to push on our sprint on Friday. And we also don't really want to suck at performance, because right now there's a fun bug that every time an image is displayed using the file into the module, it has to read the image completely. So if you have a remote image, it has to read the image in fetch its dimensions, and that information is not stored somewhere. So we're going to fix that. And it's also not in core, which is again one of the things that we want to do for Drupal 8. We kind of want to put these API improvements in, it'll help others reuse it and help maintain the media module better. So what does media do? Again, it provides the unified UI for managing your files. You can upload new files using media. You can also do a mass import, point it to a directory, and media will suck all the files down from that directory, save it to its local directory, and save records for them. So it's kind of nice for new sites if you just have a large group of PDF files or something. It does the integration with WYSIWYG, which we'll get to see. And it also provides an API. So if you want to write your own browser plug-in, you can do that. We wrote one for Palantir to work with a remote data source and asset management software so the users can select, oh, I have this video in our remote software that hasn't been used yet on the site. Let's use that one. And it pulls it in. And it also provides a way to integrate with Flickr. All those will provide our modules too. And this is the fun part of what we don't do yet either in media. If you're not using images, it can be a little bit frustrating. If you're working with audio and video, it takes a little bit of work. I'll be honest about it. Because there's no way to display those files other than linking to them right now. So currently we recommend using something like OMBED or media front or media element to help an HTML5 audio or video tags for those that helps round those out. If you want to put those audio and video files embedded in with a WYSIWYG, it's also a little bit rough right now. It works great for images. Works great. But it's still a little rough. Being able to control more of the WYSIWYG stuff, we need to work on it. We need to make it easy to configure because it's about like five steps right now and it's really hard to walk people through that. They often miss a couple of steps and then get frustrated. And we don't have it well documented either. And it goes along with usability too. We do some usability testing. We know we're at fault. Like we're not perfect. We know that. And we have a lot of work to do. So we're honest with ourselves. We have a lot of things wrong. We want to fix them. So here we go. Here we go. We got some demos on what you can actually do with media right now. So this first video is going to be just basically configuring how you get media to work on an article content type. So we've got our demo site here. And this is an article. Sometimes I'm kind of slow when recording these. But so to add a field you go to your structure and your content types and hit edit, manage the fields on article. And so this is the Drupal 7 core field interface. So we're going to add a new file field. So we give it a label and we give it a little machine name too. So we select the file field type. And the next selection box is the widget type. Now core provides a file widget itself, but media provides this media file selector. That's the one you want. That's where all the magic happens. So here it's going to create the field for us. And it has, this is a really fun like three step process that we weren't happy about, that we had to put into core. This is not media it's doing, but people are working on making this part more usable in the multiple steps. So here we're actually editing the field and so there's a couple of important things. When you have that media widget you get a browser plug-ins, you get to select which ones appear. And if you don't select them they all appear. But if you wanted to people only to upload files you could just only check upload. It works out nice that way. There's a allowed file extensions for uploaded files. It doesn't apply to anything remote. That's only for things that are new and uploaded. So we put some standard extensions in there. If you had a remote provider like Flickr or YouTube you'd want to make sure to check the video in the allowed remote media types. This is something people commonly miss here. And then there's also a allowed schemes section. So if you wanted to restrict it to only YouTube you could do it here. But we're just going to allow a few things. We like being open. So that's kind of the important settings for the media widget. We're going to make it a little limited field. So there's our new field. We've got files right there. We're going to drag it up above the body and make it easier. You'll see we have an image field too. You can actually use the media file selector with core image fields as well. And really there's no big deal you can use them both. So here's the manage display tab for these fields. And so we've got our files field and we have to select how they're displayed. So we're going to select rendered file which means it's going to this is the file entity way of displaying it. And it basically works like node reference and user reference. It gives you a view mode to pick from. So we're going to pick large I think is what I did. Because that's also an important step that you will miss is once you've added the file you can't forget to configure how it's displayed. Otherwise it just kind of won't show up. So here we're editing and this is what media provides. This little select media button and here's the magic. There's the media browser. So we've got upload, web and our new views powered library. So there's the filtering and views. So I can change how it's sorted so I can see the ones that I've uploaded last the most awhile ago because that's where all my cat pictures are. And views does its thing just right in there in Ajax and I can pick an image. There's my cat Rodney. And there it's put a little preview of how I've selected it. You know I can hit the remove media and it'll cancel that selection. I can go and select something else. We'll do a bad image. I hate these develop generate images. And we can add another image to this field. We'll take some questions right after the demo. So that's kind of how the media widget browser works. And you can add your own browser tabs. It's a little confusing how to code it but it's possible. So then we're going to save this node and since I didn't configure to display it in the teaser view mode, I don't see it there. But here it's displaying the node and hey there's my image. It's my file and my cat. So that's how we use the widget. Alright and this next one is going to be using a remote video. So a YouTube video. So I've got the same content type my same field I selected that YouTube was allowed and remote video was allowed. So I've got a YouTube just an url that I copied in my browser's location bar and I'm just going to paste it in there. I don't need to know the ID I just copy paste and hit submit. Boom. There it is. It's even copied the name of the file from YouTube for me so I don't... Yeah see. So it works the same way as local files as YouTube files and I see it done there and there's me gift wrapping my cat. He was a sport. He put up with it. Took a couple of treats. I couldn't do it with my other cat. She'd kill me. So yeah that's how you that's how you'd work with remote stuff. I don't know what I did there. Alright. So I mean it's a unified UI. You'd work the same way with YouTube, same way with Flickr pictures. You just copy paste the url and it just works. It pulls in the file name from Flickr and it just it works. It's great. And one thing I want to point out too is that it also works with the image field in core too. Yes it does work with image field in core. So you could use Flickr with image field. So here we're going to do a short demo of how you add fields to a file and how you would edit that data. Because this can be kind of confusing and we're still working on the usability of this process. So for media 1x you would go into your configuration section and under the media there'd be a file types link but we just moved it in the 2x version back under structure. So oh wait this is WYSIWYG. Okay this is configuring the WYSIWYG. Sorry. So when you're configuring your WYSIWYG for media you have to first enable it as a text format. So you have to go to your text format. So this is full HTML. We've made sure that we have that advert media tags to mark up checked. That's the first step. And then there's a second step where we actually have to enable the media button in the WYSIWYG configuration too. So we're back and we hit our WYSIWYG profiles under full HTML we edit that. This is just using the WYSIWYG module with the CK editor library. It's not using the CK editor module it's the WYSIWYG module. So there we enabled the media browser it's going to be the only one it's going to be kind of lonely but that's okay. Now if we go back to our content I love those contextual links in Drupal 7. It's handy. So here we've got our body field I make sure that I have full HTML selected in order to use the WYSIWYG. And there we go. And there's our media button and again you get the same UI here for selecting files. You see all of the browser tabs here I'm just going to select a file from the library. And here you get an option on how to embed this file. So again this is using the view modes so we're going to select large and boom. There's that image embedded in our WYSIWYG. And now I'm going to make some typos. So pardon my typing. But it's just nice that it works consistently so you get the same UI in the WYSIWYG and again we're working on figuring out how to get audio and video embedded properly. Sometimes it doesn't work, sometimes it does work. The goal is to make it all work. So there we go. I click on the node and there's our embedded media. It just works in the body. So for configuring fields on a file we go to structure and to file types. So again in 1x it would be under configuration and media I just wanted to make that clear in 2x it's under structure. But once you get there it's the same thing. So here's our different file types. We've got application, audio, image, text, video and other. These kind of map to the default MIME types of files so PNG images is image slash PNG so it'd be an image file type. So here we're going to add a credit text field to our image because usually images have credits for who took the image. They're popular for most sites that are using media. And we're also going to add a tags field because why not tag an image? It's fun. I'll skip ahead a little bit. So there we've got our two fields credit and tags and again you want to make sure they are configured to display on your view mode. So by default they're hidden on anything but default. So I may drag them up to show make sure they're displayed. This is the tricky steps to this. So we've got my content again and I go in and edit and now I'm going to get to show you a new feature that's in the 2x module is this edit media button which kind of helps make this usable. So it just pops up a modal and I'm now editing the fields on that file directly from the node. And once I hit save those things are saved. I could just cancel out of the node editing. Those changes are made. So I'm filling in the fields and making sure it looks a little ugly but we're going to work on cleaning it up. So now all those changes have been saved and I'm just going to go back and view this node again. Because I've selected that rendered file how to display this field it's now going to also include the fields for that file. So there we go. I see that I've got my media, I've got the credit and I've got the tags for that file all included. So it's actually kind of nice. Just right there underneath the image. So. And that would affect an image no matter where it was placed like if you reused that image elsewhere. Yeah, if you reused this image the fields are going to stay the same. We're working on a use case to be able to say override an alternate text on one node versus another node. You'd want to be able to change that. But for the most part you want to use fields to be the same on that file no matter where. So like I said with the publication window that's going to be the same for that file no matter where it's used. And one more thing to show I believe this is going to be kind of what file entity displays and how you would manage the files themselves. So if you go to content there's actually a files tab and it now lists all the files that have been uploaded on your site in a nice little table type of file they are what size who uploaded it when it was last used so I've got my cat picture and I can I'm going to just view that file as its own thing so again we can see that it has the fields on there and I can edit this file a note you can't actually edit the file itself right now you can only edit the fields and I can go and delete it too if I wanted to hey that file is being used you might not want to delete it a cool thing if you have the multi-form module enabled you actually get a little edit multiple files operation which is kind of nice for bulk things if you want to edit 10 at once and it gives you just puts all the forms together and you can set save and it updates multiple files at once so that's the multi-form module that does that there so again you can delete it and so media actually adds on to this and gives you a thumbnails page kind of like what the media browser looks like but kind of instead of a listing it's thumbnails so you can do the same thing you can edit and delete from that screen so it's just nice to be able to see what those files are so it's handy and another thing that the file entity module adds for 2x only is this nice little add file so it kind of is like the media browser but it's own separate things so if you just wanted to upload some files you could just do it here or if you wanted to add a YouTube video but just to have later you could do it from here it's just kind of nice once we get into a nice access API built in you can say yeah this person can upload files and they can access this page right here so that's just kind of a nice thing for editors too and then one last short video we've been talking about the views browser and so we just want to show you that you can change it if you want to so if you have the views UI module enabled you'll see a media browser view and you just edit and unfortunately you can't change which fields are displayed right now but you can add filters you can add sorts you can expose those filters so we're going to add a filter for tags of course I do so we expose that filter give it a nicer label to hit save and so now if we go back to our media browser we'll be able to just see that so you can add if your editors want a different filter hey we want to see things that we want to add our date field to the exposed filter you can do that so there's our tags right there and it just works yeah there we go that's kind of the overview of what you can do with media right now and kind of some of the pitfalls and steps that people have when configuring it too and so now I said we'd take questions after the demo but we'll take them at the end too so we want to make sure we get through everything else some cool things that are also going on in the media ecosystem not just the media module but things we're going to highlight a few of those that we find really interesting there's a full wiki page there too with lots of stuff that people are working on one of these modules is the upload module so it's an HTML5 uploading library with flash fallback that allows you to do multiple files at once upload progress we're working on integrating it properly with media it does work from that little add file place already but it doesn't work with the media browser so we're working on that but it's a very cool project we're looking forward to helping it along there's the OMBED module so typically you've had separate modules for each of your remote providers like Flickr, YouTube, Vimeo the OMBED module is actually really interesting because it's an open standard that sites are using to describe what that video is about the name of it so that you don't really need you can just use OMBED and it will fetch that data and return it back and it's actually used on Drupal Gardens right now and it helps really enable oh I want to support this random video provider now and there's a service called Embedley that could possibly do it so it's nice to be able to provide support for lots of different stuff but if you just need a specific one like YouTube just using the media YouTube module works just great too there's the remote stream wrapper that I wrote it's another one of the 9D modules it allows you to actually link two files and leave them on the remote server and not bring them into your local Drupal install so it's useful for like stuff that's on CDNs if you just want to pull in external stuff there's lots of really weird use cases but it's fun and one of the interesting things for remote images it can actually generate local image styles so in Drupal 7 core you could make a thumbnail version of that remote file it'll store that thumbnail locally but keep the original source on the remote server it's cool and it has its own little media browser tab too there's the derivatives API project which was a google slumber of code from last year which is really neat because it's designed to be flexible like I've got a .mov file I want to transcode it into this different service and upload it to YouTube and it does it all through rules it's still a work in progress but it's really exciting to see there's the media update and translation modules that Achieve has been working on they currently only work for media 1x but if you want to like replace the actual file data of a file record you can do that or if you want to translate your files that works for that cool module that's being used on Drupal gardens it's a great crop so when you embed an image in the WYSIWYG if you right click on it you get options to like crop it or rotate it you apply an image style to it which is really handy lots of people like to use this so it's a cool thing to see yeah we're excited about that one too Travis Tidwell is working on the media front module which is kind of another way to display audios and videos I encourage people to give it a try it's really themeable it has playlist support it's a cool project also we have the media element module which I'm big if I like it a lot it's an external library like media front to display audio and video in HTML5 with backwards support and so I like using that one too so that's kind of some of the cool things that are going on in the media space so what we have left now is kind of where we're headed in media and so one of the things that we kind of decided on as maintainers at the Sprint back in Chicago last September was that we kind of wanted to form our own little group because Drupal 7, Drupal 8 core you probably heard about it in the keynote has the concept of initiatives there's an HTML5 initiative there's a translation initiative you know led by someone and for the purpose of encouraging development and improvements we kind of want to do that but just with the media module and like all the other modules that work with media that seems like a good idea so we kind of scoped it out in Chicago and we of course got really busy but we're starting to pick up more steam now we have a wiki page where kind of it helps defines the goals I'll just quickly go over them because one of the things we wanted to prevent was development of media module feeling like this which it could because it's like I want to help contribute something to media but who do I talk to is it really going to get in no one's going to look at my patch I'm just going to hit a brick wall why even bother and we totally don't want to have that happen that's not true at all we wanted to look like this it's like there's a wide open road we're going to run on it you can help us go you can add some gas to the tank we're just going to keep moving on you can join on if you want we got an open road and one of the things that helps is we actually now have a formal roadmap for the module which kind of just helps define our goals and people can see that and say oh I want to help with that feature and it just goes from there we also wanted to do this because we wanted to have better communication not only as maintainers of the module but also between the community too people that were interested in media module so we're actually having meetings every two weeks in IRC in the Drupal media channel and to open to anyone I encourage you to join if you can figure out how to join IRC and we just use it to talk about what we're working on this week our goals major blockers, things that are coming up so I'd highly encourage you to join in and it's also trying to get new people involved too you may be the cat that's hovering in the sink you don't want to pop out but we want you out of the sink and playing around with media and it's also kind of our way to make a commitment as media maintainers saying that we will be here we'll listen to issues we want to get you involved we want to involve everyone not just ourselves it's kind of a pat on the back but we think it's important because especially we don't want whoever has the most time and the most money to be kind of doing their own thing and going off and doing their own thing with media we want to make sure everyone's involved because it's happened in the past but we want to keep it as a community project community led community driven and part of this is we now have a media bug squad based on the views bug squad and Thomas Finsen is leaving that effort and people are getting involved in the queue and it's a good way to kind of get more familiar with media because you just kind of dive into the issue queue a little bit no I couldn't reproduce this issue so if you find Thomas you can ask him about the media bug squad and so how else do I become a member? well really you just become a member by getting involved there's no formal oh secret handshake you're now accepted into the media initiative you know we're involved in lots of places we have our project we have a group on groups.drupal.org we have a website which we're going to get up and running we are an IRC and we're also having a sprint on Friday and we kind of need some specific areas of help like corporate JavaScript, usability documentation people that like writing or testing things we would love to have your help we're having a sprint on Friday and one last thing I'd like to cover is what will media look like in Drupal 8? because it's kind of a little bit of an unknown right now you know there might be a core initiative an official not an official unofficial but an actually official media initiative it might be a subset of our little initiative but it'd be important to communicate with other things like an HTML5 initiative or a WYSIWYG you know keep that communication open for what we need for media handling and we recognize we have a long way to go still but we're making progress we're getting there still a long way to go so kind of for Drupal 8 what we'd like to do and if you'd like to hear more about this I'm having a core conversation tomorrow in the morning about Drupal 8 media but basically we want to put some improved APIs in the core so basically taking that file into the module and that the file edit and administration pages moving that into core and allow you to put fields on files and we can keep working on the media module in contrib working on the usability, working on the UI of it because we know it's not great but we need to make some improvements and really put it into core once we are feeling really good about it so we don't want to really rush it in because it's okay to download a module it's fine so again we'd really love to have you get involved we're looking to also sprint on Drupal 8 involvement on Friday so we'd love to have you some credits for our presentation and we're about wrapped up do we have any questions there's a microphone right in the middle there if you could have a question it would be great if you could go up to that everyone's so polite so anyway my question might be a little specific but I was really excited to see just what all you're putting into the 2.0 version of media since it's it's really much more extensible particularly with the views integration than media one was in my experience wondering so you'll still have the media element or media front as the primary means of displaying videos but I'm curious about in Drupal 6 we had embedded video field or whatever and then you could have a thumbnail of say a YouTube video and you could display that interview say if it was a content listing I'm wondering will there be that kind of capability as an alternative view mode for a video so the question is how do you get thumbnails of remote files like YouTube and stuff that capability is actually in the modules like media YouTube it'll generate the thumbnails for you it was actually in the demo video that little preview was generated by the module and OMBED also does that too so it's just part of the native functionality for those remote providers so that's integrated with views then in media 2 I think there's a patch to be able to display the file itself that we're working on but yes it will be I think that was the main thing I knew you could display it in the node it was more with views but thanks I was just going to say that hold on I can turn that off I was just going to add that the media YouTube module specifically will download a local copy of the image so it's available to image styles for resizing it displays it as a local file alright next question I also want to thank you for all the work you've done and I've been playing with the 2.0 branch also is there a reason why the file is not supported? what do you mean by file scheme not supported? so you've got HTTP and you've got public and private but the actual file you can't use file to get a local file on your server probably because there's just not a stream wrapper that implements it yet where would I go if I wanted to do something on that? I would probably have to talk to you later because I think just a stream wrapper would have to be written for it the remote stream wrapper actually implements HTTP and codes for that so I think it's just something that would have to be written for that and support it thank you this may be somewhat a loaded question but great work on the stuff so far going through your demos even for the 2.0 branch of the project the user experience the site admin seems to be not ideal let's say there's and for personal experience too it's rather convoluted to get your use cases I want to get images and I want to build something that's not an image gallery and I want to do something that's not a one-time embed on a page if I want to use some sort of semi-repeatable but not a field on a node type use of images or video whatever so to get from that thought to rendered images on a page consistently is an arcade process that involves multiple pages of lookup on groupstud on GDO or on issue queues I guess this is two questions so like one is who's leading the UI UX of the admin side of media and what can we do to improve it so the question is what are we doing for usability for the content editors we're actually starting a usability process a formal process with some awkward usability engineers and the Drupal usability team we're going to be doing some testing on how that process is actually used by site admins and content editors and what we will need to change in order to support it for them I would encourage you to get involved in the meeting because we discussed it a bunch last Thursday and how to get involved so I think we have time for one more if there's any more questions I'm totally on the conference I'm at a core conversation we have a bof on Wednesday or Thursday that's media related so you can totally come to me then very quick question you mentioned there's a module for handling the translation yes I missed the name of it it's the media translation module nice and easy alright thank you very much for coming enjoy the rest of the conference