 So, just to note, a session that is on the printed schedule for this room in this slot won't be happening, so if anybody came for that session, you're in the wrong room. If you are here for this session, then you are in the right room. Okay, do you know if there's a lot of people still coming from lunch, or? Okay. Hello, everybody. Welcome to a session about the progress of media initiative for Drupal 8. My name is Giannis. My handle in all various Internet things and Drupal.org and Twitter and all that is rsm. First I owe you an apology. I had a last minute problem with my slides, so I'm not used the completely up to date version. I pulled down things that was on GitHub, because we are storing these slides publicly, because mostly Dave and myself are working together on them and then giving this same talk on various events. But more or less everything except my presentation and my name should be on it, so I hope you will apologize me. I am a software engineer from Slovenia. It's a small country next to Italy and under Austria to give you an idea. I work at examiner.com. Examiner is one of the biggest Drupal websites. We do fun stuff. We handle a lot of traffic. We create a lot of content. We use Mongo, which is probably not very common in our community. We also recently started to share our content with various different destinations inside our mother corporation. To solve that problem properly, we started to work on publishing platform that will feed all these sites with content. We decided to go with Drupal 8. So a lot of stuff that I've been doing related to media is during my work time at examiner because we need these two, so just like a small note and thank you to my employer to allow me to do that. Sometimes I work on things that are not strictly necessary for what we need. So first thing, our slides about Drupal 7, what we have in Drupal 7 at the moment. We have file fields and image fields. You're probably all familiar with that and there are a lot of limitations. Files are limited to fields. You cannot reuse files. Drupal will automatically delete files for you if you delete a note that this file was uploaded to. You cannot make files fieldable, et cetera, but then we have a few contrib modules that improve that. We have file entity that which brings you possibility to add fields to files, which allows you to add metadata. Then we have file lock, which will prevent files from being automatically deleted because if you install one of the modules like media that extends core files with possibility to reuse them, then you certainly don't want files to be gone arbitrarily. Then we have a few extension modules that allow you to embed remote media. We have integration with CK editor and back port of entity embed, which I will tell more about later. There is also Scald module and a few other modules that basically do the same job by re-implementing everything from scratch. Scald could be compared to media and solutions around media feature-wise, but it doesn't share any code. This is one of the problems that we have in Drupal 7. We have a lot of competing solutions that don't cooperate. It's impossible to mix them, to integrate them. In my view, this is a huge waste of resources. Let's see what we have in Drupal 8 core. We finally have embedding in WYSIWYG because you will probably know that we have WYSIWYG in Drupal core by default now. One of the features that come with core WYSIWYG is embedding of images in the WYSIWYG area. It works quite nice. You can also add captions. You can define alignment. If you move this image around, caption follows you. It doesn't stay where the image was initially positioned. So that's a pretty good job. The only limitation that we have is that we cannot reuse files that are already in the system. We have to upload a file every time when we do this. It will also track file usage. If you try to delete the file and you are embedding it somewhere in some WYSIWYG area, Drupal won't allow you to do that because it will know that it's used somewhere and it will also tell you where, which is nice. This is something that competing solutions, which we often compare us with, don't have as far as I know. Then we have very basic file listing. You will see all the files that are in the system that were uploaded using file or image fields. You get basic information. You can filter this. It's a view, so you can modify it. But it's not a media library as you would expect it. You can't use it to organize files, to change them or anything like that. It's just a listing. We also have this, another view, which will list all the usages of a file to solve exactly that problem that I explained earlier with WYSIWYG. If a file is used in a WYSIWYG field somewhere, you will see it there. We also made the automatic cleanup configurable, so now it's much easier to override that because in Drupal 7 we needed another module. We had to fight that. Now in Drupal 8 we just have a simple configuration value, which we can set and either make this period after which files will be deleted longer or completely disabled. We fixed file deletion. We have WYSIWYG. We can embed images in WYSIWYG, but we can't embed anything else. We still cannot reuse files. We cannot field files. We cannot make them fieldable. It's hard for us to handle metadata. It's still limited to fields. We don't have media library or anything like that. Files are entities, but they're not full-featured entities as you would expect. And you will say, only that? It's like, what have you been doing all five years? And it's partly true. We spent a lot of time at the beginning of the release cycle with planning and also arguing a bit. But at New York Camp 2014 we came together. Organizers did a very good job of bringing everybody there on site and they locked us in a room and said, sit down and stay in there until you come with a solution. Which actually happened. We came with a plan. And the most important thing that we decided there, which maybe sounds like something minor, but conceptually is completely different than what we had before, it's creation of smaller independent components that are reusable and pluggable. Which means now we can have different competing media solutions that will be reusing same smaller pieces, which means collaboration, which means less waste of resources, less waste of our time. And that was the main achievement. Like instead of heavy media and scald, we decided to have smaller components oriented at very specific tasks like storing files, embedding files in WYSIWYG, picking files to be reused somewhere. So these are all smaller problems that are currently in the seven solved in big pieces and in the eight we're solving them in smaller modules that can be reused among different competing solutions. And another attribution to nice camp organizers this year, one year after this first meeting, they did a very good job of inviting us everyone to New York again where we had a sprint for a week, which helped us push forward a lot of things. And here we are, first independent component, which I already mentioned with the seven, it's entity embed. It's a module that solves embedding just any entity, not just file entities into WYSIWYG. It's currently in quite good shape. You can use it. We still have to improve UX. We still have plans how to abstract it. And it was also partly back ported to Drupal 7, so you can also use it there. We still have to integrate it with entity browser, which is another component I will explain later. And it looks like this. You configure different embed buttons. Each button is responsible for one entity type. In this case, we configured button for files. Are you able to see this? So at the top it says file, and then from the drop-down, you basically picked which entity type your button will be responsible to. And this is most important at this point. Then you can also define which icon will be used with this button when you actually see it in the WYSIWYG toolbar and which four matters can be used with it and things like that. The most important part is you define a button and define which entity type this button works with. And then when you click on this button when working with the WYSIWYG editor, you get this page. And this is basically the autocomplete field that you are familiar with from, let's say, tagging with taxonomy terms. It will search for an entity, in this case, for this file, for this gif file. And then you will be able to define which formators, which formator to use for display and configuration for that formator. And then you also can define how to align it, like everything that you know from course image embedding. And here it is. And then you can edit it again. You can move it around. So it works very similar to course image embed except it supports just any entity. You can embed taxonomy terms into nodes or nodes into nodes. You can do crazy things with that, but we're not responsible if you do stupid things. And it also works in a very clean way. It's just one HTML attribute, it's custom Drupal's attribute with few data arguments that define which entity type is that, which entity type, which entity UUID is it, and configuration for formator. And then when rendering your content, text filter takes this and transforms it into a rendered version of your entity. So it won't persist, look and feel of the entity that you embedded in here. If you change the template later, it will respect that new template, which is very important. If you embed something and it stays like this forever, you come to a point when you want to redesign your page, all your embeds stay the same, which ends up being very ugly. This solution, it will also follow you when you do redesigns. We are also working on embed API. It's abstraction of the entity embed module. It's module that will provide foundation for various embed modules. One of them is entity embed, which I just showed to you. But then we also have URL embed, which works with URLs If you want to embed, let's say, a YouTube video, you can just use URL of that video and URL embed with some plugins should be able to handle that for you. And we're also planning to work on shortcode embed, which is something similar like in some forms you had some short codes, which would then translate into some kind of larger markup, would allow you to pre-define different pieces that you can reuse and things like that. Then next component is entity browser, which I already mentioned before. Entity browser is responsible for creating, displaying, and selecting content that you need to reuse in some other place. Let's say when we integrate this with the embedding solution, instead of having that ugly autocomplete field, we put entity browser in there and then entity browser allows you to open a model or something similar where you get lists of files that are in your system. And when you pick those files, entity browser takes care about communicating information about these files to the embedding solution, which then knows how to use them. Of course, we want to use views inside it, because views essentially provide all sorts of listings, and media library for example is just another listing, but it's not limited to that. Like you can have totally custom uploader solution where you just drag and drop images and system uploads them and creates file entities for you or anything else. We also integrated with inline entity form, so you can open an entity browser and then the inline entity form will appear, so you can actually create another entity in the same window, in the same field in touch. It's quite a complex solution, but we hope that when it's done, it will allow us to do very interesting things. Yeah, but it's kind of usable at the moment. We are using it in our PAP tool. The main constraint that we have at the moment is that there is no configuration UI, so if you know what you're doing, you can hack YAML files, which are basically configuration for entity browsers, and if you know how to do that, you can actually achieve a lot of things. If you don't know how to do that, then there is no UI that will help you, but we're always happy if you want to experiment with it, you can ping us and we will try to help. There is also a module that comes with some example configurations, which you can use as a starting point. It's called entity browser example, and it lives in the same repository. Let's see how it works. We have a very basic node here with title and one entity reference field. When we click on this button, we open the entity browser, and we have two so-called widgets in this browser. One is uploader and the other one is library. We currently uploaded a few images using the RobZone.js library, which allows to do drag and drop things and nice, fancy experiences like that. And then in the other widget, we have a view, which displays existing images in the system, and we created our, let's say, slideshow in two steps. We uploaded a few images and then we went into entity browser again and used a few other images that were already in the system. So this is perfectly possible to do. We are using this on our project. There are, of course, a lot of bugs and a lot of things that need to be improved, but I think it's a very good start. Okay, then we have another module, which is called inline entity form. But what's that? Isn't inline entity form Drupal Commerce stuff? Of course it is, but we said that we want to collaborate and we are not limiting ourselves just to modules that are created as part of media initiative, but we're also looking around and trying to identify modules that will work for us too. And inline entity form is an example of a module that was created for Drupal Commerce, but it's done in a very general way, which allows you to use it in a lot of other situations. And this is exactly what we want to do with our components. We are not limiting our components just to media use cases. You can use embed solution or entity browser solution for any other problem. You can use entity browser to search for related content that you want to link to the content that you are currently working on or things like that. Together with maintainers of inline entity form, we spend a lot of time to port it and it's very usable at the moment. It has entity browser integration, which means if you are familiar with inline entity form, you know that you have this possibility to create entities inline or to reference existing entities. And where you reference existing entities, they display an autocomplete field. We now swap this and display entity browser instead of that. So you can use entity browser to reference existing entities for inline entity form. It still needs some code cleanup I guess and we would like to have more tests in it, but it's very usable. So if you have use cases where this comes useful, you should really take a look at it. This will be a similar example than what I showed previously. Instead of having these very basic list of files, we swapped that with the inline entity form, which makes it even nicer. So we can create a photo media entity with inline entity form and then we see this familiar table that we also had in D7. And then here below you can see that we opened the entity browser. It's this entity browser that swapped the autocomplete field and now we are uploading few more files and we should probably scroll this up a little bit. And when files are uploaded, upload widget creates media entities for you and you get them in this table. And now you can reorder them or edit them which we'll use inline entity form. So it gets very interesting. Like you can mix all these different modules from Drupal ecosystem to achieve very interesting experiences. Then we have file entity. File entity is we call it storage component. It's one of the ways how to store your media, how to store your files. Currently there is an unofficial port. There is some planning going on how to approach this for DE8. Maintainers want to change its approach a little bit from D7 but they don't agree on it entirely. But if you want to use it on existing Drupal site you can use unofficial port. This unofficial port is already used on live websites as far as I know. So if there will be a radical change when port becomes official I guess there will be some kind of migration path. But disclaimer don't use it in production. But listen to me. Then media from Drupal 7. Media will be just one of the, this full featured providers of media experience or I tend to call it. It will basically just glue all the components together. It will depend to other smaller modules and come with some basic configuration. And of course this can be done when components or at least majority of components are finished. So we don't have any news about that. But you don't have to wait for media to be finished. Like you can start playing with these smaller components and there is quite big possibility that for at least some use cases that you might have will be enough. You just have to play with configuration and try to put it together in a way that works for you. I see these modules like media that provide, just basically provide configuration and dependencies more like an example modules in D8. You will be able to use them but you could only use them as a reference to see how they do it and then you could do it in a slightly different way. Like I usually compare this to Drupal Commerce which comes with a lot of modules. It's huge ecosystem. And you have two ways of approaching it. You can use commerce kickstart distribution which brings everything together gives you a lot of defaults configuration. So you have better feeling of what is possible but you can certainly pick just individual modules from the commerce ecosystem and build your own solution without touching commerce kickstart at all. And I see modules like media like kind of equivalent of commerce kickstart in our case. Then we have media entity module. It is alternative storage solution like kind of competing with file entity. It stores your media in a slightly different way. It takes slightly different approach. It creates a new entity type from scratch and then uses standard Drupal Field API to do everything else. It's very usable at the moment. We have basic UI. We have an API to handle metadata. Let's say if you create a reference to a YouTube video in your system and you want this module to pull metadata from YouTube and store it in local fields, it allows you to do that. And we already have a lot of providers. You can use it with YouTube, with local files, with Twitter, with tweets. You can treat your tweets as your media. It integrates with Instagram and some guys are currently working on audio plugin for it. And it comes with very basic media library too. We still have to integrate media library with entity browser, which will make library usable inside of entity browser's views, which will then give you nicer experience when searching the existing media items in your system. Like video that I showed earlier had a simple table with thumbnails and checkboxes. So this is kind of improvement on top of that. We also missed some configuration UI with this module too. We have some, but not everything can be done in UI. So if you really have to want to play with it, you will have to hack YAML files at the moment. And we don't handle any rendering at the moment, but since this is very standard Drupal entity with reusing standard Drupal files fields, like file field or image fields, and you can configure your rendering to some extent with just with stuff that comes with core. And it also comes with like validation API that will let's say if you want to create a piece of media, in our case, the tweet, and you copy URL or an embed code of a tweet that you want to use. And then if you do a typo when copying this, let's do a typo, validation will kick in and it won't allow you to save that because it will detect that this isn't actually a reference to an existing tweet, even if it looks like one. But when we fix that typo, we save it and then you will see that we have two other fields called tweet content and retweet count, which is now filled in automatically for you because I define mapping and told media entity to fetch this information from Twitter's API and to save it in a field for me so I can use it locally. And we also have media PINCHI module, which is not a disease. And it's like first let's say usable example of a full featured solution. It's a module that depends on media entity and comes with some basic configuration and if you want to play with media entity, you can just download this, install it and you will get a lot of default configuration which you can use to explore. And learn. And then we also have crop API. It's a very basic module that tries to provide very basic APIs for cropping tools. It gives you storage, which is using entity API. It's not using custom tables like solutions in D7 date. We have entities now and it is designed in a way that can handle both of most common approaches that we have in cropping world. One being defining an area which you want to crop and the other one being just defining a focal point. So this storage mechanism is able to store both of them and then it also comes with few basic image effects which you can use then to define your image styles that will be using this crop information. There is no UI yet and we won't be adding any UIs to this module. What we're hoping is that people will be using this storage component when they will start working on their UIs and the biggest benefits we see here is UI is a very subjective thing. I like one solution and somebody else likes another solution and it may also happen that you start with something and then you don't like it anymore and you want to switch to something else that looks a little bit differently. If all the crop UIs will be reusing this same storage component, you can just swap them because the data that is stored underneath stays the same and we also save some work because not every crop solution will have to re-implement storage and image effects over and over again. And there are already some people working on UI parts of it so we are seeing some traction there which makes me very happy. Then we have Drop Zone JS integration. Drop Zone JS is the drag and drop uploader tool that you saw in one of the screencasts, actually in two of the screencasts. It is using Drop Zone JS library and our integration module initially provides form element which means you can use Drop Zone for any form if you have a completely custom form for whatever use case you have. You can use Drop Zone there and then we have entity browser integration on top of that which is what you saw in action previously. We still have to integrate it with core image and file fields and we're hoping that we'll be able to do this sooner rather than later. One of our members is already working on this. And then we need to do some cleanup and tests and I think this will be everything that this module will provide but since it gives you a very basic form element you will be able to do a lot of interesting things with it. This is Drop Zone's webpage and you already seen how it works. It creates an area where you can drop files and it will upload them asynchronously or if you don't like drag and drop you can just click on this area and it will open file browser for you. And I hope that this will be replacement for Plopload module in the eighth because Plopload comes with a lot of extra weight. It has different back ends. It comes with HTML5 back end with flash back end with silver light back end and I think we are in the times where we hopefully don't need that anymore. This is purely HTML5 so it's much cleaner, it's much nicer to work with. Then we also have full back formatter which is basically a field formatter that allows you to create priority list of formatters that might be usable for your field and then first of them which will return useful content will be used. One usage for this would be a field where you reference videos and you have few videos from YouTube, few videos from Vimeo, few local ones and you can't use one formatter for everything. So you would use full back formatter and then tell full back formatter that you want to use either YouTube formatter, Vimeo or local video one and then full back formatter will be able to determine which one of them should be used for a specific item that you uploaded or created. Then we also, I think this module already exists for the seven, it's been in planning for the eight I believe and it's basically reusing of formatters for image fields, file fields and entity reference fields. Like currently in Drupal Core you have special formatter for file fields and special formatter for image field and sometimes you would like to reuse them for whatever reason, because both fields essentially store files, reference to a file and this module will allow you to mix that. Then also file download module which will be responsible for downloading files, serving files, sorry, and logging that. And so where are we? We stayed with the plan that we will stick to smaller components and especially the example of inline entity form shows how successful this is. Like if we wouldn't go down that route we could never use inline entity form for media cases, but now we can and we've seen that it works. We built momentum to some extent, we would still love to see more momentum. I did notice that recently when Drupal 8 itself is approaching state where people will have courage to use it, more and more people started to send emails to Ping on IRC, asking questions, trying to play with components and we've been trying to mentor all these people and to guide them. So I think that momentum is actually building. It's just maybe we wished that it would happen faster, but sometimes you can't speed things up until they are ready. We struggle with communication a little bit. We don't communicate enough with the community. Like we have these kind of sessions, but I don't think that's enough because there are like tens of thousands of members of the community and they are not all in there. We'll see how that continues. We try to, if everyone that approaches us and asks for mentoring, reviews, suggestions, we try to answer. At least I can speak for myself. Sometimes it takes me like a few days more that I would like, but we all have other things to do in our lives. I am not sure what will happen if momentum grows rapidly because it's already sometimes too much of people asking things, so we will have to figure out how to solve that. And we are still looking for funding. We had few Google Summer of Code projects in the past. We had one this year too, which is essentially funded by Google, so it's kind of funding. And as I already said, Examiner allows me and some of my colleagues to work part of our time on things that benefit the entire community, but other than that, I'm not aware that anyone else would be doing media on non-voluntarily basis. We need help. That's the bottom line. If you noticed with every component, I also added very rough estimation, how much work is needed to complete it, which is very, very rough. I might be completely wrong, but I was just curious, because we never did that before, and I was just curious if we just do very rough estimations for every component and sum everything together to see what the actual figure will be. And when I summed up everything from previous slides, it came to around 20, 24 developer months, which is a lot of work. And we can probably predict that it will be even more, because if we have very defragmented community, when people can just spend an hour a month, we spend a lot of time with communications, so this might even go up. This doesn't mean that media in the eight won't be usable before that. Like as you've seen, you can solve a lot of problems already, but there will certainly be things that you have to work around until we invest at least this amount of time. And as I said, don't hold me on that. I was just curious. It was interesting to see a number. This is a list of our contributors. We are seeing more and more of them, and there's more than one frame for pictures of all of you. If you want to get involved, we have Drupalmedia.org page. We have weekly scroll meetings on our IRC channel. We have a group on groups.drupal.org. And I would say if you follow our group, it's probably the best single point source of information. We store our code on GitHub group, but we sync all our repos to project pages on Drupal.org. So if you either go on GitHub or look for these projects that I explained on d.o., you should find the latest version of code. And we are also using issue queues, Drupal.org issue queues for development. Just instead of patches, we use pull requests on GitHub because it's easier to review, but all the pull requests should be linked from the issues. So you should have references around. And if you are shy and you don't want to expose yourself in public like in IRC or on our group, you can ping Dave or myself directly if you have any questions or concerns, suggestions, ideas. We're always happy to listen and help. Very happy to help. We also started a Drupal 8 media guide which is on GitHub too. It's basically a GitHub repository. There is not a lot of useful information in there yet, but it's improving and we want this to be the main source of information for Drupal 8 media in general. We have a sprint on Friday. We're also sprinting to some extent during the week. And we will have a sprint at Batcamp. So if you want to help, come to me on Friday or if you are in Berkeley, end of next month, you're also invited to join us. I will also like to mention Aaron. He was a very, very important Drupal media contributor. We always succeed standing on giant shoulders and he was our giant. He was diagnosed with ALS and he passed away this year, but now we have this yearly Aaron Wimburn award to respect his memory. Thank you, Aaron. And thank you. And if you have any questions, there's a microphone. Because all the sessions are recorded, you have to speak into it. Hi there. So I see that you were typing in different languages and how, do you know if anybody is using this on a multilingual, any bold site yet? With this meaning like the group of media tools? I suspect there are, but I don't have any firsthand information. Company called MD Systems from Zurich, they, I think they have quite a big website, media website on D8. I'm not sure, but I suspect since it's Switzerland and they have three languages, it might be that it's multilingual, but I'm not sure. You can ask Berdir, I think Sasha Berdir, he's in Barcelona, so I can ask him. Great, thank you. Great, and whoever, I'll talk to both of you guys then because I'm writing a Drupal 8 multilingual book and I was waiting on the status of media to tie that in. So this is perfect, thank you. So it probably comes down to the individual components. I'm not sure about file entity because I didn't use it much yet, but media entity basically does everything that should be done to be multilingual friendly. So you should have multilingual media entities and it's probably the same with file entity. So anything else? Okay, then thank you everyone and enjoy. Do you want to ask a question? Yeah, sure. With the framework as you've got it at the moment, is there any kind of way that on an instance basis you can kind of override metadata for media, so you've got say an image and you've got out and title tags as metadata and that gets reused every time you reuse that image. But then you want to say in this one place, I want to use that same image, but with different metadata, is that, does that kind of work within the new framework? So we don't have any special solution for that, but one way you could approach this already is let's say when you have media entity, which represents a local file, local image, it basically uses an image field on the media entity, which essentially means that you are referencing to a file, core file, which if you enable file entity module will be fieldable. So you could let's say add this metadata on this deepest level of a file and then create new instance of media entity every time when you use it and override metadata there. So that could be possible. And I think for this kind of use case, you probably need an intermediate entity every time because otherwise I didn't see any solution that would give you this capability without that at least something that would be implemented in a sensible way. And also we have entity API in core and it's very, very powerful, so we should be using it. So yeah, I think have an intermediate entity, whether it being media entity or anything else, you could also do a two step file entity too probably. So something like that. You have tools that can be used to build that, there is not a one click enable solution for that, definitely. I heard talk once about a migration path from Skald to Drupal 8 Media, what's the status on that? There's none. At least that I would know about, yeah. Okay, so no plans? There are plans to implement that certainly but there is nobody working on this at the moment as far as I know. But like people behind Skald, like open web solutions from Paris, they were represented on this discussion at NICE camp last year. So all these plan, how to approach media in the eighth was also based on feedback that they provided based on their experience with Skald. So, and media entity is actually inspired by Skald. Like it works in a very similar way than ATOM entities in Skald do. It's just extracted and lives in a separate module. So I would say that at some point, when somebody will need it, will write migration path from ATOM entities in the seven to media entity in the eight. And like it really comes down to the, everyone works on things that they need. So I can focus on things that my company needs for their own product and other people can focus on things that they need. There are some people that do something just purely out of passion but that won't sustain development of solution of that scale forever. So it comes down to if you need something and it's not there yet, you probably have to implement it. Or if you're lucky, you find one or two other people that need roughly the same thing and then you have to contribute it back. We don't have one big commercial entity behind media initiative. Like we have commerce guys behind triple commerce. So we don't have somebody who is funding development. So I guess this is the only way. And that's why I think communication is one of the most important thing for our initiative because if we won't be communicating enough, people won't be following like common plan when working or on their own solutions. That's why I think this will become even more important when a lot of new D8 projects will appear. Okay, you deserve your coffee. Thank you.