 Welcome to session about the entity browser module, which is one of the modules that we created as part of the media initiative, but it's also usable outside of media scope. My name is Yanis. You can notice me on the internet slash RSM. I'm working for a company called MD Systems, which is based in Switzerland. I've been an active member of the Drupal community since 2009. I've been using it even a little bit longer than that, but got actively involved in the community when I went to my first DrupalCon. And if I would do it again, I would definitely go involved earlier. So if you're not actively involved in the community, I strongly suggest you to do that ASAP. I'm one of the leads of the media initiative. It's the initiative that has been working on many modules, mostly contra modules that are trying to solve all sorts of problems related to media problem space. By media, we mostly refer to media assets management from the content creator perspective and storage, et cetera. Recently, we also started to discuss which of those pieces could potentially end up in core, which would make them even more visible and probably even better. I used to work for a company called Examiner.com. Anyone heard about this company? Yeah, some people, but not many. Examiner was one of the first websites on Drupal7. It was a huge media website. We had millions of articles and tens of thousands of active so-called examiners, which were people that wrote for this media site. And for some time, it used to be the biggest Drupal website on the internet in terms of traffic and in terms of amounts of content. Because it was media site, we had to solve all these problems there, which is why I became interested so much in this area. Unfortunately, website is not live anymore. It was shut down and company was shut down this July, but it is like really important part of Drupal's history. So a company where I work now, MD Systems, is one of the biggest contributors to Drupal in general. We are exchanging with Acquia on the first place and on the second place. But if you consider the size of the company, then we are free to say that we're the biggest contributor. Because there are like 700 and we are 20. Our CTO, Berdir, Sasha Grossenbacher, is one of the top five contributors to D8. We started shipping D8 projects more than a year and a half ago, pretty early. Most people were still afraid of D8 at that time. And we also have a lot of media clients. So we are kind of D8 expert, D8 media expert. We are also involved in a club of media companies that work on a D8 media distribution together, which is called MP8. And this distribution is already running a bunch of media sites, mostly in Switzerland. We try to dedicate 20% of each project back to the community. And yeah, if you need Drupal-aid expertise, we will be happy to help you. So what are we talking about today? First I will explain what the entity browser is, what is its purpose. Then I will talk about the architecture, how it's built up, because it's a pretty powerful tool, but it can also be a little bit complex. And understanding architecture and ideas behind it is very important to be able to work with it efficiently. Then we will see a few use cases where you can use it. These use cases will be in the media world and also outside of it. We will also check how it integrates with inline entity form module, which is a module that was created for Drupal commerce in D7. But similar to entity browser, it was created in a general way, so you can use it in many other areas too. And they nicely interact and nicely complement each other, so to say. And I will talk about where we are at the moment and what's the roadmap, what are our current priorities with the module, and if it's ready to be used today or not. So have you ever wanted to upload more than one image at once? Please raise your hand if you needed this feature, obviously. So entity browser allows you to do that. Here we have a standard node and with a file field. And when we open the entity browser, this is now the entity browser, we can drag and drop images to this upload area and select them and they're there. Yeah, this library that is used for uploading, it's called drop zone JS. It's a standard JS library and we have Drupal module for that. You can use it on your own forms, but entity browser then does another step for you and creates plugin that knows how to work with entity browser. Have you ever wanted to select images from media library? Please raise your hand if you wanted to do that. Yeah, this is one of the most requested features that we get in relation to media in Drupal. And here's a similar example, a node with a file field, image field, and I should make this screen cast shorter. And now when we open, we can go to this second tab, which is a media library and we pick few images and they're being selected. In this case, only one, but it also works with more of them. As you will see now, maybe you would want to combine both. Like you are building an article and you want to add a slide to your images to it and you want to select few images from the library and then upload few more and then maybe reorder this selection and then confirm that this is it. And that's actually possible. In this screenshot, we first go to the library, select few images there. And then when we go back to upload page, we can see that this selection is now displayed here. And we can decide to upload more images. Or just one in this case, I think. And, oh no, it's two. And now when we uploaded them, these two images appear below and now we can reorder this selection. We could also remove few items if we wanted to and when we're fine with this and we confirm the selection, everything is sent back to the field and then you do whatever you want to do with that. Then, let's forget about media for a second. A lot of times, especially on media websites, you have this use case where you want to reference related content for your article that might show up in a sidebar block or something like that. And of course, usually we use entity reference for that. And default entity reference field is just this autocomplete, have you ever seen it? Like this autocomplete where you start typing the title of your note and then you get like suggestions and you pick from them. And this works a lot of times, but sometimes we need a little bit more. And we can use entity browser for that. In this example, we have another note that has an entity reference field that references notes. And when we open the entity browser, we are presented with a view and we can use this view to search for this related content and select it and then it's displayed here. It's displayed a little bit differently because it's not an image, it's a note, but also the display configuration can be tweaked. Like in this case, we're only displaying titles, but you could create like a view mode, which you could call thumbnail or something like that and configure a nice thumbnail for your article. And this really depends what the structure of your article is, but you can do that. That's the most important part. And another case, this is not so much useful for related articles, but it can be used for in other areas. So for example, if you want to reference something like another node and you realize that this node that you want to reference doesn't exist yet, usually you don't want to go to some other page to create that node and come back and then find it. In a lot of cases, it's easier if your content editor stays in the same flow. And entity browser allows you to do that. One of the so-called widgets for entity browser that we have is called entity form. And instead of displaying a view, it will display you an entity form. And inside entity browser, now you can create new entity, node in this case. And when you save it, it's created and then reference to this node that you just created is passed to this field and then you automatically reference it. And as you can see, now it's referenced here and the content of the body field is what you expect it to be. So a lot of use cases are covered. All these are real life examples. It's nothing that's like we tweaked. If you download entity browser and in case of those media examples drops on JS, you're able to build that. So what is entity browser? It's basically a very general browsing, selecting and creating tool. It allows you to browse entities that you have to be able to select them and also create them. But in our problem space, we think about creating entity just of another special case of browsing them because this way it's easier to abstract it and easier to work with these concepts. And it can work with fields, but it's not limited just to fields. You can use it for with the wig embedding, for example, or you can use it in your custom forms. If you have a custom form where you want to reference or get a list of some entities, you can use the form element. And the only thing that you need to do is to read values of those entities from your form state. Everything else is handled by the entity browser. Any questions so far? And if you will have any questions, hopefully you will. There is a microphone there in the middle of the room and for the sake of the session recordings, I would ask you to go there to ask them. So let's talk about the architecture a bit. It's very flexible, which makes it a bit hard to understand sometimes. But it uses standard tools that come with Drupal Core. It mostly relies on plug-in system, which is something that was introduced in Drupal 8. So if you know patterns that are already in core, you shouldn't have problems understanding patterns in entity browser. When we were designing the architecture of the entity browser, we were having this mock in mind. So what do we have here? We have a listing of entities here in the middle part, which are entities that we will be selecting from. And then we said probably in general, one list is not enough. Maybe you want to have two different lists. Example for that would be global media library where all the files are or just users media library where files that this user that is currently creating content uploaded. And then maybe another list could be something where you upload and then list is created for you. So that's why we have these tabs at the top. These tabs are allowing us to switch between these pages where we interact with our entities. And then we have also this bottom part, the gray part, where the intermediate selection is displayed. This is what we've seen earlier when we select a few files from the library and then upload a few more. And of course, in a lot of cases, you don't need this bottom part. And you might also not need this top part with tabs because you are fine just with one view that displays something and allows you to select stuff. And cases where there is nothing displayed at the top and at the bottom are just special cases of the same concept for us. So if this is called like thumbnail selection display, thing where we don't display anything and don't allow you to do multi-steps workflows, it's called no display. Because it doesn't display anything. It doesn't allow you to interact with things that you already selected but it just passes everything on to the code that's called entity browser. And it's the same goes with the top part. If this is tabs plugin, for example, if we don't have anything, we have a plugin that displays only the first listing that we have. So we wanted to allow the simple use cases where you don't need to complicate too much but also have architecture support you to go crazy. And these parts that I just described are basically plugin types in entity browser. This middle part, which is the meat of entity browser where entities are displayed or uploaded or like whatever is called the widget. And it really can be a lot of things. It can be a view, which we've seen already. It can be a file uploader, like it can use just a plain HTML5 upload element if you want or you can use the rubzone.js which gives you nicer user experience and thumbnails and progress bars and stuff like that. Or it could also be a remote resource browser. You could have a widget that connects to YouTube's API, allows you to interact with it and then like search and get some results and when you pick videos that you want to reference from that list, it creates entities behind the scenes for you and passes them on. We are currently working on the integration widget for one of the commercial DEM providers. DEM are digital asset management systems. And this is exactly what we're doing. Like we have a list of images that they have in their system. We interact with their system through APIs, display what could be used on the side to the user then when user selects images, images could be downloaded to your site and used locally or you just store the reference and host images through the DEM system. Or it can be an entity format, allows you to create an entity inside of this context. All the items that have stars are already implemented. And you've seen most of them except of HTML5 file uploader you've seen the rest. And many more, like modules, different modules in contrib are already building their own widgets and like integrating with whatever they need to do. If you want to build your own widget, you basically implement a class which is a plugin and you need to implement three functions. One that displays the rendered output of the widget, one that validates the selection and one that handles submit. And it needs to implement this interface. And then propagation of the selection when you call submit works through symphony events. But if you don't have any special requirements you don't need to deal with that because on the base class we have a helper function that you can call. You just pass a list of entities that were selected to it and then everything else is handed behind the scenes for you. Any questions about widgets? Yes, please and please step up to the microphone. This is maybe a silly question. Just when you have a view and you're paging through. Yes. Do your selections from the previous page somehow persist? No. Or they're lost? Not yet. And as far as I know also in core, like if you have content listing on admin content I think that there is not persisted either if you want to use bulk operations. It's a bit tricky problem because you need to store the state. Obviously it should be possible to do, of course. And it's on our radar but it was never the highest priority. Okay and it's still not. It's still not. Okay. Because it's a thing that also plagues to use bulk operations in Drupal. It's a big request somehow. Yeah, I mean, yeah. It's definitely possible to do it, I think, but we didn't get to it yet. For more low level stuff that we needed to sort out. But you can join us on Friday. Okay, next plugin type is so-called widget selector. It's called widget selector because it allows you to select widgets. It allows you to select which widget you want to use. Makes sense, right? And in this architecture mockup thing, it's represented by tabs. But it can be many other things. It can be single widget as I mentioned earlier which handles the case where you don't need to select any widgets because you always use just one. It can be a dropdown, like instead of having tabs on the top, you have dropdown hidden somewhere on the side. And when you select new widget from the dropdown, page reloads and displays the widget that you want. It can be buttons, which is basically similar to tabs, but appearance is different. And it can be tabs. In reality, most of people use either tabs or single widget. The point was that by implementing these different options, we showed that this is possible. And if you have a very custom use case, you can do it. Like we had this nice feature request that said I have uploader in a library and I want like initially when you load your browser, I don't want to display anything, just two links, which say I want to upload, I want to select. And then when you click that, you are transferred to the widget that you wanted. But then also your selector is displayed as tabs on the top. From the user experience standpoint, it could be a nice improvement. There is an issue for that. There is like a back of the napkin mock, but nobody got it, got to it yet. But it's a nice idea and this concept of widget selector would allow you to do that. Yeah, and really there are not more widget selectors that I would know about. I suspect that in contrib, this will mostly be it. And then other crazy stuff will be custom projects and solving their really custom requirements. Again, if you need to implement your own widget selector plugin, you need to create a class, a plugin that implements this interface. And again, you have get form, validate and submit function, which basically handle how widget selector is displayed. You validate selection of the widget and you submit and trigger the change of the active widget. And there's also one function that is called initially, which is called set default widget. And this happens at the beginning when the entity browser is being loaded so that entity browser knows what to display for you initially. Any questions here? I need some water, cause I talk too much. So the third plugin type is called selection display. It's called like that cause it displays your current selection. Here it's displayed at the bottom, but you could move it around. Like you will see example later when it's initially hidden and then you can press a button and it's like rolls up. And yeah, it's the part that displays current entities and also decides when your selection is completed. Like in this case, it decides so when you press the use selected button. But if you are using the no display selection display, that sounded very weird, which essentially means that this bottom part is missing, it decides that selection is done every time when you select something, which basically supports this use case where you don't need multi-step workflow, but just like when you selected something and where you uploaded something, it assumes that you're fine with that. Then we have a view display which uses a view to provide this list of entities for you. With view display, there are two limitations. One is that we cannot do reordering with it. And the other one is that if you have the same entity selected twice, which generally works, nothing wrong with that, view will display it only once, which means that the actual selection might be different from what you see. And these are limitations with views, so we cannot overcome that. And then we had this rendered entity display, which is what you will see later. And it essentially looks like that. And these pieces, each individual item, is rendered entity and you decide which view mode you use for that. Again, plug in, class, implement this interface, get form, validate, submit. Get form defines how your selection display looks, validates your submits and submit decides when the selection is completed. Any questions about this plug-in type? I will assume that you understand everything, which is nice. And then the third, actually the fourth plug-in type is so-called display plug-in type, which basically defines how your entity browser is displayed. Currently, we have three implementations. One is iframe, one is model, and one is stand-alone page. Stand-alone page is not really used anywhere as far as I know. It was more like a proof of concept to show that this is possible to do. But iframe and model are used almost, it's either one or the other. And obviously, model is when you decide that you want to select entities, it will open a model for you in display entity browser inside it. And iframe will display it in line with the form where you are trying to do whatever you want to do. And in the demos before, you saw both examples already. With the files example, we used model. And with the related content example, we used the iframe. Maybe you remember that when we selected that, like select related content button, it didn't open the model, it opened like another frame inside of the main form. Again, we wanted to make it flexible so we don't make any assumptions for you. We implemented plugins that we think would work for 95% of people, but still if you have crazy requirements, you can use that to modify the behavior. Same story, plugin type, plugin class, interface. In this case, functions are a little bit different. Display entity browser is function that is called when you want to inject entity browser into a parent form. And this is now also abstracted, like if you usually don't call this function, it just everything happens internally. If you would be to implement your own display plugin, you need to implement it, but you will probably never call it. And function selection completed, which is also called internally when selection is done. And then entities are passed into this function and this function is responsible to informing, like upstream code about the selection. This usually happens through some kind of front-end interaction, but it could be anything. So where we can use entity, sorry, any questions about displays? Displays are maybe sometimes a little bit confusing, but for now you just have to remember that what you probably need is already there. And just remember if you have any special requirements in this area, you can probably do something about it. So where we can use it? We can use it with fields. We've seen that. This is entity reference field. It's a widget for entity reference. As I said, you can define how this looks. In this case, we are only displaying titles, but you can also render notes or actually any entity. You can reorder this, like you can drag them around. You can remove items by clicking the remove button. And we also have edit implemented, which basically opens a dialogue and displays an entity form for this entity. So it's, in some cases, you might need something like that. Then it can be used as a file or image field widget. We've seen this earlier already. Excuse me. And it can be used in entity embed. Entity embed is a module that allows you to embed any entity into WizzWik. And it integrates with entity browser, which means that you can use entity browser to select those entities. And then it allows you to define how this entity looks when embedded. It also allows you to add a caption to it to define alignment. And in this case, when we are embedding an image, it also allows you to set the alternate text and the title. And we've embedded this nice animal in our body field. This is done through entity embed module. It is another module that we created as part of the initiative, media initiative. Again, we knew that we need to solve this problem of WizzWik embedding, but we didn't want it to be media specific. And that's why we created, we implemented architected it in a way that allows you to embed any entity. You can embed a node, you can embed the taxonomy term, you can embed commerce product, like whatever entity that is able to render itself can be embedded. Or, yes? So the question was for the recording, what is stored in body fields if it's just a reference or a rendered entity itself? It's just a reference. We have, it's still an HTML tag, but it's a special custom HTML tag called triple dash entity. And then it has data attributes on it, like the entity type, UID, and display configuration, like definition of how it should be rendered. And then when everything is displayed, we have a text filter that searches through your body fields and finds these tags and uses these data attributes to load the entity and render it based on the configuration that you saved. Or, if you decide so, you can, for example, extend this filter and ignore your display configuration entirely and display it whatever you want, however you want. And since it uses UIDs, it should, it works with like deploy module and things like that. And yesterday at core conversation, there was question about this, and I've never tried it, so I wasn't able to answer if it actually works. I just theoretically know that it should work, but then I had somebody in the audience that confirmed that they used it on their own project. So, I'm going to question in the back. Yeah, the question is, if it's possible to use entity browser with paragraphs, the answer is yes, it works. We just add a field, like an entity reference to paragraph and use widget for entity browser. There is only one catch. Sometimes if you have more than one paragraph field on a form and both or more of them are using the same entity browser, values can leak around. And this is one of the critical bugs that we need to solve to get to beta. This is one of the highest priorities right now. And some people, including myself, are working on this bug this week. So, it should be resolved soon. But if you have only one paragraph, it should work without, I mean, only one paragraph field, you can still have more paragraphs. It should work without any problems. Yes, as I mentioned, you can also use entity browser in your custom form. We provide the form element for you for those who are familiar with form API. This is like part of the form API structure and you basically say type entity browser. You define which entity browser you want to use and then you can also define cardinality, which will mean how many entities you expect to get from the entity browser or also it's possible to add more validators. So you can write custom validators that will be applied to your selection and if validation criteria is not met, entity browser will complain about it and won't accept the selection. But for 80% of use cases, this is what you need. Just define which entity browser you want to use. And then, when the selection is complete, the selected entities, reference to selected entities, appear in a hidden form element, which then when form is submitted, leaves its values in the form state values. Very easy. Any questions? The plan now is to do a demo, to show you how to configure entity browser a little bit because this is the part where a lot of people are lost sometimes. And the first example would be how to do the reference, the related content use case. Now I will have to switch my screens here. Okay, this won't be as easy as I wanted to, but we'll figure it out. Okay, let's try to zoom this out a bit. Okay, I have to look at that screen because it won't mirror it. So I have a Drupal site. It's a clean Drupal installation. The only thing that I did is pre-configure the content type so we don't have to do that because that should be clear I guess and generated some content so we don't have to do that either. And basically what we have here, can you see like is this visible to everyone? Size okay. We have this article content type, which has a title of course and a body field and it's probably not working. Switch from full screen and back. So body field and we have image field where we basically attach images to our article and we have related content entity reference field and also text, but we won't deal with that. It's here because I used the default article that comes with standard install. And as we can see, like we can search for related content with standard autocomplete field and we can use this standard uploader. Okay, we'll see if that, okay, whatever. Now we would like to use entity browser for this related content part. First thing that we need to do is to enable the module, which is called entity browser. I already downloaded it of course. If you search for Drupal entity browser, you should be able to find it. And now if we go to configuration page, we can see that we have entity browsers. We can see that there are no entity browsers yet. We can add one, but it says that this form depends on C tools module and you need to enable it to be able to do that. The reason for that is that C tools provides a wizard for multi-step forms, which was very useful in our case, but we didn't want C tools to be dependency for the entire module because you actually don't need it for entity browser to work. You only need it to do the administration and that's why we made it a sub-dependency. And now if we go back to entity browser page, we are presented with this form where we can create it. And now in order to be able to use ref, like to use a view for related content, we will obviously need a view first, which means that we should create one. It will display content. It can display any content type. Let's make it a table. So the titles of the nodes will be displayed in a tabular form. And let's add a filter on title. So we will be able to search and we need to expose it to be able to do that. And we will use contains operator. So if we enter a word into this field, if a title of a node will contain it, it should be displayed with the results. Now if we update the preview, we can see that we already have that. List of nodes with titles. And now two very important parts. First part is that we need the entity browser display for this to work correctly. It's like similar concept, you have block display and page display which will create a block view or a page view. We have the entity browser display. Like your view won't be capable of interacting with entity browser if you don't create it. And then when you've done that, you need to add a field which is called entity browser bug select form. There are two of them. This is a UX bug which we want to resolve. And but basically either of those should work. The problem why we didn't resolve that yet is like if we would simply remove it, we would break possibly break entity browsers for people that were using the one that we removed. So we need to provide some kind of update path which is obviously a bit harder than just removing it. And now we basically see those check boxes here. And I usually prefer to have checkbox at the beginning. I can just reorder that. So now we have checkboxes on the left side. And we save that and the view is created. And now we can go back to not this but configuration. We can go back to entity browsers configuration page. No problem. And now we can create our entity browser. We need to give it a name. I will name it related content. And we need to choose which plugins for each type of plugin that I explained earlier we want to use. I will decide that I want it to be displayed as a model. And since I will be only presenting the user with the view, I don't need any selector for widgets. I will just have one widget which will be my view. So I will use single widget, widget selector plugin. And I don't want my selection to be displayed. I want it to be immediately passed back to the field. So I will choose no selection display plugin in this case. And then I go to the next step and each plugin has its own configuration. Here we are configuring the display plugin which is the model in our case. And we can define how big it is. Or if we don't define any size it will be responsive and it will use the whole space that it can. And the link that opens the model has a label there and we can define how this label looks. And instead of select entities we will say select related content because it makes more sense for our use case. And then we're in the next step. This plugin has no configuration. The other one also. This is also like a UX problem because a lot of times people just need to go through these steps. You can also, no you can't. Sorry, there is an issue in the issue queue to detect where there is no configuration and like jump to the first step that has something that would be a nice improvement but for now you have to press next twice. And we're at the last step where we select which widgets will be used. And currently we have two widgets available. One is a view widget and the other one is very simple upload. In our case we only need a view. It's being added to the table. We can give it a name. In this case the name is not that important but if we would have tabs at the top then this name is used in the tab. So you can define how tab names the widget that is underneath. Then we can also define how the button, like below the view you have this button that says select and you can also define the label for that button. We will call it select related content and we need to select a view that we want to use. We have only one view in the system that knows how to work with entity browser. It's the one that we created and the reason why it knows how to work with entity browser is because we created that entity browser display earlier when we configured our view. And we save it and we just created our first entity browser. One important thing when you will be doing this, also there are links. Just found another buck I guess. Your entity browser it's not saved when you press next. Like if you change something and you press next it's not saved yet. You have to go to the last tab and click finish and this is when the configuration is saved. It's very important. Some people were like opening bug reports. Yeah, my configuration wasn't changed. Yes, it's also a UX problem for this configuration form and there is issue to add like finish button on every step which would be also very nice to have. And until that is done, just need to be aware of it. Okay, now we have our entity browser. We have 10 minutes left. And now we have to tell our content type to use it because it's still using that autocomplete field that I showed earlier. We do that by going to the content types configuration page and then finding our content type here in this list and going to manage form display configuration page. And here we can see the list of all fields and we can define how those fields are represented in the node form. And we can see that we have this related content field here and it currently uses autocomplete and we can change that to entity browser. And this is not enough. As you can see, it says here no entity browser selected which is a problem because then field won't know which entity browser to use. And we need to go to the configuration here and define which entity browser to use. It's only one that we have. And we could also define how entities when selected are rendered. We will be using just the title and we can decide to opt out like edit button, for example. Like earlier we've seen case where we had edit button, now it won't be displayed, so we won't be able to edit. And another confusing part sometimes, this was not saved yet. Even if the subform disappeared, you have to press this save and then it's actually saved. So not only entity browser has strange UX issues, also corridors. And now if we go back to article creation page, we see that this now looks differently. It says select related content. When we press that, we see the view in the entity browser and we can search for something. It's Loremape Sumi kind of stuff. We found two articles based on this search query and we select them. They are like passed on to here. We can reorder this. We can remove them by pressing to this button and you also see that edit button is now not here. It's because we disabled it earlier when we configured the form display. As you can see, I'm using same strings every time. And now when we save this, we can see that related content is here and it's currently configured to display a link. But this is another part which has nothing to do with entity browser. Any questions? Yes, yes, please go to the microphone. Yeah, so for our content developers that are used to working with featured images for blogs and whatnot, they're blog entries to be related articles. Is there any way those featured images could be used as thumbnails for the related nodes? Yeah, in both places. It could be used here. Like to put them here, you would basically want to create a view mode which displays just that image that represents the article and then configure form display to use this view mode instead of the title. And here is up to you how to configure the view. The only requirement that we have here is that you place these checkboxes in the view and everything else is completely up to you. And you can style it, you can display it as a table or as a grid or whatever you want. And we've done some client work where we used paragraphs to solve the same problem. Can you see a reason for using this instead of paragraphs? Is this more performant or is it just different ways of doing the same thing? It's a different way of doing the same thing. You are talking about like related content, specific use case or- Yeah, then we just configure paragraph to- Yeah, it's up to you how you want to model your content. Like this is not, as I answered earlier, entity browser and paragraphs can be used together. You might have reference fields in your paragraphs and you might want to use it inside. So that perfectly works for you. So yeah, it's like your decision how you want to structure your content. And we also use paragraphs a lot. So it's an architectural decision. We also use both a lot. For images, do you have a successful crop solution? Yes, it's not a scope of this session, but basically there are two modules right now in Drupal 8. One is called focal point. It was already there in seven. And it basically displays a cross on top of the image and you just select the area of the image that has the most information for you and then cropping will try to keep that area intact. This is one. And then the other one is image widget crop which uses like the standard rectangle approach where you decide which area you want to use. And it can have different types. So you can select one area for one image style, the other area for the other image style. And the nice thing about these both solutions is that they both use the same storage component which is crop API, which is something new in Drupal 8. And the reason to do that is if you start with focal point and you're not fine with it anymore, you can switch to image widget crop and some information will be preserved. Obviously, there is difference between the two because one only saves the location and the other saves location and the size, but you could solve that. You could apply default size or something like that. And crop API uses crop entities which means that you could make them fieldable and add more data to them if you want. And our desire is that every cropping solution out there uses this for the storage because then it's easily swappable. It integrates with field widgets. So when you have image fields, it adds, that's a UI to the image field. Not in scope of the entity browser, not yet, but you could write a widget that does that for you. Allows you to do that. We're unfortunately out of time. I wanted to show you another example with the files example that we've seen earlier with drop zone and that stuff. And actually, there's a module that pre-configures everything for you. It's called file entity browser and it integrates with drop zone and it has this masonry-driven grid of images. And this is actually the module that I used for screencasts earlier. And if you download this module, it's called file entity browser or file underscore browser here in the URL. If you download this module and you enable example module that is part of it, then you will get everything that you've seen on the screencast. But conceptually is pretty much the same. The drop zone is its own widget. You select it from that drop down in the configuration form and that masonry-grid is a view that has some custom styling on it. So nothing super crazy. So road map, we are very close to beta. We just need to fix few critical bugs like the one that I mentioned earlier about paragraphs and we should tag beta. We're not planning to break BC anymore. So if you start using it, we won't be breaking your configuration. The reason that we didn't tag beta is that these bugs that we have are quite nasty and just didn't want to commit. But if we will break something, we will do everything to provide BC layer. Definitely for configuration, internal API might change if needed, but probably not. And internal APIs shouldn't affect you. We need to improve user experience a bit. I've just seen, especially in the configuration part, and we need to add more tests, but you can use it today. And lightning distribution, thunder distribution, which is an enterprise media distribution made by Berda. And MP8, which is a similar distribution built by us for our Swiss clients. And many more sites are already using it. And we've seen very fast adoption. Like every week when new stats come out, we have like exponential growth every time. We need help if you want to get involved. There are issue queues. You can come there and report bugs, have open support requests, help us work on it. We also have a copy of the entire code base on the GitHub. If you prefer pull requests, you can open pull requests. All the code is synced between GitHub and Drupal.org. So wherever you clone, you always get the latest code. The only thing that we ask you, if you prefer to work with pull requests, and if you open a pull request, please go into the issue queue, create an issue there, and link to pull request. Because issue queues are still the main place where all the communication is going on. We have meetings, general media initiative meetings every Wednesday at 2 UTC on Drupal-media channel. Come on spring or Friday, we will be there. And thank you and please evaluate the session. And I apologize for being a little bit too long. Unfortunately, we don't have time for any more questions, but if you have any, we can meet outside and I would be happy to answer them. Thank you.