 Okay, let's get started. We're talking today about UPOL. All right, great. UPOL is a project that I started maybe six months ago as a proof of concept for what changes we might want to make in Drupal Core for Drupal 8 for testing, okay? The test framework? Oh, I see what you're saying. Yeah, clever. Yes. Pretty good. Okay, so on the left-hand side here, we have our current simple test framework and specifically the flow that it does in order to run its tests, okay? This is the simple test module is the test runner. At least that's what I like to think of it as, okay? And it goes through and finds all of the test cases and runs a setup method. The setup method sets up a whole new Drupal, okay? Usually sets up a whole new Drupal and the test methods run inside of this child Drupal, okay? After that, there's a teardown and rinse and repeat until all of the specified classes are tested, all right? On the right-hand side, you have a simpler flow for testing, which is to say that you run the command line PHP unit program. That's another open source project for people who don't know, super popular in the PHP community as a test runner, okay? That discovers all of the test classes that are in the directory you've pointed to or otherwise fed it and those test classes are then run against your Drupal instance. So the SUT here stands for System Under Test, all right? So one of the key advantages of UPAL is to get rid of what I think is a fatal confusion inside of the current simple test system, which is that there are two different Drupals going on when you're running your simple test, okay? There is the host Drupal, which you are logged into. You have administer simple test permissions, okay? You click a button in the web GUI and it goes ahead and runs your test, right? Then there's the system under test, which simple test basically builds up an environment for you and runs tests in there. And simple test does Herculean efforts to make sure that there's no leakage between the host Drupal and the system under test. But if you've been watching the issue queues for the last few years, we continue to struggle with that leakage, okay? And so the model on the right hand side, there is only one Drupal. There is no host or system under test and confusion and leakage. There is just Drupal. That's what's getting tested. And there's PHP unit. And there can be no confusion about, you know, I'm actually in the test, but I've already loaded a file and PHP is getting confused between the two Drupals. No, there's only one Drupal, all right? So I think that's a really strong improvement. You know, for the folks out there who've tried to debug simple tests, this is one of the things that's absolutely killer is that there's two different Drupals. In fact, when you're inside a test, sometimes there's like more layers of confusion. There's requests that are calling back in a Drupal. But for now, we're going from two Drupals to one, okay? So I've already started talking about some of the advantages that I think the UPAL system gives us, okay? Skipping down to the third bullet, PHP unit is a hugely popular project. You know, the simple test module was actually started by me and so I take full responsibility for it, but it really has grown in a way that I'm no longer that comfortable with it. It started off as a, we used the simple test project, which is a great open source project, but since then we've really made it into our own specialized thing, and particularly our own specialized thing that does this host Drupal system under test thing, all right? We made that decision. It was, I think, a good decision at the time when we were adding unit tests and a testing framework. We really struggled with, is anyone going to pay attention and care, you know, to the tests we're there, that we need to write. We need to write thousands of tests. And it was decided that we had to have a web GUI for running tests. It had to ship with Drupal. The runner had to ship with Drupal. The test had to ship with Drupal. And it had to be super easy for developers to see what we were doing in the simple test module. I think, you know, everyone would say that's been a huge success. When you run the unit test suite, there's 40,000 assertions or whatever there are. There's just an amazing suite of tests that we've built. But I think that we can now, you know, preserve all of those tests and just change the test runner. So that's what PHP unit does, okay? One of the objections that comes up when I talk about UPAL is that, hey, this web GUI that you find at admin slash something simple test. You know, people use that. People like that. And they're the way most people use PHP units from the command line, all right? There is a visual PHP unit open source project. This is a screenshot from that. So for folks who want to run unit tests from the GUI, that's still an option, okay? We don't, we can still have GUI unit tests and not ship with our own UI, all right? I think that's much more healthy for us to drop the UI from Drupal, rely on this project, and take advantage of the huge PHP unit ecosystem. So when you start using PHP unit as your test runner, you get to take advantage of lots of stuff that's going on in the PHP community. So these are two screenshots from two IDEs that are quite popular. It's NetBeans and Eclipse. I know that the same capabilities are in PHP Storm and Comodo. So, you know, by taking on PHP unit, we automatically get IDE integration, which is a really huge step for us, I think. And, you know, we should be excited about that. There are, I guess over here, I was saying that when you adopt PHP unit, it comes with code coverage calculation, okay? So when you run your tests, you know what lines are being tested and what ones aren't, all right? That's harder to do with our browser-based tests. It's automatic with our unit-based tests, but in any case, you know, we're further along in code coverage calculation when we adopt PHP unit. Things like Jenkins plugins, you know, JUnit XML, that comes for free when you adopt PHP unit, all right? All right, so I'll talk a little bit about how UPAL works. UPAL basically preserves everything that is in Drupal Web Test Case and Drupal Unit Test Case, all right? So I basically copied all of that code into a new project, UPAL project, and changed the setup and teardown methods so we don't actually set up a new Drupal site in setup. We just test the Drupal site that, using the code base that we have right there, and set up a new, you know, run and install if we have to, all right? The tests that live in all the module directories are completely unchanged, okay? So the idea of UPAL right now is that it's a drop-in replacement and all of our tests continue to run, all right? And the final big win is that we delete the simple test module. You know, if this finally gets into Drupal 8, that would be part of the patch, is to remove everything that you find in simple test module because what that module is about is about the test runner, and we're replacing that with PHP Unit. So the web GUI goes away. It, you know, it has a bunch of tests to test itself. It's got API. It's got a whole bunch of things. We get rid of all of that, okay? So that's really the end of the UPAL part of the talk, all right? So just to summarize, the idea is to replace the current test runner with PHP Unit, all right? I want to talk a little bit about the tests themselves, and at least start a conversation about where we can go with the tests. There are two really interesting PHP projects that we might want to take a look at. One is called Bahat, and the other one's called Mink, all right? I hope I'm saying Bahat right. Anyone say yes or no? All right, let's go with that. Bahat, Bahat, don't know. Mink is like a, Mink is a browser, essentially a programmatic browser, so it's analogous to the browser that's in simple test now, where you tell it go to this URL, click this link, fill out this form field, etc. These are just two projects that are based on Symphony that we would have to use. All right, so let's look at what a Bahat test looks like. Let's go to here. All right, so this looks quite different from our current unit tests. The tests are written in completely readable English, okay? So this takes a while to wrap your mind around it, but I think it's actually quite a step forward. So this is the blog feature. This is an excerpt from some tests that we maintain at Aquia for Drupal Commons. We actually use, we don't use Bahat, we use this Ruby-based system called Cucumber, which is the same thing, but in Ruby, all right? And the language that the tests in actually are shared between Cucumber and Bahat. So here we're testing the blog feature of Drupal Commons. You can think of this as testing the erstwhile blog feature in Drupal 8, okay? We have some setup-type stuff that has to happen at the beginning of the test. That's that background section. So, you know, written in English, given a fresh Drupal Commons installation, given a username Derpington with a password, ZomaiGod barbecue, you know, login and join an organic group, okay? That's the setup for this particular test. And then we actually have the tests themselves, all right? The tests themselves are called scenarios, all right? There can be one or more scenarios in a file like this. This is called a feature file in Bahat, all right? So it's a lot like what you're used to when you write tests. They have setup methods, they have a bunch of test methods. It's the same thing here, they're just written in English, okay? I will show you in a minute how the English gets translated into something that a computer can actually do, all right? If we look at the scenario outline, we see that we're going to create a blog entry with a certain title text and a certain body text. You can see that there's placeholders for title text and body text here. And the test says go ahead and submit that blog entry and then it has some assertions. I should see a blog entry with certain body and title in it, okay? This example section down below is just a nicely readable table of data that you're going to feed into the scenario, all right? So you just loop over the data set and run the scenario twice in this case. Here's the title text column, here's the body text column, there's two rows, okay? So this is a real test from our test suite. So let's go ahead and look at it. Okay, so stuff, each line in a Bahat-based test is called a step, okay? And what you have to do is write some code in order to be able to tell Bahat what the English means and where the function is that does it, okay? So here's a bunch of files, there's a directory called step definitions and if you look at a step definition, this is what one looks like, okay? So this is a step definition for, I have joined the default group, all right? We need an organic group in this case, all right? So this is actually a regular expression up here and that is how Bahat figures out what the English means and where the function is that's supposed to do it, okay? There's not magic here, there's just regular expressions. The good news is that you very rarely have to ever write the regular expression. Bahat actually hands you these, so you write your English first, your feature and then you run it and Bahat says, oh, you haven't actually created step definitions for these. Here is a shell of what you're going to need, all right? So let me show you how that works. Correct, it's a good clarification. So, you know, for UPOL, you don't have to adopt any of this stuff as a separate part of, you know, I get a chance to talk to great core developers. Here's something I think would be good for the project, all right? So, but this is really kind of separate from UPOL. And how am I doing on time here? 15, good. All right, well, you know, we've put in our own code here, which is to say visit this URL. So you can see that it's the MINC project that understands what visit means. It means navigate with your programmatic browser to go somewhere and click button, all right? So, go to the terminal. Let's see if we can make this bigger for you guys. Scroll down, way down. Okay, so here I am in a small project. This is actually, if you go to the Bahat website, they have some great docs and a great quick start guide. So I have, I'm halfway through the quick start guide at this point. I have written my English based test. And now I'm going to run Bahat for the first time. So I run the command line program called Bahat. It looks at my English feature or all the feature files that are in the directory. And this is what it sells me. It says that I have two scenarios defined. I have declared them, but they're not implemented yet. He doesn't know what any of the step definitions are that are in them. This is actually the feature file that we just ran. So the thing we're testing is the LS program. And there's some background information and two scenarios here that everyone can kind of relate to that it tests the LS actually enumerates all the files in the directory. Okay? So here are all the step definitions that need to be defined. All right? And what I wanted to really show you was that Bahat will just give you these regular expressions right here and shell functions that you paste into your file and you just start replacing with a little bit of code where it says throw new pending exception. That's where you actually implement your step definition, okay? So if we look at what like a larger test suite would look like with Bahat, this is the Drupal Commons test suite that Acquia maintains. You will see some Ruby in here. Clearly the Drupal project would write in PHP, not in Ruby, but all the principles remain. It's a bunch of features all these files over here. Those are dot feature files. That's where your tests are written, your English based test, a directory of step definitions, okay? And some support files that are kind of shared code that you might need within your tests. That's really all there is to it. The Bahat command line program does a really good job of giving you enumerations of all your step definitions. So you can, as a test author, you can kind of see what English actions are available to you. So you figure out how to write, I need a new user, I need a user that's logged in and then you can kind of go through with your test. So the reason for this, so some people have an initial objection to Bahat and Cucumber because there's a layer of indirection there between the English and the code. And extra layers are bad, you know, fully in agreement there. But I think that the benefits you get are more important than the indirection, right? The benefits you get are that anyone in the community can spec out a new feature, okay? The way they spec out a new feature is to write that English based test. That is a very clear way that anyone can say, this is what a activity stream should look like in Drupal Core. And once it passes all of these tests, you have a very clear agreement that it does what the requirements were set out. Maintaining these tests is going to be a lot easier. A lot of that work can be done by anyone because they're written in English. Bahat actually supports other languages but I think we'd probably write our tests in English. And so I think it's just more inclusive to have testing opened up to all these other people. Yes, we'll still need developers to implement step definitions and change them from time to time. But I'm pretty excited about opening up the simple tests and the testing community bigger. All right, so that's it for my pitch about UPOL and Bahat. I guess we have some time for conversation here. Then we're going to start media. All right, five minutes for conversation. Great. Go up to the microphone, please. So with this approach, are you proposing that any new features for Drupal Core start with writing a test first before writing code? So I don't think that there's really a way to enforce that. Whenever code usually shows up for Drupal in the issue queue as a patch, the patch will have a test and it will have the functionality. So it's never quite clear if the person did test-driven development or not. In fact, it does not matter. So I'd say whatever people find comfortable, they can do it that way. Okay. And on the topic of sort of twice as much in terms of the English version and then all the actual steps, if we count comments as lines of code, we might not have double the amount of code because I think for just about every test, there's an English comment explaining what it does and this seems like that just split apart slightly differently. That's a great way to think of it. I hadn't thought of it that way. That's awesome. Hi. So taking a step back to the architecture of UPOL, being the author of the deploy module, we're actually using the current simple test setup in a very interesting way because we're setting up actually two sites, communicating with each other, deploying content between them. There's a lot of black magic with sort of headers and things like that in request between them. Would there be any way in UPOL to actually set up two sites to test them and communicate with them? Because now it's only one site that is running. Yeah, true. But I think that in your test, you could set up an additional one. You basically would do another multi-site with the same code base and do a setup of Drupal. Yeah. Okay, cool. Yeah. Very excited about the concept of using a cucumber-like test framework. I was actually really curious too if there's any maybe tangible examples from perhaps Aquia or maybe another organization that uses probably like an agile or scrum method to generate those stories, particularly from a managerial standpoint, because it seems like if you have that, the tight coupling you're trying to do in the Drupal organization is clearly a tight coupling that's practiced elsewhere. And I imagine that there's probably something we could learn from there. I know that there are other organizations using behavior-driven development. That's what, that's kind of the category that we're talking about, BDD. I know that Damian from Commerce Guys is really big on the hot and mink and thinks that's a great direction for us. So maybe Commerce Guys is using it. I'm not quite sure who's using it. But the idea definitely is that simple test is hard to use outside of Drupal core development. I think we can really make our test suite much more useful for our own client projects and so forth. It's definitely a question out of the hot. So I've kind of seen projects like this before. The problem I've seen happen is that all the permutations you can do with steps and all the permutations that the underlying code actually supports is different. So I wonder if you had any insight on that. The problem, can you say it one more time? You think, okay, I just need to do this test case. I just need to take these pre-existing steps and then create a new permutation. But then you find, oh, when I put these steps in this order now, like there's something a bug in the underlying code and maybe those other permutations that works. But now you do a different permutation. You think, oh, I have to change the steps and all of a sudden you realize back said, oops, I have to change the code or, oh, the code supports these steps in this order, but not in that order. Right. I mean, I think that steps are shared code across the whole project. And so anytime you have shared code, you have to treat it gently and treat it with love. And it's very much about making these steps generic so they can service as many test scenarios as possible. We have the same sort of thing now in Drupal web test case.php. We have create node and Drupal log in and log out. That's all shared code that we maintain and we have to change it carefully. So I think it's the same sort of problem that we've been dealing with is what you're describing. I was curious if you put any thought into how we would manage the mapping of the steps to the natural language and avoid the kind of duplication of the steps in the Drupal.org infrastructure. And my second question was more like, I do the LDAP module and I have to make a lot of fake server code. And I was wondering if the PHP unit project, if it had in that project, if there was a lot of mock servers that were being generated for different outside externalities. Sure. Yeah. Great question. The second part first, PHP unit has mock objects. And we will definitely start using those. Simple test doesn't have that. So this is the kinds of things you get for free when you go with the leading test runner. It has a terrific manual with lots of examples and comments. So it's quite easy to get started with that. For people who want to get more experience with PHP unit, there's also the Drush unit tests are all built on PHP unit. And so people who love Drush can start helping out there. The first part of your question was harder. What was it about? With the mapping of the natural language and the steps, how do you avoid duplication of the steps? I think it's similar to the last question of like, it's shared code. People have to be aware of all the step definitions that are available to them. They need to try to not duplicate when there's a slight variance from what's there. We are pretty good at coding standards. We will need sort of English standards for how we write these steps. I think this is the sort of stuff that we do and we're pretty good at. So that's all for my time, but I want to keep going with this conversation. So please find me and talk amongst yourselves and let's get a little momentum for this stuff for Drupal A here. We're good? Okay. Hi there everyone. My name is Dave Reed and I am a senior engineer at Palantir.net and fairly recently become one of the co-maintenors of the media module for Drupal and kind of gotten myself into a nice big nasty mess with that too. So this is just kind of my conversation on kind of what we've been doing because we've done something kind of unofficial. Kind of just let you know about that and also kind of show what the things we want to do to improve media handling in Drupal 8 and kind of my idea and we'll see how it fits with your idea or if you just like it. So we have this unofficial official media initiative. We decided we wanted to do this as media maintainers last September as just kind of a imitation of the core initiative modeled. We wanted to promote and kind of form our own group around the media module and contrib and all of the modules that implement with it too and kind of help support and provide you know help and grief support for people that have been working with it. So of course one of the things we did first is we have a now kind of official roadmap for the module which we didn't really have before which kind of helps get people involved and you know because they can see oh what's being worked on maybe I can help contribute to that and of course this is a community roadmap too. It's not like AQUIA is deciding this. It's not like Palantir is deciding this. This is a community agreed on roadmap and I'm kind of like the unofficial official lead of this initiative and I'm kind of taking a benevolent decider role but I'm not trying to push my own agenda with this. So it's a community roadmap. We also now have a bug squad going with Thomas Venson who's here which is awesome that that model was started by views because we totally needed it for media too and it's already really started to help. I would encourage it if you have a big module too so it's a good way to get new people involved as well with the module. Like the core initiatives we're also having bi-weekly meetings in IRC. They're on Thursdays about 2 p.m. central time or 3 p.m. central time. We post on our groups page when they are and I would encourage you to join and like I said it's just those meetings are also to help encourage new contributors, decide on a roadmap, talk about what we're working on that kind of thing and this initiative is also kind of our commitment as maintainers of the module that yes we're going to be here we're going to listen to issues. We're going to be responsive and not kind of trying to disappear on you and it's also kind of a good commitment for the community too because that way they're not going to be like well is Palantir going to like stop working with media and abandon it and no one's going to be working on it anymore should I keep using media. So it's kind of our way of saying yes this is a community led project it's going to continue we want to have momentum into it. But so one of the things we were starting to do kind of now that Dries has announced a feature freeze for Drupal 8 is we kind of need to start looking at core and how we can you know do we want to move media into core what's kind of a plan with that and what we can do. So to first we need to cover some bad assumptions that core has with media management and files and I'm sorry that I'm going to have to bring these up but I hate them. Core has some bad assumptions that files are always local and writable. If you have a read only file stream you can't do image style derivatives of them because it's hard coded that you have to be able to write to that image style to that stream wrapper. I can't have a remote just loading from HTTP and say I want to put my image derivatives in the public file system. It's difficult. The concept of file extensions does not apply to remote files. In a file field you have that little field of allowed file extensions what do you put there if someone wants to put a YouTube video or a Vimeo you can't. So we're trying to work with this concept of MIME types in media so we have a MIME type of video slash YouTube but it's kind of hard because we have to also deal with this assumption that we're working with file extensions in core and we don't really have a good solution on how to resolve that yet. And my favorite function file delete oh god it's my favorite function in the world because I've got some code for it later. It doesn't actually delete a file. It does validation twice three times. It has to it's checks to see if the file has a valid URI. It checks to see if the file is used anywhere and it checks to see if file unmanaged delete actually succeeded and if either of those cases fail the file it fails. I can't just call file delete it's really frustrating. Another really big assumption is that files will never be reused and this is killer for media. We have a file usage system in core that if you upload a file and put it on a node and then you remove that file and save your node that file gets deleted and you can no longer reuse it you have to reupload it and just sucks for a media library concept and I've looked at other systems too WordPress does not care at all it'll just leave all those files in there for you because it has a media library and it's just it's really frustrating deal with this file usage system and another fun one is image dimensions there was an issue put into Drupal 7 core that we wanted to include in image dimensions when you output an image that data is attached to field data so if you reuse that image twice you've now made that those image dimensions redundant you're storing them in two different places now and we could just store them related to the file ID but we didn't and I'm kicking myself that I didn't like I actually did proposing that issue I was like why don't we just associate it with the file record and I kind of got ignored and I didn't push on it and I'm kicking myself and it's just we're just duplicating data that we could reuse because this is causing a performance issue now in media and the fun thing is that the file usage system assumes that it's always accurate and correct but it doesn't handle revisions in core so if you add a file in one revision and then remove it and switch it to a different file again that first file gets deleted you can't revert to that old revision and keep the file it's gone sucks and we also have the concept of media that puts files we embedded via WYSIWYG and we have to make sure that we we're tracking it and it's really fun code like parse the text value of the text field searching for and regexing for our file ID string and then have to add it to the filter usage system it's fun and there's also kind of a weird thing with image field it's kind of a special case of file field and we've had to have deal with some assumptions because it includes different field data like the dimensions and alternate text and how would we support that media because we changed the widget completely so here let's go so it's some easy wins for Drupal 7 or Drupal 8 we can do these these are really fairly simple in the grand scheme of things and you can actually find like these issues because they're tagged with media initiative in the core queue so the first thing is that we're converting our entities to actual classes in Drupal 8 and we're kind of stuck a little bit with the file entity so we need help porting that to a real class and there's an issue for that fix file delete to do what it actually should do because yeah here's this is like in file delete why are we doing this we should not care if it's a valid uri we don't care and then it has you know it checks usage and if that file unmanaged delete function fails we return false it's just uh frustrating and we need to also stop storing the file entity object in the field data so when you have a file field and you reference a file in the node object for like a node reference field you just see a node id in the node object if you for a node reference field or a user reference field you just have a user id that's stored in the node for a file or image field you get the whole damn file and image entity stored in there so if you change something on that file entity that node that's been cached is now invalid it's frustrating um and one thing that would be nice is we could add a kind of a base remote stream wrapper uh for read only stuff so that it'd be easy easy for other people to extend core only includes a local stream wrapper but it'd be nice to have a remote one too because it's just it'd be easier to extend that way um and along with that we want to make sure that we want to have image styles to be controlled based on the scheme that's being used so we could have an amazon stream wrapper say i want to store my image styles uh on my amazon system or a http stream wrapper says i want to store my image styles in the public file system because i can't really go and save it onto someone else's website that's just not going to work so that's just kind of an easy win uh and another one that would just be really nice to have for core and would be really great is be able to support html5 audio and video tags that'd be a huge win because we work for images but you want to do audio or video okay you have to install two different modules um so we've got some all like different solutions we've got media element to consider as an external library that could do that popcorn.js uh which i just learned about like an hour ago uh could possibly do that and travis tidwell has been working on a media element he told me about that one um so that would be a nice easy win too um so here we get the not easy stuff this stuff is not oof um so the one thing we'd really like to do is make files fieldable in core and basically right now what we're doing in contrib is we have this module called file entity that it's its own separate project now that basically enables you to put fields on files it gives you a whole ui for administering a list of all the files that have been uploaded on your site just like the content screen you can see them all it'll show the file type you can hit edit or delete um you can edit the fields on those on an individual file you have file types where you can add the fields and manage their display it's a lot of work and it's kind of an odd concept um and we want to it'd be one of the things we need to put into core um because the concept of having fields on files is what we want um but we also have a lot of work to do in the file entity module still um it's not quite finished yet um it doesn't have a lot of tests it doesn't have any tests uh which is bad um and we also need a usability review which we're working on um but like configuring the way that different file types are displayed is really really really hard for users um and we also currently in the module there's different file types there's application audio image video which are currently tied to the common mime types the first part of the mime type um but probably we're going to want users that should be able to define their own file types it's like a document file type for pdfs and microsoft office and those types of files they should be able to edit those and currently you can't so we need to figure that how that works uh and we also want to put in a file access api uh which would be really nice because it would replace like hook file download and stuff so you could actually just call file access operation file object and the account for which it's going to happen it makes more sense than what's going on in core now it'd be nice if we had an entity access api in core for triple eight i'm not sure if it's going to happen or not but we're proceeding with what works for us right now so and we also need to resolve what's the difference between field data and the stuff that's in the fields themselves like alternate text on image fields should that be data on the field or should that be a field on the file and it's of course like a tongue twister and massively confusing i don't know what's right what's right maybe we'll talk about it after um and the last part is we you know eventually we want to put the media browser in the core you know the whole UI aspect but there's going to be a few things that i want to do first uh it needs usability testing and again we're working on this we're getting some aquia usability engineers involved and we're doing some formal testing soon uh we're getting it going because it's just it's still a little confusing doesn't work quite the way people expect um we have a ways to go um and we do have file on image fields in core right now so it's not like there is a massive gaping hole in core media management that we need to rush our work in i i like to take the approach of get it right and contrib and then move it into core uh angie's gonna differ with me on that she's just gonna be like we want it in now we can refine it and i don't like that method so we'll figure it out um we need views uh we went through a big transition in the media browser because we had all this custom code written for listing and displaying all the files and you couldn't filter it you couldn't change it and we put in a big conversion to views for this and i don't want to regress if we put it into core so we need views and that's kind of a big issue and we also need a good modal api in core um because currently our modal is pretty hard coded it has lots of bad assumptions uh it's not it's not the most easy to understand javascript it has some bugs that edge cases it's just it nice be able to to be able to reuse what core has and there's not really anything right now but and a few things that would be nice to have uh it'd be nice to have an entity reference field in core uh and it would get rid of the use of file or image fields and kind of deprecate them and it'd also be nice to have a way to like select existing things for this entity reference because what we're doing with the media browser and being able to select existing things is not unique i mean no reference wants that too user reference wants that too like we don't want to be solving this for our own selves we want to have a solution that's good for other people to use but you know we also maybe need just a media browser because it has a special case so um another thing that would be nice is if we could if you have an entity reference field uh so say you're embedding you're referencing a node but you want to change the title for when that node is linked on another node you can't really do that and that's kind of what we're doing with image fields right now in alternate text we're just you're referencing a file and changing the way the alternate text is displayed um so maybe this kind of concept would be useful for core too and nice to have so the i mean the overall theme is we're not like completely ready yet we're i'm going to be the first to admit that there's a lot of downfalls for media right now sure it's really great for you know a majority use case but once you start getting into it it takes a lot of work it starts to become unusable and gets really frustrating and so we'd really like to take you know get more polish and contrib um but still kind of work on those easy wins for now those are definitely things that we're targeting now for triple eight and we know that we can do um so i mean we're having a sprint planning boff uh this afternoon and we're going to be having a full day sprint on friday so if anyone is interested in helping with media uh definitely come talk to me come to the boff come on friday because we're probably going to be working on those easy win issues um and hopefully get a lot of patches generated for those um and that's really all i have so now i just really love to hear from you questions uh concerns what you'd like to see so hi um i was just wondering um if you have a media browser um would it be better to be listing the the file entities that are in the database rather than looking on disc that's what it's doing right now yeah okay yep thanks first uh two quick questions um if i magically applied all the magic patches to media two could i use it now yes it's totally usable right now okay um so the secret is that i'm actually using media 2x it's in unstable right now um in contrib but i'm actually using it on several production sites and several other people are too so i'm kind of on the hook if something bad goes wrong and i will fix it right away um so yeah it's it's pretty safe to use you just i want to stress that you need to have engineers to support it in case something goes wrong uh you just can't have the assumption that you can use it and go the second question is um as someone who's trying to work on cleaning up the css and java script with the overlay module could you just send me a list of everything you want done to make it the awesome modal you you have always dreamed of well i mean that's kind of actually something that i'm a little concerned about because most of the time the node form is opened in overlay we want an overlay on top of overlay i mean i have a module that does that it's called inception um but it's not it's it's it's a joke so we we need something that we need a way to be able to do that modal the media browser window on top of overlay as well so that's kind of what i'm talking about there so i i want to use overlay but i don't think it's going to be able to to use that yes so i'm probably to blame for the file usage stuff but i kind of think you're misunderstanding okay that it's supposed to work um i mean a lot of the overhead and file delete is there because um think about how it fails right if you can't actually delete the file and it's like a two gig file do you really want that hanging out on the on the disk if it's not in the database i mean there's there's there's kind of a lot of reasons for some of that they're not always great um and then as far as the usage stuff i mean the way the idea with the usage was that it you could you could write a media library module that just stuck usage on everything so that it doesn't actually get deleted and then you could you know kind of develop your criteria for which ones go into that media browser but then you know they could be held on to and then you don't have to worry about some control module deleting the file up from under you so i i think some of the stuff is there it's just figuring out how to get get it right yeah with file delete i uh talking about if what if a actual file delete operation failed you wouldn't want to remove it from the database um and i say i wish it would throw exceptions like node save does or no delete does um instead because we could handle it then um and for file usage there's actually a module that does that right now it's called file lock and it basically automatically adds just an empty usage uh for automatically for every file or for every pattern of a file name or that kind of thing um i'd rather just get rid of the usage system and make it optional and and like move it to contrib because i just rather not care because if we have an api a ui for deleting files users can do it themselves right well i think once files are actually like a proper entity but like that was one of the things where we didn't have any kind of a management system that was presented to the user so you know like yeah how do you ensure that it sticks around long enough but can get cleaned up and so yeah yeah it's it's tough because i mean it's the assumptions the files can't be used in triple seven because there was no way to reuse them and so we did what we did and it's it's just kind of a struggle to work against that in media in contrib since we can't really change the way triple seven works but yeah should image module just be merged into file module i don't know for sure um i mean there's a valid use case for image module being different from file since it does have like the alternate text part of the uh field widget and um it has its own formatter for displaying image fields with an image style um but if we figure out you know if we have the image file type and manage the display of that that kind of takes care of that okay so i i'm not completely sure i'm i'm open to input on what people think of why we have two different file reference fields and core so and should files be revisionable that's a very good question too because they probably should um but it's hard to support right now and if files are revisionable and the file is an image and you revision it and it's a new version of the image is that old image file still there uh what happens to the the urls if there are yeah because that's an interesting problem because the file manage table uh the the uri column is unique um so you i don't know how we'd work that out i mean definitely we want a use case for revisionable files be able to store all that old data um but yeah it's a tough issue okay thanks where is accessibility on your roadmap accessibility is we will definitely prioritize any issue that comes up um i just think it's a matter of we need people that know what we're looking for um if if there's guidelines out there with things we should be looking for we definitely want to review those um it's kind of like usability in the same area that we won't we know that probably there's something wrong we don't really know what's wrong um and don't really have the time or capacity to like do a whole lot of research into it but we're totally open to people saying hey here's what's wrong here's here's how we can fix it all the title tags immediately come to mind but there's other things like aria inclusion uh for uh higher education governmental institutions to be a very big deal so we can't actually at the you use it right now because of those issues got it okay definitely talk to me later if you want to yeah no i'm coming to the spread good all right um i was i was wondering if uh an entity reference should be able to to have a formatter so if if we have a an entity reference to a file entity so if that's an image then we want to have the formatter it or the form or the display to display one way if it's a video it has to be different but what do you think about that well that's kind of how the the file types work right now um because you can figure like you configure your image file type and your default view mode for that file type to use an image style uh or you can use you know any other different image in the video like you can set it to configure uh to use media element first and uh you can also use a youtube like it's a little bit weird the manage file display tab for media because you can have multiple formatters and it's like the first one it tries if that's a applicable to the current file it uses that if not it falls down it falls down falls down falls down um and that's a little wonky um that's like one of the usability concerns we have is that people have a hard time configuring that um but like once you have it set it works just fine so so if if we're used the the entity reference field um would we need to improve that so it can display um different forms i don't think it does that at the moment well i think entity reference allows you to use just like a rendered formatter which you select a view mode so it just work with that so cool yep i think i may be sort of missing something uh currently the way that it works uh with managed files is they are more or less treated as sort of a static entity and i don't really see a big disadvantage in that simply because usually when you are referring to something is from a user's point of view they're referring to it from the point of view of a of a node which essentially refers to a file in a file field or a file entity i guess and rather than trying to add revision information at the managed file level why not simply ask users to refer to a different file that is a constant so if they want to upload a new version of a file they're creating a new file entity and the old one can still be left around for your library but they're simply referring to the new one instead and that gets revisioned as part of the node itself yeah and i mean that's could be a way we do original files um and i've heard both cases where people want to actually change the existing file and replace it's just the file data but keep all the fields for it um which is something that would be a little bit of a concern because you'd have to copy the field data over right to the new one you'd it'd be like a clone basically uh operation i would see it more as being uh you know a file upload is static and never changes and all the metadata associated with it granted you know we probably should be adding more metadata uh you know for videos you'd want to have the width and height and so forth that are associated with it but if you take that model then you're taking revisioning out of out of the control at that lowest level of the of the of the managed file and putting it back at the node level which is where i think it really kind of should be yeah i mean we have two different proposals i i don't think we have a right decision on which one's okay what we should use and that's definitely something we'll have to discuss yeah yeah yep that's definitely a good point yep that's a good counterpoint to that so yep all right i was interested in your comment about managing getting it right and contrived versus uh developing as a candidate for core do you think one approach versus the other is more likely to succeed in getting it into drooplate and what happens if uh i i think it's a great initiative and very important what happens if it doesn't make it into drooplate um i mean it kind of depends on how much official support there is behind it so right now we're kind of an unofficial status but i know that Dries and Angie and the Drupal 8 maintainers do want improved file management it's just going to be a matter of making sure that our stuff is ready reviewed enough and it's just that's why kind of we have the initiative is to get more people involved so we can have our own momentum behind it and keep it up and make sure we can you know maybe get these things accomplished by december and do you think uh what about whether one approach versus the other is more likely to succeed i think they're both at this point honestly i mean we haven't initiatives are still kind of new um to us and you know things are getting in with html5 and things that are not related to initiative are getting in just fine too um so i i don't really have which one works better um i just personally like the theory of getting things right or close to right in contrived first and then just trying to move it in uh so i i think they're both valid methods so not really an answer but yep one more so on the another kind of data point on the um file revisions um back in the audio module um it had sort of a quirk where uh as you put in the metadata in the form it would write it back to the id3 tags so i had kind of set up a thing where it did support like revisions of the node would result in revisions of the file um which i mean if you had you know podcast you had a bunch of 60 meg files every time you made a revision which is kind of painful but um the the way that that was sort of usable was that it had its own uh play and download callbacks so it could kind of redirect it to the right version so you could actually have it play the right file since it was kind of obscuring the url and not using the the you know file name as part of the url yeah all right thank you all for coming uh i definitely love to see it the media buff the media sprint so