 I think we'll go ahead and call it good. You guys have been very patient and waiting. Thank you very much. Anyone still coming in from coffee can just miss the intro. OK. So this, how was the keynote? Good? Yeah. So yay, I'm excited to see you all here. It's TripleCon LA. This is my, I don't know how many TripleCons I've been to, but I've been to every US conference since DC. That was my first one where I got a scholarship to go to. And I've been to everyone since then. So I'm just really excited to be here and see all my friends again. And several of them are in the room because they're nice and support me. But this is the Triple8 media status update. I'm not here to talk about my friends. So it's just going to give you an overview of what we've been working on for Triple8 and the media ecosystem. What things we've gotten done. Kind of show you some progress. What we have left to do. And so kind of some of the challenges. And this is a core conversation. So they'll be, I'll try and leave some points throughout the conversation, throughout the session, that if you want to interject with some questions, that's totally fine. This should be more of a back and forth, even though it's more of like a status update. So feel free to jump into the question. I'll repeat it. Or if you want to go ahead and come to the mic in the middle there. If you want to reference this later, there's a link. I'll paste this in to the session page. But it's a www.druple-media.github.io slash d8 status update, all with dashes. You can also tweet at me, at Dave Reed. I do not have any notifications running right now. So you will not see it on the screen. But I will reply to it later, I promise. See if you have any questions, like afterwards, that you think of, or I want to say hi. Tweet me. I'll also be at the Lullabot booth. Pretty much the rest of the week. So if you want to stop by and say hi. So let's go ahead and dive in a little bit. A little bit about me. I'm Dave. I've been around in Drupal for nine to 10 years now, which makes me feel really old. But I like it a lot. I'm typically known as the module guy. I have that reputation. I don't know if it's a good reputation or a bad reputation. But I think the count of modules that I've maintained has definitely been over 100 recently. That's not actively maintained. It's just written. I'm not actively working at all 100 at a time. But I've definitely gotten involved in more of the media stuff recently in the last couple of three, four years. Ever since I was working for Palantir.net, we made a big push to improve media handling. That's where the 2.x branch of the media module kind of started. And we really pushed forward. We had a big sprint that we had a week with Aaron Windborn there, who's no longer with us. And I had some Palantir devs and some Acquia devs. And we made a big push. So I was really fortunate to get into that and kind of dive into that and be fuel responsible a little bit for it. And it's kind of evolved since then. Right now I work for Lullabot, as I kind of mentioned, with The Booth. We're a full-service Drupal design development strategy firm, and we're kind of proud because we got named the number one web development agency by Clutch. I don't think that matters a whole lot. It's nice to say that we're number one. But we like hanging out, so come down to The Booth if you want. And as a moment of personal pride, this is my five-week-old that I left at home. Linus, who also shares my great looks at looking at code. This is pretty much how I look during the day, like when I see stuff, like, what is that? Where did that come from? Who wrote that? It's just great. He's picked that up already. And if my wife is going to listen to the recording afterwards, I'm sorry. You'll get all the sleep this weekend, I promise, because she's at home with two kids now. They're blessed. And the four-kitten shirt, of course. And of course, this just isn't about me. We have this as a whole team of the media people. And it's not just these five people as well, although we kind of consider these five to be somewhat of the core team that were kind of pretty active and always involved. And we have lots of more contributors. We're trying to get more new contributors. And we've got Google Summer of Code students coming in. We actually have three projects with Google Summer of Code that are involving media this year. And we'll detail those a bit. So it's just really great. It's not just one person. We're trying to make this team this kind of initiative kind of thing, even though it's unofficial. So yeah. So let's just kind of hit the overview of the plan. We came up with this plan at New York City Camp. We got the media maintainers and the scald maintainers together in a room in the same place and kind of locked the doors in a boardroom. And we wanted to figure out, we're both kind of doing this media thing, but we're both kind of competing and doing different things that are kind of the same. How about figure out, where's our common, where do we interact? What common functionality do we have? What can we work on together as we look forward to Drupal 8? So that maybe we can share some stuff. And we got the big whiteboard and diagrammed it out. And we kind of realized there are some things that we shouldn't share and work on together. And so we came up with this plan to move forward from that, that we want to have these more independent components. So if you use the media module in Drupal 7, it's kind of like this big module. There's file entity, but media module like does all this stuff. It does the WYSIWYG handling. It does the browser component. It's just this monolithic component that just is hard to support and ends up being, it kind of shows the struggles that we've had in Drupal 7 supporting that. So we wanted to kind of break things up into smaller chunks. And that way we could reuse them. Like someone could come along and use the browsing component or the embedding component. And we also want to make sure that these were pluggable. So like they didn't just work for media stuff, but they could work for any entity in Drupal, which I think is a very important point and helps keep us abstract enough and keeps us on that goal. Like if we don't think of everything in files or media, I think we're on a good track with that. But I mean, that's where we're coming from too. So the components that we decided on, I kind of touched them a little bit. So there's embedding. So there's, I want to take this file and put it into my body field. That's one major responsibility. So that's embedding and WYSIWYG. It's not necessarily WYSIWYG. It could just be like an HTML tag that you could use. Because I know that with decoupled architectures, WYSIWYG may have a less important role too. So we want to make sure that we're still supporting that. Browsing and selection of items is another big component. And then storage. Like how do you actually, what's the lower level? Like what are you dealing with? Are you dealing with files? Are you dealing with something more abstract? So there's some other smaller things, but these are the three main components that we really like to focus on. And this is like, if you think of this in media and file entity terms, media was the first two, and file entity was the last one, the storage. So we're kind of breaking it up into three-year parts instead of two, if we look at it that way. And of course, the goals that we have from this plan, a lot more collaboration. We want to keep talking with all these people that are interested in media, the scald maintainers, the media maintainers, people that work with files entities. We want everyone collaborating together and working on these shared components. Because it's nice, because we're already struggling for resources. It would be great if we're all working together on that stuff, rather than trying to compete. It gives us more momentum. We communicate a lot more. We communicate in public a lot more with our plans and that kind of stuff. We give these kind of presentations, rather than them maybe being sequestered secret road maps that aren't shared or public. We want to make sure that this gets out a lot more, because that way we can bring more people in. And more people can see what we're doing and say, hey, that's cool. I could build something off of that. So that's really important to us. So the first big part of this is we're gonna go into embedding. And this is the entity embed module. And this is my favorite part. I'm really, really proud of the work that's been done by the team on this. And I'm happy to say that this is usable right now in Drupal 8. And I know of several sites using this module and production on Drupal 8. Those crazy people are, but they're doing it. And this is definitely pretty ready to go. So the module's pretty much 90% there. We've even back ported it to Drupal 7. Devin Carlson back ported that to Drupal 7. So if you're interested in using this as like an alternative to media, WYSIWYG handling, you could try this out. And we've also improved some usability of the display configuration. I'll show that with some screenshots. We do have some remaining tasks. So the selection of what to embed right now is just a simple autocomplete field, which we'll see. And we want to integrate with that with our other component entity browser, which is still being worked on. And we've also discovered that there's like the button, creating a button to embed nodes and creating a button to embed files. There's also these like concepts of embedding and how to display them that we can share on among other things that we kind of want to abstract. So we're going to make that another module called embed API. And we just want to polish the usability of that stuff too. And I can't really go much further than mentioning this terrific guy who's been our Google Summer Code last year student who worked on entity embed and kind of has taken the lead on entity embed and done a really, really great job. So thanks to him. So this is the basic like selection form for how to embed something. And so I'm inserting a file and it's just right now autocompletes by the file name, which I recognize for most people isn't very useful. That's where we want to swap in a more better selection component if it's available, so this is swappable. And it works for nodes, all that kind of good stuff. And then the next step of the form is you get to pick how you want to display that item. So you select it and then configure how to display. So with files, you can pick from a file or image field formatter. So like here you could pick just like an image style or you could do a responsive image formatter as well. It's just ready to use and you type in the alternate text if you want to. It's just, this is all based on field formatters, which is kind of another thing like we're trying to reuse things as much as possible. So rather than like these custom ways to display things, we're like, hey, it's a file. Why not just let them use file formatters and image formatters? They're already there, just reuse them. And if you insert a node, you can use any kind of entity formatters, that kind of stuff. And so this is an example of an entity one. I'm inserting a node called test article and I'm saying display as the label and link to that node. Or you could have it render that node completely in your body and it totally works out of the box. You can use the Drupal 8 quick edit links inside the rendered entity. It's really, really great. It works really well. And so I inserted the picture of Matt, the lower-eating cheese. And I can't really edit anything about this, aside from being able to edit that again in the contextual menu. So I can't accidentally change it here in the WYSIWYG preview, which is really nice and a new feature in Drupal 8. So I could edit and go back and select something else, swap it out or change the way it's displayed and it just works and that's really great. And kind of the nitty gritty of it is that we use a custom tag called Drupal-entity and there's just some really cool stuff in here. So for example, we have an entity ID four, but we also store the UID of the file of whatever entity's being referenced. So when you deploy stuff, all your embedded content when your body fields will work, which is really nice. And it even, that alternate text is just an alt tag, an alt attribute, like as normal and it doesn't need any more conversion than that. So it's using these nice data attributes. Jeff Eaton is presenting right now on like the battle of the body field. He just goes crazy for this. This is like his perfect system. And so I don't want to say I made it for Jeff, but yeah, it's a benefit. And then this is a little bit smaller. So if you look at the slides, you can see this, but this is how you configure a button for embedding. So you pick an entity type, you can give it an image for the button to provide the label and you can actually configure which displays can be used. So if you want to manually control, like I only want them to be able to use responsive images or I only want them to be able to use the rendered entity format or you can have control over that, which is one of the recent things that we've added and I think has been really nice. And so I mentioned that we're gonna abstract some of the stuff from the entity embed into this embed API. That's one of our Google Summer Code projects this year. So the concept of making a button that corresponds to something like an entity or something else and then has display plugins and be able to select the display plugins, that's gonna be in this module and we're gonna kind of reuse it for stuff like embedding URLs. So like you paste in a YouTube link and we want to be the de facto way to do that. So this is another Google Summer Code project, two out of the bat. So if you paste in a YouTube video, we kind of want to kind of do the same thing. We're not gonna use a custom tag, but we're going to use a link, but maybe add some custom attributes to that, like how to display it just as the HTML, how it embeds, that kind of stuff. And we also want to support more things than just OMBED. You should be able to provide some custom plugins and provide your own custom URL, like, oh, I'm gonna paste in a Drupal.org link and I'll output this HTML and you could add support for people that paste in URLs. And it would also be nice. And we have on the roadmap for this that if someone like paste in a iframe embed of a YouTube video rather than the URL, to have it like magically convert itself underneath into the actual normal syntax. So they're all normalized for you, which is something that WordPress actually kind of does. If you paste in a URL to YouTube, it pops up an embed for you. So we want to make sure that we're kind of feature parity with that because I think that would be useful. And then there's the short code embed, the other embed thing that we're planning, which is kind of like macros. I don't know if anyone's used short codes in Drupal. It's kind of just like little random stuff, like, oh, I wanna do a special call-out text in my body that maybe doesn't correspond to a specific tag on the box. So I'm just gonna put a form that says, here, type in the call-out text and select something else and it'll transform it into an HTML tag like this. That's kind of one of the other use cases there are. Not as much as entities and URLs, but it's there. So we're kind of planning that right now. All right, so we covered the embedding. Any questions about embedding? All right, yes. Yes, the question is how do those tags go through? Yes, they go through a text format system that converts that Drupal-entity tag into whatever is rendered, like it'll be inside a div or whatever. Yeah, it should be possible. Yeah, that's definitely what we're trying to abstract is different ways to embed stuff and kind of use that same system. Yeah, yes. Sorry. Yeah, so the question of keeping the files and assets separate out of the body first is kind of the storage and not directly embedding them. The nice thing about having this kind of standard tag is that it should be totally possible sort of like the insert module to basically reuse the same syntax and have an insert button on your file field that then just pops up that tag into your body field. So as long as you've uploaded it somewhere, it can just be used and as long as someone uses that tag, it'll just automatically work. Does that help a little bit? If you have more, just let me know. Cool. Yes. So file locking in Drupal 8, an update on that. We've actually got an issue in Decor that's been committed that makes the, so the issue is that if you upload a file and then don't use it anymore, Drupal will automatically delete that file after six hours. It's now configurable out of the box in Drupal 8. You can set it to be like, don't ever delete my files, just keep them around, which eliminates the need to lock every file. We do still track file usage in Drupal 8 and the nice thing about having that standard syntax of that tag for embedding entities is that we automatically can track that usage then. So like I've embedded that file on node one and it stores that automatically. We've worked with Wim Lear's on that, so. Yeah, once you save the node, it'll record that in for the file usage table. Yep. But it's kind of nice that out of the box you can set that you don't need to lock all files, which is nice. That hacker in Drupal 7, I hate that, yeah. Yes. Yeah, since it tracks the usage, just fine. If you've embedded a file and you delete that node, it'll delete the usage for that file and then if Drupal sees that, oh, I had usage but now I have none, it will mark it as temporary and it's up to your configuration, whether you've set the default of six hours or changed that, it will remove it or not, so. No, you cannot set that for individual files, it's a global. Yeah, I would definitely foresee a use case for some kind of file locking on individual files still. Like always, always keep this file. Yeah, I would see that use case. Good point. The great thing about Drupal 8 is that file usage system is totally swappable. So you could swap out a like per file or whatever logic that your organization needed to do that. So it's very possible. So yeah. All right, any questions about embedding before I move on to browsing? All right, we'll go ahead and move on. So entity browser is the new home for the browsing component and this is probably the biggest challenge, I think, for moving forward, because it's not a simple task to kind of abstract browsing files into browsing any entity. But we're working on it. It's making progress. It's maybe usable if you're living on the edge, but we're definitely working a lot more. This is our third Google Summer of Code project to have someone helping out on this. And so we have completed the basic architecture and API and the configuration, the config entities for browsers and I'll kind of show the fun architecture picture. And it's also integrated with the inline entity form right now, so if you browse for something, you can also inline edit it in the browser as well. We still need to work on the UI for browsing. It's still a lot in progress. And we also wanna make sure that it's really fully integrated with views. So you use views to select stuff. That was one of our big things that we really liked when we did the Media2X branches, basically on views. And we wanna make sure that that's possible in Drupal 8 for any entity type. But it gets complex when you add filters and all this extra stuff that views wants to do. So it's just a hard problem we're trying to work through, but that's our goal. So the fun architecture for entity browser is there's different ways to display the browser. Could it be a standalone thing? Could it be an iframe? Could it be a modal? Most people probably use a modal or inline kind of a thing. There's the widgets, the individual widgets for the browser. Is there an upload tab? Is there a selection tab? Is there a paste a URL tab? That kind of stuff. And we really wanna make sure that we're using existing stuff. So it could be a view. It could be a widget for a Drupal 8 field type. So the upload widget for files should be something you can use natively in this entity browser. And that way it kind of reduces the need for custom code. And if you can write a widget, a field widget, you can use it here. There's the way to display the widgets. Are they tabs? Are they dropdowns? Are they buttons? Could you change the way that they're displayed? And then how you display the items that have been selected? Do you put them in a grid? Do you put them in a list? That kind of stuff. So there's a pretty complex architecture here. And I think we run a little bit of a risk of this being the next big project still that becomes hard to maintain. So we're trying to make sure that that doesn't happen. And there's a lot of good people working behind that too. And just to kind of tease a little bit, this is, you can kind of see in the background here, this is the browsing here. It said select entities. And we popped up the browser in a modal window and using inline entity form to edit a media entity. So it is kind of, it's working somewhat. So feel free to give that a try. Or if you wanna help out, that'd be appreciated. So that is the browsing component. And now we kind of hit into the storage part. So file entity, I've been one of the maintainers of this. There was an effort to port it about 10 months ago that's kind of hasn't had any updates since then. So it's a little bit stalled because I highly doubt that that code works on Drupal 8 right now, being as it was 10 months ago. And that's like 500 cat years in Drupal. So we're gonna regroup a little bit on this one. We kind of wanna take a better plan because file entity had a lot of responsibilities in Drupal 7.2. It made files fieldable. It added the UI, so adding, editing and deleting files individually without having to work with nodes. The listing forms, it added downloading formatters and lots of other stuff. Like it added audio and video formatters, basic HTML5 formatters. So it kind of had a lot of responsibility. I think we need to look at, how should we split this up? Should we just make a HTML5 formatters module? And what does file entity become in Drupal 8? I think we just kind of have to take a step back with that one. But it definitely will be ported to Drupal 8. This one will be available. I think that doesn't get out as often as much, but there's definitely an intent to do that. So if you'd like to help, I'm sure I'll be talking a bit about that this week with some of the other maintainers. If you have ideas, come see me. The media module that became all that glue for everything is still gonna be a glue module in Drupal 7, but it's not gonna have all those responsibilities. It's just gonna be glue, and glue is good. As long as it's good glue. So it'll be based on file entity in Drupal 8. It'll have a pre-configured entity browser for you to use with files, and have a pre-configured entity embed button for files. So if you install media out of the box in Drupal 8, our hope is that everything just kind of works for you. You can customize it, tweak it however you want. And with the configuration management in Drupal 8, I think that'll be a lot easier to do as well. So we're looking forward to that. The other big storage component is the media entity. So this is something new. Well, not really that new. But one of the discussions from the New York City camp, Nice Camp, was that the scald maintainers have this kind of abstract concept of, not everything should be a file. It should be this own separate thing. They call it an atom, but we wanted to kind of maybe switch that into a different terminology that could be then shared by other people. So that's kind of where the media entity was born. So this is pretty usable right now. There's some people, I think examiner is using it for a Drupal 8 project. And the basic forms and editorial UIs are completed, and there's already some provider integrations for YouTube, Twitter, Instagram, and local files. And I think rendering is one of the big issues that's still kind of to do. So yeah, I mean, it's in progress slash usable. So, and then I have kind of some quick screen swatches so the progress of this. So this is creating a YouTube media file. So you'd paste in the URL to that, and it's kind of a little bit more of an abstract kind of form. You'll kind of get to pick in Drupal 8 between file entity and media entity, and we'll try and do a good job of documenting the reasons why you'd want to pick each one once we've got them fully developed, because that'll probably be the big question for everyone. But it's kind of nice to have these two different kind of options for storage, because it makes us really think about that embedding and the browsing components, and making sure that they work for both of these things. Because there's a media pink eye module now. I'm not sure how it got that name. It kind of has a disease kind of connotation, but I'm sure it's great. It's kind of what's bringing together media entity, the media browser together. It's kind of the glue module for the media entity. So you kind of want, if you want to try and see how that everything works together with these components, I would give that a shot. Another fun module to mention is the cropping API. So this is a new module that we kind of started looking at all the cropping, different cropping modules. They're all storing basically the same stuff, an X, Y coordinate or a rectangle, some kind of thing about an image. And we wanted to give them kind of an API to base off of and kind of standardized. So it's just an API, but it's in progress right now. I think it's pretty almost finished, just aside from any integrations or UI, but that's pretty ready to go. So if you're looking for cropping, I would keep posted on this one. Another small module that I think I find really interesting is the fallback formatter. So File entity in Drupal 7 had this fun concept of, okay, I have a video file and I wanted to figure out how to display it. Okay, I'm gonna try my YouTube file formatter first. And that formatter says, hey, are you a YouTube file? No, okay, move along. And then it goes to the next thing, like okay, is it a local video file? And it says yes, I am. And it says okay, here's the HTML and formatter to use, use HTML5 video. And it kind of has that system of falling back to the next one, next one, next one, until it falls back to a default. And so we abstracted this to its own module in Drupal 7 and it supported a Drupal 8 as well. It's not passing the test though for some reason. I tried to fix that this morning, but I couldn't, it ended up time. But it's an interesting concept to use, like if you have a file field, yes. Totally, yes, it works for multiple value. It's designed for the multiple value use case. So like if you've got a YouTube video in slot one of your field and an image in slot two of your field and a local video in slot three of your field, like this gives you a way to display all of those items in their own way, if you had a file field. So it's, you can kind of see like, you pick which formatters you wanna do, you drag them in the right order that you want them to run in, and then you give those formatters the options that you want. So it just, it works great. So it's a fun one to use if you need it. And another interesting one is the recycled formatters. I like this name. So there's an interesting problem that say you put a file field on your node and you upload images to it, you can't actually just like pick them to be displayed as images. You have to have them like rendered as generic files or a link because if you use a file field, you cannot use image field formatters. They're two separate field types. Or if you had an entity reference field that had files, you're limited to entity reference field formatters. You can't use a file formatter or an image formatter. And I don't think that's cool. You should be able to reuse those between those. They're all references essentially. They're files or entities. So this is this, we have a module in Drupal 7 called file image formatters that lets you reuse between file and image fields. But we wanted to take that to the next level in Drupal 8 and possibly backport that to share between image file and entity reference fields. So it's like a little bit of insurance. Like if you pick the wrong field type, you're not screwed down the road. So yeah. I mentioned downloading in file entities responsibilities. We want to split this off into a separate module which is called like file download. There's been several modules out there like related to file download and file download tracking. It'd be nice to have one good home for that now in Drupal 8. So like having a URL to hit for a direct download like file slash five slash download with secure tokens that people aren't crawling every file download link by a numeric index. Provide support for access control. Can this user download this file or not? And logging downloads too. All right, this file's been downloaded 40 times by this IP kind of thing which I think is useful for a lot of implementing sites. So we're planning this out right now. And then we have struggles. So that's our progress. And I want to touch on the human side of this too. I mean, we struggle as a group. I struggle as an individual with this too. I think recent, I mean, I was on paternity leave for four weeks. I was completely out. And so like I couldn't really follow stuff and taking care of two kids. I can't really do stuff on the side was learning how to handle that. And I just got back to work a week before DrupalCon. So it's kind of like this flurry of trying to get everything prepared and get updated on everything. And I think I let some things fall. And it's like, when we don't have a definitive person to lead stuff like the official Drupal.org initiatives, someone who's that good communicator and project manager type of person that can help motivate people and ensure things are constantly going. We struggle with that since we don't really have that. So we're trying to keep that going. But it kind of, it goes well and then it maybe goes not so well for a couple of months. So yeah, we're just trying to keep improving that. We're still working on stuff like funding. It'd be nice to have sprints every quarter with our team, like not necessarily at Drupal events. Like it'd just be nice to hang out for a week at an Airbnb and just code all of us together in the same room where we're not distracted with a Drupal event. So we're trying to figure that out. Another thing that's been interesting to look at is composer usage in Drupal 8. So stuff like Plupload, including external libraries. How do we do that from a reliable perspective? If you install a module, how do those libraries get downloaded? Because the user shouldn't have to download all those libraries for them. And I wanted to call, specifically, there's a buff today between five and six p.m. to kind of discuss our options and figure out a path forward. So I will be there and I would encourage anyone interested in that issue to be there as well. So we're not sure how to use composer quite yet from a module standpoint. Something I kind of deal with is GitHub versus Drupal.org. We moved a lot of our development to GitHub for these modules, which I think is great. GitHub has definitely good use case and I love pull requests. It's all good and inline commenting on pull requests is good, but I'm starting to really get frustrated with the separation between our issues in Drupal.org and the pull requests in GitHub and communication happening in two different sides. And there's a proposal to make issue workspaces on Drupal.org to kind of help give you get repos per issue. So you could check out a branch that corresponds to an issue. And so there's a session on Wednesday. I wanted to specifically call out for that because I was super interested in that too. But I just find that challenging, like duplicating efforts. Like it's nice to have one home on GitHub as an organization. Like here's all the modules we're working on, rather than Drupal.org trying to search for all that stuff. So that's just kind of one thing I wanted to point out. And of course, how do you get involved? There's lots of ways to get involved. We attempt to have weekly scrum meetings in IRC, but I think the last two months have been not very regular on that. That's our bad. We're gonna try and revamp that again. But if you come to IRC, just feel free to ask a question at any time. I have log stuff all the time, so I will respond back when I can. Someone posted a question at 2 a.m. this morning and I finally got back at 7 a.m. today. So like I said, we have our GitHub organization, Drupal-media that houses all the development projects there. We like to use a service called Hackpad for planning discussions and architecture documents too. And we have a group on groups.drupal.org as well that we post stuff to as well. Myself and Yana's are here. We both, you can contact us on Drupal.org. We're trying to get more sprints organized. I have a slide on the next one. We use Trello for organizing our sprints and stuff, just trello.com slash Drupal-media. And we also have a website, Drupal-media.org, but this should have been one of our circles. I'm not sure how to use it properly yet. We haven't figured out what content do we post there, that kind of stuff, and how we keep it updated. I wanted to point out that we are sprinting all this week in Los Angeles. So feel free to join us in the Coders Lounge if you're there, or just pop into IRC and in the Pound Drupal-media channel. We'll direct you to someone who can help. And there's also gonna be a dedicated week-long media sprint at Nice Camp, the New York City Camp, July 13th and 19th. So if you're interested in that, feel free to check that out. Or if you want to have a sprint on media, let us know. All right, any other questions at all? Yes. It's kind of hard for me to explain a little bit just because it is an API. So it's just mostly like, how does, I think it stores an entity type for, yeah, he's gonna give a better answer. I'll let him answer. Yeah, it's basically a storage component for crops. It is a custom entity type that stores the coordinates of the crop area on an image. And it's kind of done generically so it can work with file entity and media entity and you could do like strange things. If you have an image of a node and you could implement it in a way that you would store crop information directed for that node even going around file entity. So it's kind of generic. It's storage part. It is implemented in a way that allows you to store either just focal point information or the entire crop region. And it's that way we wanted to provide support for both cases because right now for D7 you have modules to do either of those. And that's more or less it. It's just storage that stores an entity and because it's an entity you could add fields to it if you need to store some more information with it. Or it could be revisionable. Yeah. Yeah, like your focal point could be revisionable. That's kind of interesting. You couldn't reference to it from some other entities. Use the entity reference, things like that. There was a question over here, yeah. Sure, so the first part of kind of what the screenshots are based on, this is media entity here. And the screenshot of the media browser is also media entity powered as well. The embedding stuff is just any entity works out of the box. It doesn't really rely on files, files are in core. It's just like, you can only reference them by a file name. Does that help answer that part? I guess so. Okay. It would be the same thing. So like, let's see. So like this example where I'm referencing the file that has the file name mat-cheese.gif that is a file entity. Just in core they're not fieldable. And there's a listing page of files but you can't really do much with it. It just links the file and shows you where it's in use. You can't like delete the files from that page or edit them, that kind of stuff. But you know, this, since they're already defined as an entity type, it works out of the box with the embedding stuff, yeah. Well, they were an entity type in Drupal 7. It's kind of the same situation in Drupal 8 now, so yeah. But we didn't have anything that worked on an abstract basis like this in Drupal 7 before, but it's nice to have this now. And the second part, okay, all right, cool. Yes, totally, yeah. Totally put in a user. You can put in a block. Anything that's an entity type. It can get hairy, but it works, which is nice. The fact that it works is kind of the big thing for us, yeah, yeah. That's your responsibility. If you do crazy things with your tools. Yeah, you're on your own there, yeah. If you do the road, you decide. Yeah, it gets, brandt. And if so, have you seen any of that? Has anyone working on any of that yet? So I think, yeah, it should be totally possible, you know, with both solutions, media entity and file entity, I think we should be shooting for Revisionable out of the box for both. I know media entity is. And I know that there's a control project for file entities in Drupal 7, like file entity revisions. And that's kind of one of the things that like I was taking a look at file entity again, and it's like maybe adding revision support, like as a sub module, like to have it there and not a separate project, like bringing it into file entity a bit might be a good idea. It's like, hey, I really would like revisions for my files, would be nice to have. Yeah, yes. Oh, sandbox prison. I'm looking for someone who can help me with it, allows you to edit images so you can rotate, you can crop, you can change the contrast, resave the image back into Drupal, and if someone wants to talk to give me their address, I'd love to work with someone on this, and hopefully get it in maybe into the crop API or something. Yeah, we're based on the crop API, yeah. Definitely. All right, if anyone's interested, let's see him, yeah. All right, any other questions at all? Yes, in the back. Mm-hmm. Yeah, so why don't we ditch the file and image field types in Drupal 8 and just use empty reference? At before, there wasn't like the ability to say, like, oh, if I'm referencing a file, only these four matters are available. That was only added kind of very late in the Drupal 8 cycle, and I think like at this point, we're trying just to get the release out the door. I think that should be the goal at this point is to have just an empty reference that says I can reference files, because Drupal Core does now have the way that says, hey, am I, I'm a formatter, is, am I attached to an empty reference field that references files? Okay, I can be used, if not, no. Don't show me in the list. So that way, like, you could see image and responsive image in the list of four matters for that, but not in like the node reference fields, yeah. I know there's an issue for that out there, but that's probably 8.1 material, so, yeah. Yeah, we're not exactly, it's bringing up the point that like, if the embedding concept right now is very specific to one entity type, so like it's very discreet, I want to insert a file, I want to insert a node. We haven't quite figured out how we're going to handle cross like multiple entity type support. It should be in our roadmap, it's just kind of the problem that we're like, let's get this working and working really well first, kind of, but that should be in our roadmap, so if not, well, let's file an issue for that. Yeah, and you're also going to run into the issue that views can't list multiple entity types in the same display, like that's a blocker for that too. Two different widgets, yes, yeah, yeah, yeah. Yeah, I mean, for now you can just have separate buttons, I think that works for a majority use case, yeah, totally, yeah. And an editor side too, I think, yeah, it's more discreet, like I'm going to insert this thing, yeah, yeah. All right, if you have any questions, tweet me, find me at the little about booth afterwards, yeah. Pink Eye is based on Animal Farm, not the disease, okay. Got it, that's, we might want to put that on the project page. All right, thanks everyone, have a good lunch.