 Does it work? No. I think it works. Yeah. Does it work? Oh yeah, it works. Okay. Perfectly. So hello everybody. To our core conversation, state of the media initiative. So today we will present you what we currently achieved and what are our plans for the future and hopefully in the end we will have some time to answer all your questions and but if not, then we will have an extended both right after the session. So just to introduce you, to introduce us. My name is Christian. I'm one of the Thunder distribution developers and I'm a media core contributor the last couple of days and years and working a lot with media stuff. Yeah. I'm Adam, Benaproxima on d.o. I'll look at my own credentials here. I currently rock the lightning distribution for Acquia. I might help to maintain the media module and the migrate subsystem in core currently been doing this for 10 years and I make mistakes all the time. So. Okay. Well, everybody's introducing itself. I'm Sean. I'm a freelance developer doing Drupal for eight plus years and now a media core maintainer. So yeah, that's about it. Okay. So first we want to show you what's the current state in Drupal eight. With current state we mean until eight dot three. So we just have, yeah, file upload, image upload. You all know that you can add responsive images. You can place images in Visivik. We have some accessibility features like you have to add Alt title Alt tag and title tag and just basic file listing. So yeah, just basic integration, not nice things. So what we currently cannot do is reuse media. So you have to upload an image every time you want to use it. So if you want to reuse an image, it's not possible to use the image you already uploaded. You have to upload it again. Yeah, we don't have a site wide media library. That's what I said. We have no support for any remote stuff. So just support for uploading images or files, but it's not possible to add YouTube stuff, Twitter stuff and other remote media stuff. And we are not able to attach meter data to all these, to the files. So just title tag and Alt tag what you can do currently. And we have bike upload. Yeah, you can upload two images for a file field. That's it. In Contrp space, we are having file entity which extends the file functionality a bit so that you can attach fields to files, but you shouldn't use it because yeah, it's outdated and there's no maintenance anymore. And if you're looking for something in Contrp space, you should use media entity which has support for remote stuff and integrations for image and file uploads and stuff like that. So in Contrp space, we have advanced media ecosystem that grown in the last years. You can use entity browser which is really powerful. You can embed videos. You can embed anything with entity embed. And you have crop functionality for setting focal points or creating crops out of images. So media initiative. Okay, so as Christian just described, the ecosystem around media is mostly in Contrp right now out of the box with Drupal 8, mostly coalesced around media entity and all those modules he just mentioned. The media initiative aims to bring a significant amount of this into core. So the overarching goals of the media initiative, of which we are a part, is to implement in Drupal the basic media handling you would expect in any CMS. And okay, we're all thinking WordPress. I was thinking WordPress when I wrote that. But because this is Drupal, we don't just want to stop there. We want to have an API in place so that you can extend that, customize it, integrate with more stuff. And by integrate with more stuff, I'm talking about third party media services. I'm talking about dams. So it has to be very flexible. It has to be very Drupal-y, the good parts, the good way of Drupal-y. So the media initiative has three phases. Phase one is the current one and we're calling it essentials. And the goals of the essentials or the first phase of the media initiative are to define the APIs in core that support media handling in Drupal. It's also to have parity like interface parity, user interface parity with the core file and image modules. Because out of the box, the two types of media that core actually supports our files and images. And if we want people to start using the new media system, we're going to have to make damn sure that they can use files and images with as much ease as they are used to. We also want to bring in a media library so that, as Christian just said, you currently can't reuse files and images. You have to re-upload them while we're going to fix that. We want to support OMBED media. So like YouTube is an example of that, which is a very nice and easy way to support remote media in core. Most of this stuff is targeted for Drupal 8.5, and so far it's looking pretty good. Then we want to tackle embedding all this stuff into a WYSIWYG because that's obviously pretty crucial. A little bit harder. Looks like it's going to be 8.6, but hopefully we'll be able to accelerate that. Phase two of the media initiative is the extras, the extras phase. And that's all taking place in contrib space. And that's shiny things built on top of the relatively spare core media API, so like multi-image upload, cropping, really awesome browsing for files, media items, cooler things you can do with embedding. I don't know. The possibilities are endless. It's contrib. Possibly some of that, depending on how it looks, how it materializes in contrib, maybe some of that will be moved into core, but you didn't hear it from me. And then the third phase of the media initiative is pretty far off in the future right now. It's called the extend phase, and this is, again, all in contrib space, and this is really about integrating Drupal's media system, providing the tools to really cleanly integrate Drupal's media system with third-party dams and stuff like that, because Drupal's really, really flexible, but sometimes you just want to use another system that has solved a lot of the really hard problems. Media can get complicated. You could have, like, geo things, licensing things, adverts. I don't know the problem space that well personally, but we want to be able to integrate with those services that handle it better rather than roll it all ourselves. Sean, you want to cover this part? Sure. Okay, so architecture. What's really important is we try to make use of the standard APIs that's already in core. So media entity is core content entity, just like node is, for example. Then we have the media types that are config entities, just like node types are, so nothing new is going on here. Then we have a new situation going on with the source plugins, like media has a kind of reusable situation where you could have, like, a Facebook plugin that could provide the integration with the Facebook ID and maybe an author or whatever, and you can have multiple types of sources for a situation. So you have, like, an image. You can have, like, logos or maybe some other types of images. You can have different media types that are all using the same source plugin. And let me just dive into that a little deeper. So each media type is associated with one source plugin. Like I said, for images, for example, you can have logos or flyers or whatever. They can all be separate media types. The media source will be responsible for the logic, how it's saved. So you have, like, a file ID that's saved for a specific type. Also the validation and the metadata. You can have different types of metadata. Excuse me, can I have some water? That's associated with a specific source plugin. So you can have an author of an image. You can have the width, the height, all types of stuff that could come in for a source. We can also store that. And the media source is handling how the actual source is providing the data to your media type. And, like, the configurable field situation is when you want to store the metadata, you can just define the fields, like you would normally do for a node. Just put the fields in your media type, and every type of metadata, like the author or width or height, just store it in those fields. It's really a complex situation. I hope I explained it okay. So the media library is the second thing. We want to have, like, a paradigm version of what's already happening in other situations. So we have, like, the entity browser is already providing a great solution for picking different types of... picking different media entities right now. And we also looked at other systems just to provide a good way to reuse media. And it's not an API. You won't be able to extend the core media library. We just provide, like, an 80% use case and make sure that we solve that. And if you want to do something special, just do it in contrib. The display of items will be done through a regular view mode, so you can basically configure that how you want. And, yeah, just the way you just add that to a field is a widget for a regular entity reference field. So just configure that on your view mode or on your form, sorry, and then it will just work. The creation part of the media library would be really nice to have, but it's not part of our plan for the MVP, like the minimum valuable product. So, sorry. And it will be in a separate module. So we have a media in core right now, but the media library will be in a separate module and will be experimental at first. And we can work on that in a separate situation. So, yeah, it's not storing any data. So this is an image of what we are working towards. This will probably not be the MVP, as we call it, but this is, yeah, basically something that we created to just keep in mind where we want to go. And like what I said is the creation part will probably not be in there. We are looking at the tabs and just being able to select just different types of media and add it. But, yeah, we're working hard on it, but it's complex. So, next topic, our roadmap. What's already done, we have media entity module in core. Yay. And we renamed it to media, so don't be confused. We also have plugins for document and images, so that's already working. And, yeah, we have a stable API. The media module went in as stable, so you can rely on that and it's no experimental phase before. Some things where we are currently working on is the migration path from media entity to media in core. So this migration path will happen in the new branch of the media entity module. So there will be a 2.x branch for media entity and this branch will probably just have the upgrade path and no other code. So that's our plan, how we will do the updates. We have to implement widgets for media reference fields that we have parity with the current situation in core for files and images. And, of course, we need migration paths for file and image. This is all targeted for 8.5 and as shown that media library is targeted for 8.6. So, other smaller issues we are working on is per bundle permissions. Maybe this will go in at Drupalcon, I hope so. New source plugins for all embed support so that you can use or you can add media types for YouTube or Vimeo or stuff like that. Code improvements and improved metadata mapping. So that's just a short overview. If you want to look deeper in it, there is a roadmap issue with all the tasks. Okay. Most epic use here. So one of the things Christian just mentioned was the migration path. I would use the word cross grade to describe that because you have media entity. You have all these modules built on top of media entity with media entity as a dependency. Media entity is going to have, as he mentioned, a 2.x branch and all that 2.x branch is going to do is turn off media entity and turn on core media. So what that means is that we have to have all of those modules that currently rely on media entity. They have to start using the core media API. So we have to port those. We're sprinting on that here at Drupalcon. Help us out, please. But anyway. So how do you port your module that's been integrated with media entity as a custom module that has a dependency on media entity uses some of its features or some of its APIs? We wrote a really good change record. 2863992, if you can't see that, which describes exactly what you have to change. Use this interface instead of that interface. Extend this class instead of that one. Stop calling this method stuff like that. It's actually pretty straightforward for any coders. Should be. So yeah, when you want to start with Drupal 8 right now, what should you use? As much as it pays me to say it, continue to use media entity for now just because we haven't finished the cross-grade paths for all of media entity's ecosystem. But once we have, you should use core media. And media entity will be deprecated and we will update its project page on d.o. to say as much. And I just realized the third question is basically the same one as the second. But yeah, you can use. I think the main point here is once you're using core media, you can use any other contrib module that is built on core media. Pretty simple, you know? And if you're going to be using a contrib module that still needs media entity, well, you're probably going to have conflicts and maybe should upgrade that module. But yeah, I think that's that. So we can always use all the help we can get with this stuff. And as I just mentioned, the most important thing right now for us is to port all of the, you know, 8.4 is about to come out and, you know, the media module is in there, so people are going to want to switch to this. And so all of the, at least, at the very least, we want to have the top ten most used contrib integrations with media entity to be ported over to core media. That's what we're mainly sprinting on here. So if you have module authoring experience, by all means help us out. If you want to join our initiative meetings, it's in the Drupal Media IRC channel on IRC every Wednesday at three Greenwich Meantime. And us three can be contacted or Gabor wherever he is. I don't think he's here. And yeah, that's it, I guess. So thank you. Any questions? If you have questions, then the mic, yes. Yeah, just come up to the mic. So one of the last things you mentioned is that if you need to rely on a contrib module that has not been ported yet to the core media entity, you should do that with care because generally that would force you to rely on the media entity entity type. If you have budget, would it make sense to work on porting the contrib module? Yeah, of course. So that is what you would recommend. So the maintainers of the module should definitely accept this as a proposal. This is the right way to move forward, right? Yes, I mean media entity is going to be deprecated anyway. So if they're stubbornly insisting on relying on media entity and I don't know why they would, then yeah. I think there are issues for... Okay, thank you. Yeah, please port modules. We like that. Sounds like a great start to things, but one thing that I didn't understand the reasoning behind was you're saying that the library browser would not be extensible. That feels like the wrong decision to me. Well, not being extensible made it sound scarier than it actually is. By not extensible, maybe that... Yeah, that was actually pretty bad word. It's not an API. We just mean it's not an API. It's not really going to have classes that you can extend or anything like that. It is going to use views, and it's going to use like a configurable view. So like if you want to change the filters or whatever that we give you in the media library, you will be able to do stuff like that. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. That's really powerful stuff. You can already do a lot of that. Yes. We wouldn't lock you down to one thing because everybody would hate us. Anybody else? Yes. Hi. So when Triple 8 came out, the only sort of media as such that it handled was images and they were image fields. But so my question is about when we bring things like video and audio into Drupal, we have an opportunity to manage the other stuff that goes around with that, like captions and transcripts and so on. Yes. And so if you had like video, videos which were files that lived on your own Drupal installation, you could maybe, how would you manage captions and transcripts there, especially when you might have a mixed media thing where some of the videos are on your own site and some come from YouTube and some come from Vimeo or whatever. And they have their own like ways of handling transcripts and captions. Do you think there could be an API level type thing or where in the structure would it be? Would it be in core or country? I think you could already do that. The way I would do that is I would create two media types, right? So as I think Sean said, every media type must be associated with one source plugin and the source plugin is really the heavy hitter in a media type. It sort of determines, it's really the bridge between sort of Drupal and whatever the media actually is like if it's YouTube, Vimeo or just some video file on your hard drive somewhere. So the source plugin is responsible for being able to say like, oh hello Vimeo plugin, can you get me a caption for this video and it could maybe talk to Vimeo and then get that back and then you could handle that differently for a local video plugin for example or a local video media type. So essentially, yeah, we already have that API already exists. And do you think that's going to be sort of stuff that will have sensible like defaults or stuff including core or is that more something that you can trim and site building needs to take into account? I mean in core is not going to have that. Core only has two media types to start with. It has file and image and I think we have sensible defaults provided for those, right? Yeah, we try to shift with at least people. But you know, TLDR, the API exists. Thank you. Gotcha. Okay, sorry, I have a slide. I don't have that man. Hi. Just this morning mentioned Facebook and Twitter and the like the new standard when it comes to like uploading media and stuff like that. Is there any part of the initiative that's like concentrating on the UX of the whole deal? Is it going to be JavaScript? Is it going to be some nice ways of like actually uploading the content for the editor? You know, that's a really advanced question in the sense that I don't even think I've thought about that before yet. I don't think we're thinking about that right now. I certainly wouldn't be opposed to having you know, I like nice UIs. I'm only human, you know. And I think we all do. So I don't know if we're going to have like really nice JavaScript UIs for dealing with this stuff and like there's also a certain, you know, there's like certain limitations of what we can do with just core's toolkits. You know, now granted if we end up getting like a JavaScript framework in core maybe you know, things start changing on that front then quite possibly but I don't think that the initiative, that the media initiative is necessarily concentrating on that in all honesty. We're working closely with the UX team and constantly going back and forth over all the decisions we make that's really considered as the user interface. So yeah, we are paying attention to it. We can always do better of course but at least we're interacting. If users are going to see it, we always check with UX people to make sure it makes sense before we commit it. So yeah, I think that's all the time we got. Sorry, but we have a ball. So if you have more questions, come on. Can I do one more? One more pretty please, come on. Okay, go ahead. Thanks for the presentation. For me, I work for a big organization having a lot of large websites building Drupal and the fine management that causes us two main problems. We don't have publication workflow for files and secondly it's not as search translatable. So are you going to address that and if you have an idea of when that will be addressed. Thank you. Well, it's an interesting question because the difference, like one of the reasons we didn't build this around...