 OK, hey everyone. This is the 215 session Media Ecosystem in Drupal 8. It was labeled double header on your sessions, so I hope you're in the right place. Yeah, so we'll go ahead and get started. And just kind of a little bit about who we are. Do you hear me? Yeah, you do. My name is Giannis. I'm working on the examiner moment. I started with Drupal, by coincidence, because a friend of mine was working at this international tennis tournament, and he was like, I need a website, and you can do it. And I was like, sure I can, but I've never done one before. And that's how I found Drupal, and I've been a happy member of Drupal community since then. I'm also maintaining discuss module, blog module. I was a student for Summer of Code. Now I'm mentoring, and yeah, that's it. And my name's Dave Reed. IRC Drupal is my same name, if you need to find me. I work for Lullabot as a senior developer right now, and I've been involved with Drupal for over nine years now, which feels like a really, really long time. I've been involved with lots of modules. I'm typically known as the module guy. And I apparently like to take on really hard problems and not ever give up. So that's why I'm involved with Drupal Media. So I've been working on this for the last four or five years now, and it feels like it's been a really long fight, and there's been a lot of great people helping along with this, including my co-presenter. But now we're starting to take a turn towards Drupal 8, and this is what we're going to talk about. All right, so just to kind of have a brief, why is media important in Drupal? I mean, I'm pretty sure we all kind of know this section just because it's a really important feature. People expect that we get this done right, because they want this all the time. Our competitors, such as WordPress or other systems, they have this out of the box, and they do it pretty darn well. And so Drupal kind of usually tends to take a negative checkbox when doing a comparison to other systems with this for media and asset handling, and that those people are enterprise clients too. Those are big clients. Those are big people we could have on Drupal. I would hate for media to be the reason why those people don't pick Drupal. So it's why we need to keep moving forward and get a good solution going. People use media a lot. Surprisingly, I don't know why this happens, but people like pictures and video and audio, so people expect to be able to use this on their site. So it's kind of a critical thing, along with content creation. So we need to get, it needs to happen. And people that actually do the content creation on the site, they don't want to be too burdened by the workflow. It needs to be an easy workflow. It needs to be something they can understand as well. And just kind of to encompass that all, we need to handle the media itself well. We need to treat it like a first class citizen, make sure we're allowing some people to add metadata about the media as well, all those kind of good things. And of course, the great quote by Dries, if I could snap my fingers and add one single feature to Drupal Core, it would be good media handling. And he said that in Portland, and he said it for like every Drupal Con before then and after then too. So it's always been like high on the list. Yeah, so Drupal 8 is approaching beta and we should have something in Drupal 8, right? Because features that were added were added and we're basically done with that. Oh, thanks. So yeah, we actually have few things in Drupal 8 that improved in core. One of them is file listing that is there by default. It looks similar to content listing. It tells you which files you uploaded through image and file fields and where are those files used. So you have kind of a track what's going on. You can do much more with it, but it's a view, so it's extendable, which means we can extend it in Contrib or you can extend it for needs of your site or something like that. Another thing is WizzWig integration. We can actually add inline images to WizzWig now. It works great, it supports captions, alignment, and yeah, but the only downside is it can only embed images. You cannot embed a video or something else. Yeah, yeah, yeah. Because it uses this data attributes and then when an entity is saved, it checks all the text area fields and looks for these data attributes. And third thing is multi-appload by default. We added like bound multiple attribute to file and managed file form API elements, so you can use multi-appload in your own forms and of course then we also implemented it for image and file fields. If you have a multi-value file field, you can now just go and select more than one file and it should work. It uses HTML5 multiple attribute, so it won't work on beloved browsers of older versions. It still degrades gracefully to single upload, so it still works. Yeah, so a little bit of history. A Drupalcom prog that happened last autumn. We had a core conversation and a sprint where we started to discuss how media in Drupal 8 should be approached. Yeah. So it was a more like a planning sprint. We didn't produce any code, we just came up with a plan. And like five simple bullet points of this plan would be we need to focus on use of use. We should support multi-appload by default. We should have nice wizarding integration, maybe drag and drop, things like that. We decided to go with a plugable framework because in Drupal 7 now we have several media solutions and none of them integrate between each other which means that we have to re-implement a lot of code several times. If we would have a plugable framework where these different media solutions could pick these components and use them, that would help a lot because we would develop code that does something just once. There would be no need to write redundant code. And it seems that doing a plugable framework of the coupled components would help us to solve that. Of course, one of the problems in D7 was that pretty much solid solutions came out very early in the D7 life cycle. So we should probably fix that and deliver at least basic components very soon in D8 life cycle. And actually decoupling things should help us with that because we will be able to bring on board all the developers of different solutions that we're competing before to work on these same components. And this way, we will hopefully get more resources to work on this. And of course, APIs in D8 are much, much more powerful there than in D7. And we want to use existing tools as much as we can because that means less work for us, better integration with some other solutions that might appear during life cycle. So, yeah. And the last step that was decided in Prague is that we should go with non-file-centric storage component. If I try to explain that. So in D7, we have two approaches, basically how we store files. One approach is file entity approach which takes cores files which are actually entities but probably not many people know that they are and extend it to be a real entity with fields and everything. And the other approach which is also, it is implemented right now in some D7 solutions is to go with some other entity that doesn't assume that everything will be local file because a file is tied to file-managed table and it has to use wrappers. And some people think that this is not very convenient for remote media like YouTube videos and Vimeo and stuff like that. Some people, some people. Some people. So yeah, this was the decision and yeah, we had the pointer back today. So it was kind of interesting because I did not get to attend DrupalCon Prague. So it was, I had an interesting viewpoint being able to follow kind of what's going on from the sideline and the team that was there kind of had this perspective of, if we could start over from fresh, what would we do? I think that's kind of a good perspective to take. Especially whenever you introduce a new Drupal major version, especially if you're like on Drupal 8 which has all these new things and great things. My perspective comes more along the lines of working with the file entity and media modules for such a long time. I think they're a great solution and solve all these problems. And we wanted to, we had this plan to continue porting them to Drupal 8. We didn't really have anything too well structured. But we kind of wanted to go with it. But we also recognized that we were not doing some things ideally. We wanted to take a look at some things that we wanted to fix and use the Drupal 8 cycle as an opportunity to fix them. I mean, first off the bat, we don't have a stable 2.x release of media module. So like, how can we start porting something if we don't even have it officially released yet? It's just kind of a big community pressure there. WizzyWig has always been kind of a big issue for a media module because we have to support the WizzyWig module or CK Editor or TinyMCE or any kind of various WizzyWig that comes up or is integrated through the WizzyWig module. And that tends to be very problematic and we're using a special syntax to embed the media which doesn't exactly work because it's not actually HTML. And there's just lots of issues going on there. I would describe it as overly complex out of the box that can be seen as a good thing or a bad thing. I think probably the thing that we struggle with the most is configuring how to display the files with the media module. That's kind of our biggest step. And that always seems to get people hung up. But once you understand that, you can see how complex and powerful it is too. We don't know how that goes any with any other modules like views or panels either. And media tends to have an uphill battle against core assumptions. Core assumes that files are used only once, they're locally uploaded files and that's it. But we wanted to reuse that because it already kind of provided this framework for us to extend. Core doesn't sometimes like to have things extended that way so that's kind of where things happen. Making sure that we have multiple uploads, the multi upload workflow kind of enhanced everywhere. Right now it's kind of like, it's single upload but if you have the plop load module and the multi-form module, then you can do multiple uploads and multiple editing but does it work properly all the time? That kind of thing. So we're having to battle two different workflows there. We've had to battle accessibility, making sure that we support alt and title tags properly with images and content all the time. That's always a hard one to think. And again, it comes down to usability versus extensibility. It's a very, very tough line to walk, especially for such a large module like this. And we have a problem figuring out what that balance is. And sustained maintainership. There are lots of really great maintainers for the module. Some of them are in this room, Devin, who really do a great job keeping it going but it's really hard because it's still a volunteer effort. I know Awkwia does put some time into it with their comments and demo teams which has been very helpful. But there's no lead driver of it and it kind of just is when people have the time to fix it. So that is kind of a trouble for us right now too but it's also been three, four years in the making and those people are kind of tired of trying to fix the same thing. So yeah. And there's more. I make it sound really, really bad but really it's a good module and I swear. I'm just tend to be a pessimist. That's all. So I kind of put together this document where we'd kind of, okay, here's all the problems we're facing, here's how we can maybe start tackling them for Drupal 8 and I kind of shared it with some of the other maintainers. With Drupal 8 we can kind of focus on involving this better workflow from day one, involving accessibility from day one, kind of splitting up the file entity module so that maybe files don't have to be fieldable by default, it just, it may be that's something people can optionally enable if they want it and it kind of has the same theme as what the Prague team did. De-coupling and kind of making sure that these features are more abstract and can be reusable where with the media module we kind of had these two big modules that did most of the work. So we wanted to kind of split that up and so that's kind of where we were looking at and we didn't really have any progress to show for that yet but that's where we were headed. So after the Prague Sprint there was a GDO post put out where they were like, okay, here's what we want to do. We want to have this separate media entity and it doesn't have to be a file and here's our proposal and you know, I'm gonna admit that as a file entity maintainer I didn't take it well. We were respectful but we were very disagreeing on how that should move forward and we tend to get, I think we got a little bit muddled in the very details like no, there should be files, no, they should be separate media entities and that was really the gist of our argument. It was a huge threat and it seemed stuck. Yeah, so they kind of stuck our progress for a little bit and that's kind of why we have the double header right now because we were both competing, offering competing core conversations but they both got accepted because there's a nice revolution to this. I think I was gonna go on this one. So we had a sprint at Nice Camp in New York City. I was invited to come. I was strongly encouraged to come because they were getting, they really like to get members of the media group together and I'm not gonna lie, I was really hesitant about going. I did not want to go because we had this conflict over storage and just I've been involved in media so long. I was starting to get really frustrated and I didn't want to help. I was getting close to abandoning the effort but they convinced me to come and we had this great group of people here that were there and we kind of locked ourselves in a little boardroom in the UN for an afternoon and we're like, okay. It was actually quite a good venue for something like that. It was a great venue, yeah. It's a good place to get locked up but there also is lots of security there. Yeah, that was- That was interesting. So we sat down and we grabbed a whiteboard and okay, okay. What are the common components that we need? Like let's figure out what we both need. Let's maybe just not agree about how things are stored. They can be files, they can be media entities. Maybe that's a good thing that we don't agree on that because it forces us to find where we can need our common needs. How, where our UI elements intersect and we can work on those together. So that's what we did. We're gonna keep working on our two separate storage components. So it's very likely that we'll have file entity and media entity in Drupal 8. We'll see how that goes. So yeah, we're gonna continue with that but we're going to make sure that we work on these independent parts together as a common goal because if we can get them to work for both of our storage parts, they should work for anyone. And that's kind of what we're going with there. And because we're gonna look at it from files or a media entity approach, you should be able to use this approach with nodes or anything else you'd like to that's an entity. Like we're setting kind of a lofty goal here. Like the things that we're doing, we want to make available for any entity type. So our embedding component where we're calling entity embed, you should be able to embed any kind of entity type in your Wizzier Wake field. We're going to solve it for everything. It's, yeah, we're ambitious. And this is a summer of code project. And sorry, do you want to say that? No, that's good. And it's going very well. I mean, like embedding, it already works basically. We are waiting for a core patch to be committed and it's now basically just the integration of the music editor and making it look and work nice. Like, and just because we're able to take a look at it from the ground up now, like all the problems that we usually have, like I think one of the number one requests we get in the media issue queue is like, I want to embed a link to my file in the Wizzier Wake. That's like use case number two. And we don't really have a good solution for that at times, we may have it fixed now, but like it works out a box with this new solution, which is really great. We're also going to have an entity browser component. So that's going to be your selection of the entities, viewing them, the kind of the tabbed interface for do I want to upload or do I want to select or do I want to use a file from the web? That's going to be the entity browser. And I kind of had a really fun revelation in New York that like these individual tabs in the browser, we're doing a lot of work to make those. And they're just selecting things. There's existing core functionality that does this. They're called widgets. And why don't we just make anything that gets used in the browser tab, make sure it's available as a widget first, and then we can just easily bring it all together. So it's like having a view of files. You should be able to use that with a file field itself and not using media. And it makes us focus on the usability of each component, each user interface of that. So like the upload or web UI where you paste in a URL, that should be a widget you can use on a file field. And it also makes those components reusable outside of the media ecosystem. So you could use that independently if you wanted to on your project. And I think that's a really, really great solution forward. Another interesting thing, the file entity, the way that you manage file displays, you're like, try YouTube first. And if that doesn't work, try an HTML5 video player first. And then if that falls back, try a generic file link. Like it try has this fallback method. We're actually abstracting that into its own formatter. So you have a formatter that you say, well try this first. And that didn't work, try this. And you can manage it right from the managed display screen. And anything else can use this too. So that's just a really nice solution forward as well. Yeah, so we have a roadmap. We don't have like delivery dates yet. But it like basically in step one, we need WYSIWYG embeds do the basic APIs. Namely, we need the text filter that converts like this DOM elements with data attributes to the actual rendered node or I mean any entity. We need entity browser that like has basic API and a working demo. Storage components are crucial part and the plugins system for these steps that Dave mentioned for the browser thing. And in step two, we have to focus on the UI UX of the embedding module. And we're actually already working on that. So we're on step two when it comes to embedding. We hope to have like at least part of step one of entity browser done here this week. And when both systems are working, we have to like try to integrate those so you would be able to use entity browser to actually select entities which are supposed to be embedded in WYSIWYG. Yeah, because right now it's just like a simple what type of entity are you embedding a select box and like type in the ID. Which is of course not the ideal thing. We wanna make sure that when entity browser is available we use that to select from the entity embedding. And when entity browser is basically done, then we want to use it to actually create media library. And then on step three, we do more like things that are very nice to have but not crucial for system to work. Like multi-appload and display configuration, things like that. And at the end we then plan to work on third-party integrations, we're all being dirty with this and other stuff. So this all sounds like a really great plan and I can see that you're all really enthused about it. But we actually, I'm gonna pull out the pessimist part of me again. We're gonna say hello to him, yes. Cause there's still some challenges that we face in Drupal 8 to make this happen. You know, we're feeling pretty confident we can get this done with this plan in place and kind of focusing on the individual parts but allowing them to work together really well. So I just kind of, since this is a core conversation, I wanted to make sure I bring up like, hey, what's still left in Drupal 8 that could really help unblock us kind of a thing? So if there's any core developers in the room, this is one you should really especially pay attention to and help us out of the code sprint on Friday. So kind of the big one that I think everyone should kind of pay attention to is how do we manage dependencies for contrib modules? How do we require the plopload library in our module? Right now there's no way for us to manage that. Composer is used for core but core also includes all the files that it needs. Is contrib going to be able to do that? Cause if we're gonna focus on making sure that we have those workflows from the start, we need to have those available right away and without any difficulty to download and set them up. So we need to focus on that. There's a really interesting problem in core. You may have heard Larry or other people talk about like we're decoupling core and all those good terms. But the fact is when you actually try to use stuff that should be decoupled, it's not. Which is kind of an interesting situation with Drupal 8. Like our plan to use widgets without actually having a real field in the browser, we wanna make sure that that actually is possible. We've had a real struggle getting formatters to work without a field. Saying just given an entity, I want to render it as the entity label, entity reference formatter. There's actually a lot of messy code to get that to work. So there's actually some issues there. And stuff like the links on your node and comments. If you want to hide those when you're embedding a node, you can't actually do that. You can't manage them in the display. They're just always visible. So we wanna make sure that things are just nicely done and that kind of, that's kind of more of a higher level one. Files in Drupal 8, this is kind of from the file entity side of things. They lack a proper access controller. So Drupal 8 introduced a new kind of standardized entity access method, but it doesn't actually work for files. So if you try and call those methods, it just returns false, which is great, because we wanna see our files. So that's an interesting one that we probably are gonna be working on on Friday. Probably the most challenging parts I've encountered so far are types, data and plugins. If you have a file with a space in the name, it fails cores validation to be a complete file entity, which is an issue. And say if you have a set of plugins, so the ways that our entity is rendered using the embedding stuff, you can either pick, use a view mode or use a formatter or use a file format or use an image formatter. Those are actually all plugins and it would be nice to have a plugin context system that said, hey, given that I've provided you a node entity, which plugins could work on this? And there's an issue for that in the core that Tim Plunkett just posted a couple days ago. And that would be nice to have. One of the biggest things that plagued us was one of these core assumptions that if you've uploaded a file to Drupal, used it on a field and maybe you removed that file and swapped it out for something else. Six hours later, Drupal will delete that old file for you, which becomes a problem when you want to add the concept of a reusable media framework to Drupal once the people stuff starts to go missing, when they know they uploaded it. And this we actually fixed in nice camp. So yay, we're happy about that. It's no longer a challenge. See, I'm positive for once. Don't encourage me. So yeah, now we're gonna turn back positive. Yeah, so we have a plan. We hope and believe that you like it. But there is obviously a lot of work to be done and we need your help. If you're interested in media, if you are a webshop that uses media solutions and it's not happy with them and you want to help us improve it, you should join us. So we need people of all sorts of experience. We will need a lot of front end work because a lot of most of the pop flow part is actually front end, a lot of JavaScript and making these things work. We need user experience professionals to advise us about how to design this flows. We also need backend devs, project managers. So if you have interest to help, there is something we can give you or you can give us. So don't say, I don't have skills for that. I'd actually love to point out, typically Drupal core initiatives have what's called initiative lead, who's kind of like the project manager for that initiative that helps drive development, communicate things, all those sorts of fun kind of project managing tasks. I have been acting kind of in that role but I also recognize that I am a developer. So I think we're probably gonna look for like someone who can be a good kind of media initiative lead. So if you're interested in that or know someone who might be interested in that, that would be great. Yeah and we definitely want to hear from you. Last week I was pinged by Webflow, he's a Drupal developer from Germany and he was like, hey I'm using entity embed on a project that's going out in a few days. And I was like, really? And we had a call and he showed me how they integrated entity embed with Wizzowig and how are they embedding stuff into body and I was like, wow, this is great. And wait, you mean the Drupal 8 code? Yeah. Oh, okay. Yeah. It's probably already released by now. And I was like, this is great and we can use most of your code. Can you push this to GitHub? And he said, yes, of course. And then we pinged our student that is working on this stuff and we said, you have code there that basically does what you want to implement. So go there and check it and maybe refactor it a little bit and that's it. So yeah, if you're doing this kind of things, let us know because if you will be hiding your code at home, then we will not improve this. I know at least one of you in this room has probably written their own media like asset management system. And if you have, you should probably talk to us. And another thing that I realized by discussing with Webflow was they're actually using entity embed to embed non-media entities also. So that proves that a generalized approach that we're taking about supporting all entities is the right way to go. Because I mean, it works great for them. I don't have stuff recorded. Yeah, with entity embed, anything is, that's an entity can be embedded. Anything, blocks, users, taxonomy terms. From the WYSIWYG standpoint, yes, yeah. So there are a few channels where you can get involved. We have a group on GDO. We have weekly scrum meetings on Hangout. We announce them on the GDO group. So if you follow that one, you should be fine. There are a few projects. It's entity browser, entity embed, fallback formator, media entity, media file entity. So you can go and check the issue queues. Media entity is that non-file-centric storage component. It's actually, there is V8 code already. And it's also being already used on some sites. We are on IRC on Pound Drupal-media. You can contact us directly and we will forward you. You can come help us on Friday's sprint or in Amsterdam. Or if you want to organize a sprint, let us know, we will see if somebody from the media team can help, can come and help onsite. Otherwise, we can join remotely. Just the most important thing is communicate with us. Let us know what's going on so we can cooperate and use our resources in the most efficient way. And yeah, I think it's time for Q&A. Yeah, we'll open up the Q&A and then if we have a little bit of time, I can just show a live demo of entity embed if anyone wants to see it. And please evaluate this session. If you go to like double headed session where both of our sessions are listed, pick the first one, which is about media file entity and evaluate it as a one session and then we will share results. Yeah, because the order of the sessions is not at all who won. So yeah, thanks. All right, first question. Is this working? Yep. First, I want to thank you too and the team in general and in the past and all these years that the media module has been in existence. I know it's been a rough road from the other side of the fence wanting to use the module internally. It's interesting to hear that story. So congratulations on getting through all that and moving forward. I'm very interested in the idea of using the whole entity embed aspect because like this gentleman here mentioned, blocks, we use field collections a ton. And with the idea of, we really need to be chunking data instead of blogging content rather, being able to define field collections and all that sorts of things, including images and YouTube videos and all that and being able to move it around the page within a body field is going to be extremely handy while still making it pretty simple to keep sites responsive or multi-display friendly. So I just wanted to echo that and wanted to understand, I know that you're moving forward with this on Drupal 8. Want to understand what possibilities are still out there for Drupal 7 to make use of some of these things you're doing for 8? Well, that's a great question. Thank you. The fallback formator is actually written for Drupal 7 right now, just because I know that best, but it will be ported to Drupal 8. So that could be used right now. I am thinking that possibly we'll be able to backport entity embed, maybe a more just lightweight solution that doesn't use the entity browser since that will be a much more manageable effort or a much more larger effort to backport. I don't see a reason why we can't backport entity embed. It's a matter of time. So yeah. Yes. Hi, Dave. I've got a question about one of the problems you highlighted, the idea that field formatters can't be used for things other than fields. One of the themes I've heard around Drupal 8 is encapsulating logic. So the idea that page controllers should do little more than make a call to something else, form submit functions should do little more than make an API call so that the logic within is not tied to this one implementation. I'm thinking of this problem of field formatters in a similar way, that field formatters probably shouldn't contain too much logic. So in the case of a file field formatter, that logic for displaying a file should probably be in its own encapsulated area with a field formatter saying little more than I want this file entity rendered in this way. Do you see the problem the same way? The problem isn't actually in the formatters themselves. Those are actually pretty good. Like, given the right information, I have this entity, I'm giving you it, and I am giving you this array of configuration which corresponds to the formatter settings. That's ideally what it should work with. And that should be the ideal way, but it requires type data listing of the entity to be passed in. And a fake field to be created of the proper field type. And it's mostly the underlying stuff, not the formatter itself. Yeah. Yeah, so I guess I see this problem as field formatters are maybe the only place where we can do that kind of configuration of display logic. So is there then a need to move that configuration of display logic a layer of abstraction out so that fields are just implementing that rather than making fake fields? I would hope so. I would love that, yeah. Okay. Yeah, thanks. Hey. Hi. Thanks again for the presentation, everything you all do. What's the relationship between the media team and Skald? That's kind of... So I've been in touch with Skald guys a lot because just because of the fact that one of the founders of the company that works on this module is based in the same country as I am. He's French, but he moved to Slovenia, so he's regularly participating in our meetups and stuff. And one thing that I've been really trying to achieve for D8 is like bring all these people together, and it always ended up just in a discussion about this storage component, which is kind of stupid, right? Because at the end of the day it doesn't really matter because we can probably achieve everything we want with either file entity or media entity. It's probably more emotional discussion than anything else. And so they are happy with this approach that we're taking. So basically media entity goes with the approach that they had in Skald for storage in D7. And they're helping on these other components. So I think this breakthrough in New York really helped us to come on the same boat. So, and I'm very enthusiastic about it. Yeah, we had one of the Skald maintainers in New York City and he's also working on the entity browser component. So it's kind of a really good benefit of the New York Sprint that I didn't see coming into it was getting all these parties involved and unified with the same effort because we're wasting a lot of resources. Like you said, kind of doing all the same thing but doing it differently, just very slightly. So yeah, we're glad to have them on board as long as they will allow it. So. Yeah, we will probably still end up having maybe 20% of redundant code, but this is much better than 100%, right? Yeah. Hi there. Right now I'm working on a very large installation of Drupal 7, thousands of sites running on one multi-site setup. And right now we're using media 1.0. And I've been very, I'm watching the media blockers for 2.0 for the last about year and a half. We have a ticket in to the let's upgrade to 2.x but we're gonna have that. I'm wondering what we're talking about today whether we branching off now to a 3x media with all these changes you're making or are we still focusing on finishing the 2x blockers? I wanna say that we're finishing the 2x blockers and maybe stopping there. Devin, would you kind of agree with that? Yeah, okay. Yeah, so the question is this kind of new stuff that we're talking about for Drupal 8 is it going to potentially be a 3x branch for media and no, probably not. I think by the time we would get ready to do that we should be spending it on Drupal 8 at that point, so. Are you going to be, as you mentioned that there's at least the anti-browser is right now an 8 project? Correct. Could be a lot of work to backport to 7 so that would never exist in the 7 version of media? Probably not. I mean, I can't predict the future. I don't think any of us will be doing it but I would encourage anyone who wanted to try to backport it would be more than free to do so because it is open source, so. And last thing is I'm just wondering if there are any plans with media to include any kind of Drush integration? What kind of Drush integration did you want? Well, one little thing, and I guess this probably could be done with some kind of PHP of Alkal but with what we're working on right now we actually have about 1,600 sites. About half of those are on Drupal 5 and we're trying to get them all the way to Drupal 7 using our own migration script. And one thing we have to do every time we upgrade a site into the media 1x branch is you have to manually go to the site and install the media types. I don't know of any kind of Drush call to actually say just figure that out for yourself and then just put it into the command line. Got it, yeah, I don't think there'd be something that would be managed by Drush. I could foresee a Drush command to import like existing files from the file system. So that could be worthwhile, yeah. All right, thank you. Yep, thank you. So with the new release cycle for Core, and I think Dries might have had the word media on there for like five seconds in like an 8.2. Well, I totally missed it if he did. Oh, maybe I'm wrong. Maybe it was a swishful thing. I was a little far away. But so with the difference between the file entity and the media entity, you really think that those like entity browser and entity, what was the other one, entity embed would be the things that would get into Core rather than those other two components for Contrib if that was the approach that eventually was taken? I think we could easily see that approach happening. There may be a larger discussion needed for what will get approved for Core. But yes, I could see the embedding and the browsing components being added in. Because if we go with this approach where it works for anything, they could use the browser component with just the native Core upload field. Or just a view of already uploaded files. So that should be possible. Cool, yes. All right, any other questions at all? You just all wanna see a demo. Where's the code sprint? It should be here at the conference center. I'm not exactly sure of the location. They said they have a big room for us. That's as much as I know. So I would check the website maybe closer to Friday. And we'll definitely tweet out a link from either my account or the Drupal Media Twitter account with the location. All right, one more question. I actually was just gonna give some more info on that. So the volunteers that are going to be available on Friday will help you get set up with an environment if you're new to that. So if you've set up D8 before, you can go right to the big room, find the table with these people, and that'll get you started. If you've never installed D8, find somebody with a gold shirt and they will help you triage to somewhere that you can get started and set up. Thanks. Cool, thank you. So I'll just kind of briefly show what's possible here. So, okay, I have a test note here with a picture of me snuggling my cat, Rodney. And we have a second node where we are embedding everything. So let's go and edit that because we can't really see what's going on yet. It's not related to me. I might need a rebuild here. Let's see. Let's fix live code. Yep, that's what happens. Oh, I switched to an old branch. It's fun writing plugins in Drupal Lake code when you don't do it very often. But it's funny because after, ever since we had the sprint in New York City, I've actually been really excited about working with the embedding stuff. And it's kind of been the thing that I've been kind of wanting to make sure we really get done right. I'm working with that summer code student. All right, now that we fixed that local issue, so we have text above the embedded entity. I have my embedded node rendered completely with comment form. And I have two smaller embeds. A file, which I have used the file link with a caption and just an image with an image style with a caption. So we'll see how that actually gets embedded here with the actual HTML. And we don't have it visible in the UI of CK Editor yet, but if we view source. So really all this is being powered by, I wanna make sure you can see this. It's just one div powering an entire embed. And all it has is a data entity type node, which says what entity type it is. I have data entity ID for node one. And this is an advanced example here, but if I did data view mode equals teaser. That would render the node with the teaser view mode. And that's all you need. You could also enter in a UUID for the unique ID for that node. Internally it finds node ID and uses the UUID itself. And by default it embeds using the UUID as well. I just use ID because it's easier for me. And if you wanted to add a caption, Drupal core provides this out of the box. If you just add a data caption attribute, it embeds a little caption where you can type in text. And so here we have our file link. So entity type file, data entity ID equals one. And this is the more advanced embedding syntax that uses the plugin type. So we're saying data entity embed display, it's the file entity display plugin which corresponds to file field formatters and use the file default formatter, which is the link to the file. And we can kind of see the same thing with the image. It's saying use the image plugin for an entity embed display and use the default image formatter. And then a second data entity embed settings, which is a JSON encoded string of settings saying image style use medium. So that's how we encompass the entity embedding. And this seems to be working extremely well. I should give a plug out for Jeff Eaton's session, battle for the body field at five today. He'll probably be talking tomorrow. Okay, because he will actually be referencing this as one of the solutions that he loves. So anything that makes Jeff Eaton happy, I'm usually okay with too. So yeah, that's how you embed an entity. There's no actual, we're working on the UI, do select and stuff, but we're mostly working on this underlying data attribute solution. And it seems to be working incredibly well. So any questions about that at all? All just amazed. All right, thank you.