 I see there's lots of people at the door. If you have an open seat next to you, please make sure to, yeah, raise your hand. We got a seat up here. We got a seat over there. We can get more people in here until we create the most epic fire hazard ever. Ooh, ooh. I don't have fire extinguishers. Oh, okay, all right. All right, yeah. We'll go ahead and get started here. This is the core conversation for the media in Drupal 8, not just media module, but the whole media ecosystem in Drupal 8 because it encompasses way more than that. So welcome and glad you're here. And we're gonna go through quite a bit and then at the end, we'll do a little bit of live demos because I love chancing it, but I've tested it really well. We'll see how that goes. And have a system QA at the end because this should be a core conversation in the end too. So I'd like to hear your feedback on what you think this plan is doing and what direction we think we're headed in. I'd love to hear feedback and anything you have to ask. And we can definitely pause at points too, it's not a full presentation. But a little bit about us. My name is Yanis. I'm SlashRSMDrupal.org. I'm working for Examiner.com, which is a media company. We're running Media Portal. And before that, I was working in another media company, our national media company. And so I'm kind of stuck with media problems. I'm also maintaining plot-load integration module, discuss module. I was summer of code student. I was also a mentor now two times. And yeah, that's mostly, I started my first Drupal moment was when my friend called me and said, would you build me a website for a tennis tournament? And I said, yes, of course, why not? And I've never did it before. And when he agreed, I started to look for something that I could use for that. I found Drupal. And my name is Dave Reed. We have a height difference here between us. That's kind of fun. So I'm typically known as the module guy. That's kind of my reputation in the community. I think at one point the count is up to 120 plus modules or something like that. So I have a lot of experience doing this and not maintaining some modules. But about three years ago, I got involved with the media module and the whole ecosystem around it. Really got attached to it. Because it was like one of these problems that like there's a really hard problem and don't feel like we're doing very well at it. And I feel like it could really help and contribute to this. And I was really fortunate that my previous employer, Palantir.net was totally agreed and wanted to help out too. And we had a really big push and a big sprint in Chicago and really helped move the 2x version of the module forward and stuff. But we still have a ways to go. And if we're gonna share fun Drupal moments too, my first core patch was some patch to fix Drupal HTTP headers on Dreamhost which then Drees commented like the day afterwards which I look back in that to have Drees comment on the patch within 24 hours is kind of awesome. But that doesn't happen anymore. And of course it got won't fixed because Dreamhost is not great as a host. So anyway, why is media important? I mean, these are kind of fairly obvious things because people expect that we do it right. It's kind of one of those things that it's like, well, is it right or is it need some work? And if it's right, it's like, okay, cool, Drupal. And if it's not, it's in the latter category, it may not, Drupal may not be evaluated after that. And kind of kind of go along with that. The competition handles it better than us. WordPress does great things out of the box with media. I would call it simple, but it does it well. And other systems do it pretty well too. We have lots of these media companies and enterprise clients that have advanced use cases and want to be using Drupal and have to integrate their media management. So we need to be the solution for that. And funnily enough, people like posting pictures and catgifts and they like using media and YouTube files and putting them on their blogs. So it's kind of a use things that everyone wants to do. So, yeah, we have to get it right. And especially for the editors and stuff, we want to make sure they have a good experience too. It's not just the end users and the end result of seeing the media, it's the result of being able to edit and add that media too. We have to make sure we're doing a good job of that. And just all around handle it well, yep. And of course, I think it's funny because every TripleCon keynote that Dries usually does didn't happen this time. But if you could have one thing done in Drupal, if you could snap your fingers what it could be. And in Portland, of course, it would be media handling. And it seems to always be the answer. But we always seem to not be making progress. So we've got to make a good effort here. So let's talk a little bit about Drupal 8 and the current status of core only. There have been some improvements to that that have been pretty good. There's a file listing now in Drupal Core, the box. You can't really do much with it, but it just lists files. It's better than nothing. And you can see where it's in use, that's kind of handy too. You can actually, with our official WYSIWYG editor, CK Editor support, you can actually embed images using the Drupal way. They're saved as files locally as Drupal and not just remote files or something else. You can provide alternate text and align it and caption it really nicely with H205 goodness. And that's out of the box. But you can't figure out how to... I think you can select an image style, but that's about it. You can't do anything else to it. Make it a picture element or that kind of thing. And we did add, if you had an upload field, you can actually upload multiple files just using drag and drop. Little thing, but it's nice and little handy there. And to kind of recap some of the problems that we're facing with the actual modules and implementation from the media module standpoint, which I'm well versed in and will be the first person to say, don't use the module, it has some issues. I'll be honest, we don't have a stable release for the 2.x version. That's a big thing that we're encountering right now. And a big reason for that is the WYSIWYG handling. We're doing some weird, complex stuff with the WYSIWYG stuff and being able to override fields on a file with the WYSIWYG dialogue and it's causing all sorts of issues and encoding and all sorts of goodness. And so we're almost reaching a point where we have to figure out how to cut our losses with Drupal 7 and what to do, how to move forward to get that to a release. Some people would say it's overly complex out of the box. I like to say as a typical developer, it's flexible and powerful. But it's typically, people don't understand how to configure it. It's not intuitive in a Drupal fashion. We fight a lot of battles with core assumptions because core doesn't think you can reuse files ever. So we fight a lot of assumptions with that with media. And of course it's like normal issues too, like maintainership. We're all volunteers. We're not technically paid to work solely on this. I work around it on my side, on the side and off job or if something happens for a client with media module, I can go and work on it then. But for most of us, we're not paid to do this 100% of our time. And then we also had some interesting modules come up like Skalds. They did a wonderful job of what they wanted to do but it also means that we're competing for resources then. And we're competing with ideas and not really sharing and collaborating as best as we could. So let's see. So we're starting to like try and figure out to get together and we had this discussion that was a result of DrupalCon Prague, I think it was. And was posted to our Drupal group what they thought we should move forward with and a lot of us disagreed and it just ended up like a boxing match in a typical comment thread with no result. Which was, yeah, and just not a good result from that, so. But thankfully we did have an opportunity to sprint together in New York City early this year. It was really great that they got us all to come out and got us to sit in the same room which is really important when you have disagreements that we kind of all got together and said, okay, maybe it's okay to disagree on stuff and let's try and maybe figure out what's the common functionality that we have? What are the common components we can work on together? What's at least build a base of this ecosystem that we can both build on top of but collaborate together with? So yeah, that was really nice and this is kind of showing this plan that we developed there. Are you taking over? It's so hard. Okay, all right, I'll keep going. All right, I'll just keep going. So it ended up that this new, so file entity is like the typical, the most popular way that we stored and interact with files in Drupal 7. It basically extends Drupal Core's native file entity and makes a UI around it, lets you interact with them. Independent of content and other entities. And there's the proposal from Prague to make a separate thing called a media entity that could point to a file or could point to a YouTube video that wasn't necessarily a file or a tweet or that kind of thing. Whereas the file onto the approach is tries to treat everything as a file. I like to think of it as you uploaded a video to YouTube so it exists as a file somewhere. And so we disagree in this kind of storage area and we're probably gonna keep working on that separately. So there's a media entity module now that's being worked on for Drupal 8 and there's a file entity module that we're working on porting but at the very basic stages right now. But given that, we can start to break other things up and stuff that we can share. And if we can make this ecosystem work for both of our different storage components, file entity and media entity, it means that we're doing a good job and that's actually a good measure of success for us. You could use this base components to do other stuff whether you don't wanna use media entity or file entity. They could be used independently. And so we're gonna show you the approach that we have and we also came up with a roadmap here for what we're gonna do. Yeah, so we've split our roadmap in few steps. First step is basic APIs that we need, basic API for embedding stuff into WYSIWYG, basic API for module that we call entity browser that is basically responsible for finding and selecting media items, storage components because it's the lowest layer of the system. And yeah, so we have some things that are already done. Most of work that we've invested was in WYSIWYG integration. That's mostly because of the fact that the WYSIWYG integration module that we currently call entity embed was a summer of code project this year. We got a great student called Chandan, his CS underscore shadow on triple.org and IRC. He was very enthusiastic, very productive and as he was later, we achieved a lot in that part. The next step is to start using this API to provide user experience UIs. And here again, because of the summer of code, we already have integration with CK editor. This works basically, it's almost feature complete. We are still struggling on some other parts where we're mostly dependent on volunteer work. And when we have this basic systems in place with APIs and UIs on top, we will focus on display configuration integration with third-party uploaders, like things that are important but are not operating in the basis of the system. And at the end, we have third-party integrations and things like cropping derivatives. It's most of these things I must have, but we need everything below in order to work on this. So let's see which components we're working on. A bit more in depth. First module is entity browser. As I already mentioned, it is a tool for listing, finding, creating and then selecting entities. If you're familiar with, let's say, media widgets in Drupal 7, where you have this pop-up that opens and then you have tabs where you can select media items or search YouTube or upload things, it's similar, it's based on the same idea. The main difference is that it's designed to be a general tool for selecting entities. It should allow you to use it even with entities that are not media related. Let's say you have an entity reference field and you want to add few related articles, you should be able to use entity browser to do that. Entity browser would then open, give you a view with exposed filters where you could search and then select few articles and those would be then referenced from this main article. There is nothing preventing us to implement things like search API in this thing, so the way we're trying to design it, it's very powerful and very pluggable. I'd like to speak on that too. The concept of the media browser has different tabs, like one might be a library, one might be an upload, a new file, one might be a paste in the URL to a remote file or YouTube video. The idea is that those individual tabs should also be field widgets that you can then use on individual fields. If you wanted to just use the library part on a field, you could just use the library part and that way any kind of widget that you have available for your file and image fields could then be something you can put in a media browser as a tab, so we have a widget already for uploading a new file, why not just use that for our upload tab? So that's an interesting, kind of pluggable, reusable concept for that. Few more potential use cases for that. Let's say we want to upload few images, select few other images that are already in the system and then create a gallery out of this entire set. Entity browsers should be able to allow you to do that, basically in one step. Then it should allow you to search YouTube for videos and embed it into Wizz a week, let's say. It should also allow you to have a standalone page where you select 50 articles and when you submit, those are sent to some third-party site via an API or something like that, you name it. Our intent is and our hope is that we'll do it in a way that will allow you to really use it for any situation where you have to deal with searching and selecting entities for any context. We are currently working on some basic APIs. We don't have any UIs or any demo, we just have some mocks. It's similar to what we have in D7, except we wanted to do it much more pluggable. Let's say you should be able to change these tabs on top with something else. If you don't like tabs, maybe you want to use a dropdown to switch between your so-called widgets. Widgets are these tabs where then you can, widget can be a view or an upload form or name it. Also to support use cases like the one that I mentioned before where you first upload a few images and then select three other images in the same step, we should support something like this where you can go to one widget and let's say upload things. And then these items appear below and the list of currently selected entities. And then you can go to next widget and select few other images, let's say. And they also appear down there. And when you're done with this, you can use this currently selected list to be propagated down to entity reference or anything similar to that. We have an issue and our issue queue where we're discussing architecture. This is the basic idea. We have kind of like four areas where we have pluggable interfaces. One area is widget. Widget is the actual form where you either select or upload or create or do whatever to get those entities. Then we have a widget selector plugin which decides how you will choose which widget to use. And selection display is this part below that I showed how the list of currently selected entities is displayed. And of course, browser can be used like in an overlay which is how you get this in D7 but we also want to support other forms. We don't want to assume how entity browser looks. We just want to give you the tool and then you decide how it looks. Then we have media entity as Dave mentioned is one of the two storage components. It takes the approach of not everything is a file. Media can be a local file, but it's not necessarily. Creates a new entity type which then we use to store the information about media. And it uses the standard field API fields to do the actual storage. Let's say if we have a local file, we have a file field on it. If we have a YouTube video, you can have a link field which then stores the link to a YouTube video or a text area field where you paste the embed code, things like that. And as a result of that, not everything is stored in the file management table, just things that are uploaded in the actual file field bar. And then it comes with so media type plugins that those plugins basically provide business logic validation metadata for each media type. Media type being either local image, YouTube video, Vimeo video, et cetera. Validation part exposes a validation callback that then we use in a form to validate data that was entered, but it's not tied only to forms. You can use it in your custom code if you want to do something with it. Plugin also gives you a list of so-called fields, but those are not the entity fields, are fields that this plugin knows how to provide to you either by stripping some data out of embed code or URL or connecting to an API and fetching tags, description, whatever. Then you can also configure mapping between the fields that are provided by media type to the actual entity fields. And when you save the media entity, it will fetch these fields and save it in the actual entity, but you don't need to do that. Maybe you can just access these fields via an API to use it just at render time if you don't actually have to store it. Here's how it works. I created a so-called media bundle with a new URL field and video ID field, and I attached a YouTube plugin to it. If you want to play with this, you can find both media entity and YouTube plugin on our GitHub group. And then I tried to enter Drupal.org as a link to YouTube video, and validation callback recognizes this as a wrong URL and complains. And when I entered correct YouTube URL, it saves because it detects that everything is all right. And since I defined mapping between the YouTube video ID and this text field that I have on my entity, it already auto-populated it. So now I have both ID and URL here, but I could have description that would be fetched from YouTube or title or text or everything that they provide for us. So kind of looking back with the entity browser, I think it's just kind of indicative of our goals that like how many different kind of browsing like view interfaces are there for Drupal 7 that kind of do the same thing and we're trying to replace them all. Yeah, we're keeping our goals low. And along with keeping our goals low is entity embed because there's how many modules for embedding stuff in body fields in Drupal 7? There's a lot and we wanted to do it right. So again, to reiterate, we had a great, great summer code student, Shanban who worked on this all summer and did the majority of the work and was super terrific. So we have the entity embed module for embedding any type of entity in any kind of filtered WYSIWYG text field. You can configure any number of buttons. So like you can pick a button for embedding node. You can pick a button for embedding files. You can have a button for embedding users. All different buttons, but one per entity type. But it works for all entity types out of the box which is really nice. And another interesting thing that we'll see in the live demo is we're kind of continuing on this theme of reusing and reusability that the way that we display the embedded item by default, you get to pick from an entity reference field formatter or if you've picked a file or an image, you can pick a file or image field formatter as a way to display your embedded item. And you can also write a custom version to display it if you want to, but it's like encouraging people to write field formatters as a way to display things. So we wanted to reuse those. And the tiny Jeff Eaton and myself would be really, really happy that the way that this stores in the actual body field is one HTML tag that stores all the attributes in like data attributes in a nice HTML5 way. So yay, it's terrific, we got to see it. And an awesome thing is that it supports UIDs on the box. So if you pick node one to be embedded in your body field, underneath the hood it'll automatically put in the UUID of that node since all entities in Triple 8 have UUIDs and it'll put that in there and it'll always use that to load that node that's embedded in your body field. So if you do a deployment, it won't break, which is really nice. And then like after we did all this work with the entity embed module, we kind of realized that there's a lot of similarities, like the concept of embedding things in the WYSIWYG, like configuring the buttons and a selection kind of UI and then picking how to display it kind of shares this common functionality. So things like picking a URL, like a YouTube video, if you just want to put a YouTube video in your WYSIWYG, like it kind of has the same thing. You type in the link to the YouTube file and then you have a display, what size do you want to output it as? So we're kind of making this whole embed framework or API now based on entity embed and that'll work for entities, URLs, short codes which is like a WordPress kind of macro kind of thing that we want to support and also like the fields from the same entity that you are using. So if you're on node one, I want to say put my tag field in the body here and display it like this. So we want to make sure that's possible. Our second of two storage mechanisms, file entity. Has anyone used file entity before in 777? Yeah, that's a good amount. So we're planning to keep it pretty similar but a little bit more split up. So the good portion of file entity that's basically like, hey, let's expose the UI for files and let you add and edit and delete them without having to interact with your node as independent actual good entities. We're gonna be porting that as interpolate. But the stuff that like makes you add fields to files or at different file types like audio files or video files and those types can have different fields, we might be splitting that off into a separate thing. So like, if people just want a UI for interacting with their files, they could have that. Without having to overcomplexify it with adding, oh, I've got fields on my files now, I don't know what to do with those, what should I be doing with those? And I've got all of a sudden these six different file types and I don't know what I'm really doing with those. So we wanna make that a little bit optional. Another fun part of file entity that we're spinning off, has anyone seen like the manage file display tab? Yeah, it's a pretty painful process. You have to like configure the different types of ways the file could be displayed and then configure the order in which to try them. And if the first one works, great, it'll return that. And if not, don't try the second one and I'm not gonna try the third one. So yeah, and it's just super weird. But it has a valid use case, which is like, say you have a file field in Drupal Core that you have uploaded both audio and video files to cause you maybe didn't separate them into different fields, whatever. But you wanna display the video as video, each null file video, but the audio as audio tags. You'd have to write a custom formatter to do that logic for you. Whereas if you just had a formatter that output, oh, it looks like this file is a video, I will output it as a video tag. And if not, output nothing. And if they're saying for an image or an audio, you could use this new fallback formatter module to do this. Just write in your field, manage fields as available independently. So we kind of abstracted that out as well. So we're excited about kind of not having that as custom. So another fun thing that we encountered, actually encountered on a client project, but I wanted to kind of bring into our ecosystem. If you have a file field in Drupal Core, it means you can't use any of your image formatters on that field. Like if you wanted to display it as an image style, you can't. Cause it's a file field, not an image field. But if you install this module, now you can. So it kind of works with that fallback formatter behavior too, so yeah. And then another quick module too is the field formatter. So like untangle all the instances of me saying field formatters and all that together. So if you have an entity reference field, and this will allow you to output a specific field from that referenced entity, just one field. So it kind of solves our entity embed. I want to display the field from node two in my body, but not the whole node two. So it's just that. And then kind of like the big question is what happens to the media module or the scald module in Drupal 8. I can't speak specifically to scald, but at least from media, what we're looking to do with all these components then, we'll have configuration entities, we'll have a pre-configured media browser with our library and upload tabs and kind of have just the glue code that's necessary to bring it all together. It'll have more dependencies, but I think that'll be okay. That's kind of what we're encouraging in Drupal 8 now. So yeah, any questions so far? Yes, go ahead. Mike's right there, be careful of the people on the floor. Yeah, I was wondering about the explanation you gave about the different, I think it was in the media entity part of the presentation, so I'm not sure how the file entity storage solution would handle that too, but you had different bundles for the media entity type, who had created a YouTube bundle. What would make it similar or not similar to a daily motion or an other video provider entity? Would that be a different bundle? If so, can you say that there are videos? What do they have in common? Yeah, so it would probably be the different bundle unless you write media type plug-in that handles both. And then this distinction, to bring all these video types together as videos, we would use taxonomy, because when we were thinking about it, it makes more sense. It's easier. It's like what the current D7 solutions like kind of vary with like. So current D7 mostly? And provider for the same media type or like our different providers, just separate media types. So in D7 there is no media entity, so this is kind of a new approach that we're trying, but like mostly when most of solutions in D7, when they display media in a listing, let's say, the most top level filter that they use is based on bundle. And with media entity, now we were thinking about using it as a taxonomy just because of this problem, because we were thinking how to make, let's say Daily Motion and YouTube, the same bundle called video. And then we realized that we would probably end up with a set of fields that are used for one type and not used for the other. And we would have to either hide those fields when you know that you have YouTube video or just have a huge messy form. And then we were thinking how to overcome that and like Sasha said when I was discussing this with him that we're probably trying to implement bundles on top of bundles, which is probably not the best idea. So like planning is to use taxonomy for along with bundles to bring this together. Yes, in the back of the room. Microphone. I can repeat it if you want to stay back there. Yeah, that's good. So the question is with field embedding, once I've saved and I'm displaying the node, can I then inline edit that field? Yeah, yeah, you can definitely configure how it's displayed, yeah. You can, yeah, so the question is, can you change it after you've embedded it? Yes, you can. I will show you in the demo. So I'll quickly hit through some challenges that our team is currently facing in Drupal 8 to kind of bring some attention. If you're gonna be at CodeSprints maybe Friday, these are kind of some things that we are looking to figure out as contrib module initiative that we need solved. The big first one is, how do we manage external dependencies right now? Cause core is taking the shortcut and made its composer.json file and put it right in the root and downloaded all the dependencies in Drupal. Can contrib modules do the same thing? I know there's the composer manager module, but kind of what's the official recommendation for how contrib manages their own external dependencies? We don't really know. There's some really fun, challenging issues that have to deal with formatters and widgets. Always assume that there's like a parent entity and like I can't work with them as independent objects cause I would just like to say, hey, formatter class, I've got you this configuration and this item, please display it. And it ends up being way more complex than that. So if you have any knowledge, I know there's some certain people in this room that might, we love your help with this or better solutions, but we have something that works right now. We wanna make sure that files everywhere in Drupal use the proper access control. There's just the private file access system in Drupal 7 and then there's the file entity access API also in Drupal 7 if you have the module and they don't always talk to each other or work and like we can't get core to respect the file access API. It only listens to the private file access. So we wanna make sure that in Drupal 8 at least it's consistently using one access API that could be overridden if needed. So we're working on that, we're making progress. There's some fun challenges of type data. There's an issue out there right now that if you have a space in your file name it fails validation for the file entity. So we're trying to work on that one too. I would like to report a success that we had. If you know in Drupal 7, if you added a image to your node on a field, saved it and then went back and removed it and maybe changed it to something else. If that file was not used anywhere else, Drupal would automatically delete it for you. Which kind of screws up with the concept of reusable files and goes back to that fighting that core assumption. So now it's actually configurable in Drupal 8 that window of when that file expires if it's unused. So you could make it two months or something like that which is a little bit more safer or you could disable it but that could also run into some disk issues if you don't have a lot of disk space. But we also have an interesting problem now that the file temporary status is referred to two things. It's like you've uploaded a file but haven't saved it to a node yet. And it also means the file was used at one point but now it's orphaned. It's considered temporary again. And it's kind of a confusing thing where we're having a discussion about it on Monday. So maybe we'll talk more about that on Friday. You wanna go with demo and then we can... Sure, yeah. Yeah, we'll switch over the demo because it's the most interesting part. So let's see. So I have my Drupal 8 site. From a get pull recently this morning that I have confirmed that I should work now but I have not dared to try and pull it again. And I've enabled the entity embed module. So we're gonna show you right now because I'm just really proud of this work that the team did. So once I've enabled the module I go to my input text format configuration, my text and editors. And I'm in the full HTML. And I can see down below I have a filter for display embedded entities. I need to enable that. And then I have already drag and dropped some entity embed buttons. They're like the nice E there for entity. I have dragged them into the configuration. So that's all I really need to do to embed entities in my WYSIWYG. I can show you this interface quick. This is where you actually add another embed button. So I have made two. One actually ships with the module by default for embedding nodes but I made one for files too. So I could go through and I could actually add a new embed button. I could pick which entity type it should correspond to. I can actually change the button image as well from right here. Otherwise it uses the default E. And these are config entities, yep. Yeah. And then this is the part that I was looking at. I was like, oh, this should be just a generic CK editor button, like config entity, for our embed API. So this isn't really specific to an entity embed. But all right, here we'll get to the fun part. So I have, let's see, two items of content here. I've got a first node with a picture of my lovely cat Rodney. And a second node with some placeholders here. So let's go ahead and edit this. And I'm gonna go ahead and click here and I'm gonna hit my first entity embed which is lovely size content. So I'm going to embed some content. This part here of selection is kind of very basic because once entity browser is finished, we're going to integrate this into the first part here. But for now we needed some kind of fallback behavior that just allows things to work. So right now I just typed the ID or UID of the node I want to embed. We may change this up to like autocomplete untitled. That might be easier, but I'll pick item one. And I see that I've got the title of what I want to embed. And I have a number of options here. And this is kind of what I was talking about with field formatters. So these author, label entity ID and rendered entity, those are all entity reference field formatters. And I have some other field formatters that are for entity reference fields or our fallback module too is available. But by default, we want a rendered entity when we want to render it with a view mode and I can pick a view mode teaser and embed. Ta-da. And I can even right-click it and I can edit. Maybe I want to change it to my default view mode again. Ta-da. Yeah, that's cool. Question, yes. Yes, all the plugin, these options for display, these are actually plugins. So they're kind of a wrapper around the field formatters and there's an access method that says, oh, is this item an entity that can be rendered? If so, return true. Or like, you could have your own custom logic in this access method that says, oh, does the node have this field out? Okay, yes, it can be displayed with this plugin. Yeah, that's the confusing part. I mean, we're at least, we're literally reusing the same formatter labels that you use when you pick how to render a field. So it's, we kind of have the same problem as core. Like, how do you explain what field formatter to use on an empty reference field? So yeah, I kind of recognize that it's kind of confusing, but we're also just, we're at least have the same problem as core. So if core fixes this, we can fix it here too. So something else show, let's see, what show label and my options that are available as my formatter are right there that I want to use. I can change it and it's there and it works. I'll show the source for this because I think this is the coolest part. So this is using a custom HTML tag called Drupal-Entity. And we've stored like what button I use to embed it with. I've got my data attribute for what display plugin I'm using. So it's the entity reference field and the entity reference label field formatter. I've got my settings that I had that are JSON encoded into that data attribute. So I said, I want display this as a link, so that's my JSON there. I've got my entity ID of one, entity label, I'm not sure why we have that, but entity type and I've got my unique ID as well directly there. And then, so then what this happens is when this is rendered through the filter, this is converted to just a normal div and it displays the entity as it needs to. Yes, this is implemented as a CK Editor widget. Yeah, we've had a lot of assistance from Wim Lears who's been doing a lot of good work in D8 with the CK Editor stuff. So he's definitely been our consultant for how to do stuff. Another thing I'll just quickly show, one of the common problems we get in the media module is I want to embed a link to my uploaded PDF file. It seems like such a simple use case and something we could easily do, but it's a hard problem for us to do in media well. But I'd like to report that's no longer the case. I'm going to embed a file. It's an image actually, but it's okay for demonstration purposes. And again, I see which entity I've selected that's not exactly too helpful and I have a list of entity reference field formatters, file field formatters, and image field formatters to pick from. It's kind of a lot of options and fall back appears here twice, I don't understand. But if I just picked a generic file, which is a file field formatter, I can type in the description and it outputs as a link to that file using that field formatter with a link to that file. And I could edit it again and since this is an image, we'll do an image formatter. And so I can pick the image style. I can even provide my alternate and title text right here, which is also serialized into the attribute and embed and if I view my source for this, I can see it just encoded as a regular alt attribute and a regular title attribute in this element directly and that just gets passed through when it's rendered as an image. So it just works, which is really, really nice. So yeah, yes. I get it asked every time, every time. I can rely on that question. Can it be backported to Drupal 7? So I would like to say it could be. None of us have really investigated too much into it. I think I have had some people report back. I mean the filter itself, totally easy to backport. That's fairly easy to do. The harder part is the interaction with the CQ Editor and the whole JavaScript interaction because there's not really a library to do all these forms and stuff in Drupal 7 in a good way with CQ Editor. So I'm open to being backported. I would love if anyone has the challenge and wants to take that on. We have an open issue in the queue for this. But I don't think it's like something that we're gonna be spending time on as our volunteer basis. So it's possible, it's theoretical. I'll leave it at that. So, yes. Oh, it's right behind you, yeah. So I think in Drupal 7, if we want to do the same thing, we had a scan model, we can do less or more the same thing, we can embed media or files or any type of entity into the body view and it's had a plugin to work with CQ Editor. But the implementation, the implementation is a lot, it's less clean than in Drupal 8 because of many limitations in Drupal 7 but we can have less or more the same functionality if we want to do this in Drupal 7. So I'll point out that I believe that Scald doesn't actually use a text filter to render the items which is what we're using in this module and it's thanks to the Drupal 8 improvements that we're doing a very, very late rendering of these actual entities. So like, even if the process text is cached, the actual rendering happens even after that. It actually happens after the text is retrieved from cache. So things like making sure that the user can access this node that's rendered is checked, very, very late and always checked and not cached. So I think that maybe one of the things that's hard to backport is the filter system. In Drupal 7 has a lot of, you can't late render many things that might be one of the hard challenges to do so. But this works anywhere that filter text is used not just in the field, like it could be anything that uses check markup. But it works on a field and not text format is the key. So it has to be a field value where it's used. So it is a technical implementation of how Scald actually uses some kind of token with an HTML comment. And then in the field formatter view kind of process replaces that. So it's like an alternative to the text format system kind of to get around some of the limitations of the Drupal 7 text format system. So, yes, in the back. I think it does, but we can check how the preview fetches in respect to additional attached CSS and JS, yeah. Okay, so I'll make sure that some things may need to operate differently with the preview mode in the WYSIWYG versus the actual rendering, we'll note that, thank you. Let's get through just the last little bit and then if we have more time for questions, we'll take them, okay? Yeah, so you're probably asking yourself, how can I help? Because we need your help. Currently, we are pretty confident that we have good plan that can really move the whole media ecosystem forward. And the biggest blocker right now is that we're all volunteers and we have very limited time that we can spend on this. And it's like the fact that the project that was Summer of Code project and we had a really smart and productive student for the whole summer dedicated only to embedding solution. And now embedding solution, it's way forward from everything else, basically. That proves that if we have people that are dedicated to this, we can achieve a lot. So without your help, any way of help like this won't magically happen. We need people from all different expertise. Currently, we're mostly working on backend development because it's the nature of the basic APIs. But sooner or later, probably sooner, we will need a lot of front-end work to be done, user experience design. We're also probably looking for a project management because we like to develop and we don't want to deal with that. We need your ideas, we need your past experience. We are collecting user stories for media on drupalmedia.org, am I correct? Yeah, so if you have something that you noticed during one of your projects, that was a huge problem and then you had to hack around it, go to drupalmedia.org and let us know. We have both right in the next slot. We have weekly scrum meetings on IRC. It's every Tuesday, 3.30 p.m. GMT. It might be one hour before or after depending on time zones because it's messy. But I think it's correct. Our development is done on GitHub in a group called drupalmedia. We automatically sync all our repos to drupal.org. So you can also find all the code there. We are using issues on drupal.org and we are linking pull requests to issues so to give you visibility that you need to help us. We're using hackpads for our notes and brainstormings and everything that needs to be written down. We have a group on GDO. You can contact us directly if you're more comfortable this way. Of course, we have a sprint on Friday. Come and help us. We will be on bed camp and you can organize a sprint if you want, let us know. If you have a developer that wants to dedicate a part of his, it's time. Let us know if you want to fund us. We would appreciate it because only this way it would happen. It will happen. And that's it and we have zero minutes for questions. I think we're pretty much at times. I think we'll call it. If you want to come check us out after this session or the buff right after this too. Thank you. Just digital. Just digital launch. Is this a launch or a launch?