 Hi everyone, welcome to this session of Core Conversation about multimedia asset management in Core. This is supposed to be a conversation, which means that it should be bi-directional, and I would ask you if you have questions or comments to go to that mic and speak there because they are recording this and to be able to, people that will be watching this recording to be able to hear you, you need to do that. My name is Yanis, I am a senior engineer and team leader in the systems. I've been active member of the Drupal community since 2009. I say active because I've been using Drupal even a bit earlier than that, but got actively involved a bit later and if I would have to do it again, I would become active at the beginning. I'm one of the leads of D8 Media Initiative. It's the initiative that has been focusing on improving media and contrib for Drupal 8. Now, we started some discussions about which parts could be moved in core and how and why. I used to work for Examiner.com, which used to be a huge media site. It was one of the first Drupal 7 websites. It was the biggest in terms of traffic for a long time. This is basically where my interested media began and I was also able to work in this area because I was working there. Unfortunately, site is not online anymore. It died this July, but it gave a lot of things to me and the Drupal community. I didn't have any recent enough photo with my new look. Drupal is about a community and these are my Drupal friends, so I decided to use this photo. As I said, I work for a company called Andy Systems. It's a Swiss web shop from Zurich. Our CTO is Sasha. He's one of the top five D8 contributors. We are D8 experts. We've been working with D8 for years now basically, rolling out D8 websites for how much time Sasha, more than a year, I guess, it's fair to say. A lot of media sites, we are one of the partners involved with MPA distribution. This is a D8 distribution for enterprise media websites. We try to give back 20% of every project to the community. That's why you also probably heard that we are one of the biggest contributors to the community, especially if you consider the size of the company because we are quite small. What are we going to talk about today? I will briefly explain what we seem is what our users want from media in Drupal. We will see what we currently have in core. We will see what we currently have in contrib. Then I will explain my proposal for improvements in core and how to achieve that, and then we should have a conversation about it. I'm hoping to hear a lot of ideas from you too. This whole journey, for me, it basically started three years ago at Drupalcom Prague where I had a core conversation about media in Drupal 8, which sounds very similar to this one, but it was much more early stage than it is now. Before that core conversation, I did a survey and asked people what they expect, what they want, what are the features that they most urgently need in Drupal related to media. These were the results, like media library where you can browse all your media that is on your site and search through it, that you are able to reuse your assets, that you can use local assets, like images and documents, and that you can also equivalently use remote media. Local, in this terminology, is something that you host on your web server, so it's not actually local because it's not usually not hosted from your local computer. While remote is something that is hosted by a third party usually, like a YouTube video or a flicker image or slideshare slides or something like that, it doesn't physically live on the servers where your Drupal website lives, but you probably want to use this content in context of your site, which also means that you need to support the editorial process around them. Then with the weak embedding of media assets and cropping also came up. There were a few other things, but these items were probably the ones that almost everybody in the survey mentioned, and now three years or later, after talking to many people, after many discussions and issue queues and events and so on, it seems that these are still the most important. Maybe priorities change a little bit, but if we solve this we've done quite a good job for the beginning. So what we have in core right now, we're able to host local images, files, documents. We also added a multi-appload in the eight, which wasn't there in the seven. It's not entirely obvious. You can basically select more files when you click on this browse button or you can drag and drop more files to this little element. As I said, it works. It will upload them, all of them at once, and they will all appear in this table, but it's not obvious. It's not the usual, like, huge area where it says, drag your files here to upload them or something like that. So this improved a little bit, but the user experience is probably not the best. Then we have this files listing, like, very, very basic media library, but I would argue that this is not a media library. And back story of this listing is we were pretty late in the eight cycle already and we didn't improve much of media, and we got views in core, and we said we could at least build a view that lists all your files. So you have at least some kind of insight into that. You don't agree? And we built that view. This was something that was possible at that time, and we needed to use what views defined by default. Then we have embedding. We can embed images into Wizzweek in pure core itself. It supports aligning and captions, and it works very good. So this is one of the probably best improvements for the eight. But it's also limited just to images. You cannot embed a video, for example. And this is also one of the examples where core sets standard and then contrib was able to follow this standard, which is very important because I believe if core creates standards for us and we don't have to invent these very low level parts in contrib, we end up with much cleaner and much less fragmented ecosystem. Because if contrib starts to inventing very low level stuff, you get different solutions to start competing, and then for site builders or end users is confusing because they don't know which solutions to take and which one is better and what that means in long term, etc. Here, basically core set the standard how this embedded thing is stored in that body field, and we use more or less the same approach in contrib to extend this functionality to be able to embed much more than just images. And because we use the same approach, caption works in a similar way and the lining works in a similar way, we are able to rely on core to do that. So I think that this is very important. Then we have usage tracking. It's something that when we discuss media, it's often completely forgotten about. But the fact that we are tracking usage, and I don't think that some of our competitors do that, like I might be wrong because I'm not following all the process in all areas, but this is something that is hidden underneath the hood and it's very important for consistency of your content. And this has been in Drupal forever, but I just wanted to say that there are things in core that are good and maybe we forget about them a lot of times. So if we see which of the most important use cases we cover by core is uploading and using local media assets and with the weak embedding. I intentionally didn't cross the media library because as I said, I don't see that listing as a media library, but argue with me, please, if you want. And of course, there is a lot of work going on in Contrib. We've been working on this for two years now, actively. And the first thing is support for remote media. This is the media library from what is now becoming media module for D8. It was a summer of code project by Vijay, who is standing there at the back. It was initially developed on GitHub, but just recently in the last days, we pushed it to Drupal.org. It's not finished yet, but we have a dev release on Drupal.org, so it's easier to find. And yeah, in this library, you can have local, so-called local media, which are the blue boxes, and remote media, which are the red boxes. So we can support remote media in our trip. Then something that is very important when you start dealing with remote media is how you handle metadata. Usually, let's take an example of a YouTube video. On YouTube, you don't have just a video. You have title and tags and description and maybe thumbnails that YouTube can provide for you. And in the past, it was really, really hard to use this information in Drupal in a standardized way. Of course, you could code a custom module that would connect you with YouTube, and then you would be able to get this data. But as far as I know, there was no standardized way of connecting to many different services and exposing information that these services provide to your Drupal site. In contrary, we have this now. We through the plugin system, every remote or even local media type can say, these are the fields that I have available for you. And these are the fields that a tweet plugin makes available for you. And then you can access those fields in this data in a very standardized manner. Your developer experience is the same for every type that you are accessing. And there is also ability for you to define mapping. And when this item is saved, fields will be automatically populated. So in this case, we saved the tweet. We referenced it with the URL only. And then on the save, because of this mapping, other fields were stored as part of your entity. So you have access to the tweet author or tweet ID if you need it for any reason or a tweet count. And it works the same way for every type. Then we have libraries. This library that we saw is the one for media module. And because core doesn't provide any guidance here, we already have few different implementations of media library in core in contrib for D8. This is, for example, the file entity browser module, which uses Masonry library to do this grid. And it looks nice, but if we go back, it looks completely different in this one. And this is the area where I think core could do a lot to standardize things. And then, let's say we have a library in core that supports just images, for example, but sets visual standards. And modules in contrib that provide support for different asset types, like videos or slides or whatever, can follow that visual standard and represent their items in the same look and feel, if that makes sense. And this way we would probably avoid the situation when we have another media library in contrib. So this is from lightning distribution. They are doing a lot of great job. They're using all the modules that are in contrib and building on top of them, providing some glue code. So this is one of the best places. If you want to see how things currently work and what is possible, to check with them. You have lightning underscore media module that brings all the pieces together. And the friend of mine, this is kind of anecdote. A friend of mine said once that one of the Drupal media library solutions looked like Drupal with that mask that the evil character from Batman movie had. Drupal with that thing on the face. And it's getting a little bit better, but it still sometimes looks a little bit non-standard. And another thing that we have is so we have ability to have this nicer multi-upload and this is not the only thing that we have. We can do like multi-step workflows in contrib. Here we have the media library from file entity browser that we've seen earlier and we selected few images and those images appear here below like an intermediary selection and we can reorganize that. And then if we're not happy just with these assets here, we can upload a few more with using this multi-upload drop zone JS library and they appear again. We can reorder them again. And then when we're happy with the selection, we can tell Drupal to send it back to the file field, which is a nicer experience in my opinion than what we have in core currently. Then I showed you embedding for images. In contrib we have another embed tool that builds on top of it that can embed any entity. In this case, we are embedding an image but instead of being only to upload it like we have like the cases for core, we can select it from a media library. From the same media library have you seen in the previous video. And you're not limited to images. You can also embed nodes or commerce products or sometimes like everything that is an entity can be embedded. So this is kind of, it's an improvement both in user experience perspective because you can do like selection from the library and it's also improvement from the functionality perspective because we can embed much more than just in core. Then we also have cropping. These are two modules in implement cropping. This one is focal point which has this little cross here and you move that cross around and you basically say this is the part of the image that has the most information and then when crops are being generated, Drupal will make sure that that part of the image is always visible. Then we have standard crop where we have rectangle and we select the area that we want. So we have a lot of things from this list. We just don't have scaling and rotating images but I think that this is more from the initial upload perspective not from the perspective of image styles because right now how cropping works. We just save this information about the crop, the metadata and then when image styles are generated this is used to create correct crops for you. Some people would like to see something like mini photoshop when you upload the image and to be actually able to edit the original for whatever reason. So this is probably two different use cases and yeah, so that second use case we don't solve yet. The question was, I need to repeat the question because of the recording, the question was if this cropping information is saved per file or per usage of this file. It's saved per file, we were looking into options to be able to save it per usage and actually saving it is not that hard. The problem is that image style system doesn't have the concept of the usage of the image. So if you have a thumbnail image style you can have only one thumbnail derivative for a given image. So it doesn't make much sense to store it. And this is often, people often ask this question and require this feature but in order to support this we would need to improve or update how image styles work. So yeah, we have everything, let's go home, we don't need anything. Fortunately that's not the case. The first problem is that right now it's quite hard to put everything together. There is a lot of moving pieces involved, a lot of modules and you need some knowledge to be able to decide which of them you need and how to put them together. This aspect is getting better as we get modules like media that are basically doing this for you or lightning distribution and you can either use something as lightning or media module to build this or you can use it as an example, you can study how that works and then figure out which pieces don't work for you and what do you need to change. But we still have a lot of work to do in this area. The thing is that when we started working on that two years ago we needed to build this underlying subsystems and it took us some time to do that and we needed to rewrite some parts a few times and just recently, maybe a few months ago, we were ready to start building this solution modules on top of the whole underlying basis. That's also the reason why media module was a summer of code project this year and not maybe last year. Last year the pieces that media depends on weren't ready. Then we have inconsistent user experience a lot of times. I just think about the example of the media library. We're pretty early in the D8 life cycle and we can already see three completely different visual solutions in contrib. I wouldn't be surprised if there are more that I'm not aware of and we would definitely see even more of that. This is something where core could do a very important job to set the standard and tell contrib how to behave basically. Then we have some competing solutions which it's much better than it used to be but it's still a waste of resources so it might be worth seeing if we can address that. The whole ecosystem, it's not visible for first time evaluators. If somebody downloads Drupal core, installs it, you don't get any of those things that I showed for contrib. For those people that basically means Drupal can do that. This fact is probably also a little bit mitigated by the fact that if you are service provider and if you are demoing Drupal to prospective client, you probably don't use core for that. You probably use something, either a distribution, something that you've built in-house or maybe rely on lightning to do it. I think that this problem is not so big for clients that get in touch with service providers or with professional companies. It's more a problem for somebody that does it on its own. This might be a student looking for CMS to build a school newspaper website or maybe a CEO of a huge corporation or CTO, more probable probably, and both are important. I think that we need to improve the situation in core, if nothing else, to improve Drupal's reputation in this area but the question is how. I will propose a few things that I think would make sense to do and then we can discuss about that. So the first thing that I would do is would add support for remote media in core. Not necessarily supporting all different sorts of remote media. It would be, in my opinion, it would be enough to just have a similar experience that we have now with images and files, plus YouTube videos, for example, because this covers a majority of cases and it also shows, Drupal shows that it can do that and it sets pathways for a country to extend this with different types. It would be very nice for this to be compatible with what we have currently in contra, because if we don't do it that way then we left everyone behind. And this is the case, like for currently it's possible to build Drupal's websites in few different ways when it comes to media and we need to support, like there are basically two ways how you can do it and if we do something in core we should make sure that all these implementations still work. Yeah, so my suggestion, like I think that it would make sense to consider including media entity, which is the remote media solution in contrib in core. It has quite a good adoption, it is maintained, it already has a lot of plugins for a lot of video providers, for slides, for SoundCloud, for quite a big number of different sources. There is one problem though, I think that this couldn't be an experimental thing, like big pipies, because we're dealing with the data. You can have an experimental module that improves some UI part and if the way how you store your data in the database is the same, this really doesn't matter, you just enable it, swap it for the new one or the old one, everything still works for you, but if you change the way how data is stored then I think it's not responsible to say that this is experimental. If we give people tools we need to make sure that their data is safe. So this is a little bit of a disadvantage because it gives us less room to experiment and one way I think we could do it would be to at some point, at some minor release, like for example include media entity in core and then update the standard profile to start using it from that point on and don't migrate the sites that were implemented before that because I think that would create a lot of problems for people and since all the pieces that are in core that these sites are relying on are still there, stay there, are not going anywhere, these sites will continue working and all the contrib things that depend on that will continue to function and then maybe provide an optional upgrade path or migration for this kind of sites in contrib or as an experimental module, I don't know and then make sure that everything is migrated correctly for D9. So I wouldn't force, if we would do a change like that I wouldn't force all the existing website to adopt it I would just do it for sites that are being installed from there on. There is an issue for that if you want to get involved check this URL and I will tweet the slides and put them on the session page on conference website so you can get it from there. No need to take pictures with your phones. Then we have a media library. Assuming that we would do the first step this basically becomes just a view of those media entities. We have lots of examples in contrib as we've seen. We take the best what is in there right now, improve the UX, add features, more advanced filters and by doing that we set standards in core and then for example assuming that each item in this library is rendered as a full entity with a special view mode for like a library view mode then if you have modules in contrib that provide support for other media types these modules just need to provide same defaults for that view mode and then theoretically these media types that would be added later would nicely appear in the same library and we got consistent appearance and since this is core a lot more people see it it is quite probably that viewers experience would be much better in the first place. There is already an issue and there is some discussion going on in terms of prototypes and mocks. The media library prototype that you've seen at Riza's keynote is from that issue so if you are interested in this kind of things please check that especially if you are interested in UX and design this is perfect time to get involved in there. Then with the wig embedding the problem if we do the first step if we update the way how media is stored in core it means that by default they are not images anymore which means that embedding of images kind of conflicts with that so we need something more powerful if you would be to do that and we already have this entity embed module in contrib that allows you to embed any entity it comes with some dependencies with quite powerful display configuration of few plugin types it's quite complex but the basic underlying thing that is the meat of this module is basically the text filter that converts the embed tag into a rendered entity and I think that we could move that into the core and then we have support for embedding any entity in core so we solve that problem and we could make like a simpler feature set maybe just allowing people to select the view mode and then render the entity with the view mode instead of having ability to use field formators and custom plugins and a lot of other stuff like we have in contrib because this is where a lot of complexity is and if we do it in a way that allows us to extend this we can still rely on contrib on entity embed module to provide this advanced display configuration options while core could have the filter which is the most important part and simplified UI to select entities and to embed them in two ways. Just to repeat the comment was that it's important to allow timers to have full control over rendering of this embedded thing and I completely agree with you. That's an issue where hopefully discussion about this will emerge. Then we have reusability problem. Reuseability is mainly solved with entity browser module in contrib right now. Entity browser it's fairly new concept it was built for D8 and it's also fairly complex with a lot of plugins and I don't think it would be ready to be included in core at this point so what I think would be the best way for now is to create like simple listing that is based on the look and feel of that media library that we would hopefully have and allow people to use that to reuse things but with a bit limited feature set maybe just having a list of media entities where you can pick something from would be enough even without filters it would be way better than what we have now and then either incrementally improve this in core or rely on contrib to extend it for more complex use cases and maybe see later maybe for D9 if something like entity browser could end up in core so we would have more flexibility there. And with this approach we would cover most of this use cases in core itself maybe not with the full feature set but like if we provide something basic for people that are evaluating Drupal is definitely way better than what we have now. The only thing that we completely left out is cropping which we could discuss about but I think that this is already more than enough work for some time. Another advantage of this proposal is that it heavily relies on stuff that is already in contrib so we are not re-implementing everything from scratch but using things that exist already and just improve them and that saves us a lot of time and a lot of energy but we still need people, mostly people and also money. I think that it's not realistic to expect that a group of volunteers will pop up and do this because it's a huge job and people have lives. One way we could do this and this has been proven to be very successful in the past is dedicated week long focused sprints. We've done this attempt systems two times for just media itself. We usually have sprints like that in New York at New York camp. The latest example was a sprint that happened after this year's nice camp and we basically rented an Airbnb and we're there for a week and we're sleeping there and eating in restaurants around the block and we were able and at some point it was just two of us. We started with four people and then three people and then at the end we were just two but we pushed forward things that were stuck in the issue queue for months and if we would be able to do this with a little bit bigger group more often then achieving these goals I think it's not that unrealistic that it sounds. It's nice to have sprints on events like this because you can get new contributors but it's extremely hard to focus. On events like Drupalcons we had a lot of interesting discussions in the past, a lot of interesting decisions but not much actual features came out of those sprints. While on these focused sprints where we were isolated from all the distractions results were much better and in order to do that we basically need some money not much to rent a place like that to fly people there and to provide some food and either ability to pay people to camp there but even better if their employers would say okay this is our sponsorship towards the community, towards the initiative. I will send my senior developer ex there for a week and leave him out of the daily stuff as much as I can to be able to focus on this and if we would do a few sprints like that per minor release cycle I think we could move mountains. Question. Yeah the question was if that could be combined with any event sure it can be but from my experience if it's part of the event if it happens at the same time as event is happening there is so many interesting things going on at the same time that people won't be able to focus. Like in New York we didn't do it on the actual days of the camp but we did it afterwards. After the camp for a week we stayed there and we were able to focus much much more than we would be able as part of the camp. Yeah it's definitely better but it's still a lot of people. It's pretty very general event it's very easy to be pulled out of this and into something else where discussions are happening and stuff like that so I think that if we can have something that is really focused it's much more productive. So we are dedicated to help. As I already mentioned we are striving we're trying to invest roughly 20% of every project that we have back into the community and MD Systems has been one of the major supporters of the media initiative in the past and something like this would be happening. We're definitely part of it. This is obligatory slide. Come to sprints. If you are a first time sprinter that's the room you should be in and you have mentored core sprint another room and general sprints if you know what you want to do or if you join us come to general sprints. You have to you don't have to. We would kindly ask you to evaluate this session all sessions actually that you attend because this helps me and the conference organizers to be better next time. And now it's time for the conversation part of core conversation. Any comments? Any ideas? Thoughts? Can you go to the microphone please? So what's the current state of things? What's done by that moment? Are you referring to core or triple ecosystem entirely? Do you have your own starting modules that you want to put in core or it is based on a country module that currently? I'm not sure if I understand the question. I mean do you have your own development already started? So the question is if the development already started. Development has been going on in Contrip for two years now and you have a lot of things in Contrip already. Some of them with stable releases, most of them with at least beta releases and all of these modules are already used on many sites. So this is not something completely new that is being invented right now but it's rather like trying to improve that and move parts of the existing things into core where it makes sense and where it's possible. Did I answer your question? Which part I didn't answer. So you kind of go on a lead on this, right, your company? I wouldn't say that. Many companies have been part and many individuals have been part of this initiative in the last few years. We are one of them of course but many people invested into this in the past and it's not something that is like our thing that we want to promote into the community but it's something that has been going on in the community in a very open way for a long time now and we have been part of it. That issue was created recently, I think I created it last week. So the comment question was that issue about remote media doesn't have any comments and it was created based on my preparations for this conversation and we have a few more discussions planned for this week and hopefully we will see what the ideas, conclusions about this are this week. Yes. So the question was if this what we're talking about here is support, it should work with the workflow, the tools that workflow initiative is working on and moving into core or some pieces already are in the core. And the example that you gave was the embedding. So if I understood correctly if there could be problems if you embed something into with the week and then use the module to deploy this to some other instance. We try to do everything to be as standard as possible. We have standard entity types and for example for embedding we are not embedding the rendered version of the entity that is being embedded, we just store the reference in a special custom tag and to store that reference we use UID, we don't use the entity ID. And the main reason for that was to support cases like that, disclaimer I personally never tried that but in theory it should work. And it didn't initially work but we were on that and got that fixed so now whether that will go into the core part of the workflow I'm not sure because that was a contrib module supporting another contrib module. So if it's not in core it can't be moved into core so it's a chance that you'll probably still have to use some of the contrib stuff within the workflow but along answer yes it works. The answer from the audience was that it basically works. So the question is about fire visioning and if that is the scope. I think that it is a scope. I believe that revisions in media entity should work and I'm not sure what the state is in file entity now. With file entity which is a module in contrib that extends core files it doesn't work. And the main issue as far as I understand is that yes if you have a file as a full featured entity with fields and everything it's easy to revision fields but how do you revision file itself? Do we store multiple copies of this file on the disk or yes so the main issue is how to solve this revisioning of the file itself and I don't have answer to that sorry. The answer from the audience core has a new critical bug is this I guess since yesterday exactly because of this problem where files can be deleted where we don't want them to be deleted and we will stop deleting files when they are unused by default while still allowing people to enable that if they need. The question was that it seems the comment and the question was that it seems that the biggest pain in the but is the part where we transition from files to media entities and the question was if media entities are built on top of file entities. The answer is basically yes because for local media media entity has a file field on it and this is how it references the file how it brings the file into the media entity. It's not depending on file entity because it doesn't need it to do that it just needs what is in core but yeah that's why I also said that all the pieces that are currently in core are not conflicting and should stay in core if we end up doing that. And for remote media it's doing it in a completely different way. Mostly by referencing links to by storing links or embed codes to that remote media and have some logic to be able to parse that and to identify correct IDs etc. The question is what we do with current UIs in core if we do that. You cannot use current field types with the media entity because image field and file field are limited just to file so you need to use something else which probably the answer is entity reference and I would say like my initial idea is to create a different widget for entity reference with possibly similar user experience to the one that we have now. So this would hide the complexity significantly while still relying on this new thing for the underlying part. That could be one solution because at the end of the day no matter if you have a file or a media entity when you upload files it's just uploading the file and creating an entity out of it. We're also doing this now. File is an entity in core already so it's not that important what kind of entity. Who was first? Back there was first, sorry. So the question was if I could talk about how to avoid the same problems that media module had in 7 which is trying to do too much in one bag and the answer is that we this is the first problem that we're trying to address two years ago where we had this initial discussion about how this ecosystem will look for D8 and our solution to that was instead of having one huge module that does everything to separate into smaller pieces that live independently in contrib and then a module like media depends on them and provides default configuration and that's what is basically happening right now. This approach introduced a new problem that is like a lot of hidden things a lot of knowledge that you need to be actually able to build things but I think if we provide same defaults nice default modules that build things for you then we've solved this problem. Another problem that media had in this 7 was the fact that it was unstable for basically the entire cycle and at least for this underlying basic parts in contrib we don't have any problem because all of them except entity browser are already beta which means everything should be backward compatible and even with entity browser there are no changes planned that would break backward compatibility it's just more the fact that there are some quite complex bugs and we would like to fix them before we dedicate to that. There are a few more questions but I think that our time is up but I'm happy to continue chatting in front of the room. Thank you everyone for coming and hope to see you soon.