 Well, so I can stop awkwardly just standing up here. We're gonna go ahead and get started just a couple minutes early and go through some introductions first. So the real meat of the thing will definitely be starting by 2.15. Welcome everybody to Crazy Tricks with Views. Just a quick question. I'm hoping I know the answer to this. How many of you are familiar with views in Drupal? I'm hoping we get, Drupal, sorry. Hope we get a good response. Good. Our presentation, we're gonna be going through sort of four instances of taking views beyond the normal views UI. So we're gonna be talking about a little bit more complex views. Now, we're all very familiar, good, because that was a response I got with views. Basically, views can be used to make lists of content on your site. Lists might be a lot of blog, every blog post on your site could be something smaller. They could be dynamic based on kind of contextual items that your page is offering. So it doesn't just have to be a simple list, but it can be a more advanced type list. You can add references to pulling content from other places and things like that. So those are all sort of examples of some simple to advanced views. I wouldn't really classify them, at least in my classification, as far as complex. So what we're going to do is go more into the complex items, things that you're not just using the UI, you're actually pulling in code, you're using plugins, you're using hooks, and maybe even attaching JavaScript libraries. So that's what we'll be talking today, ways that we have taken views above and beyond your normal view set and how we've been performing some pretty crazy tricks in some of our projects. So my name is Christy Dreyer. I am with Beacon Fire Red. I'm a senior software engineer and technical lead. And hello, I'm a Manny Montsoud. I am a software engineer at Beacon Fire Red. I know some of you heard about our session through Debug Academy, and that is where I did learn Drupal about a couple years ago, and I'm very lucky because I work at a wonderful company, and through our work, we try to create positive social change. So in this first section, I'm going to discuss how we created one view with three needed outcomes. So our client was the League of Women Voters, and they have multiple local leagues across the United States that people can join. And they wanted us to make it easy for their users to find their nearest local league by zip code. So the first required outcome was if no zip code is entered, display a summary list. And that would show the state name and the number of local leagues within that state. The second required outcome is if a user does enter a zip code, display the local league that matches that zip code and show the state league. And then the third required outcome is if a user does enter a zip code, but there is no matching local league, then display all of the local leagues in the same state as the zip code entered, as well as display the state league. So to start off, we created a view page display. And in these slides, you'll see the details of the views, but I'm just going to highlight the important criteria. So it's important to note in this view that it can accept two filter criteria. The first is zip code, which we have as an exposed filter, and that will allow the user to search by zip code and find their matching local league. And then the second is a contextual filter. We have has taxonomy term ID. And on our local league content type, we have a state field that's an entity reference to the state taxonomy vocabulary. So it'd be the state term IDs that we could use as filter values. But we have it set to display a summary when there is no filter value in the URL. And that's how we get the state name to display. And then we also set it to display a record count with the link. And that'll display the number of local leagues within each state. So just by setting up that view page, we were able to achieve outcome one. So we're at a URL that doesn't include, that doesn't include any filter values. So it's displaying the summary list. And then if we click on a state, that takes us to a URL that has the state term ID as a filter value. So that's why it's showing us all the local leagues. And it looks like in the state of Alabama. And then in the footer region, it's also showing us the state league. So I'm gonna show you how we got that in the next couple of slides. So we also created a view block display. And it's very similar to the page display. The filter value that it will accept is the state field. And we have the default value to has taxonomy term ID from URL. Like I said before, that's an entity reference field to the state taxonomy vocabulary. And essentially what, sorry. And basically what it does is once that filter value is in the URL, it'll know which state league to display. So we added that state league view block to the footer region of the local league page view using a global view area. And that's why you are able to see it in that footer region on the page. So we achieved outcome number one. Outcome number two is almost achieved. So a user can search by zip code and find their matching local league. But what's missing is the state league. And it's because we're at a URL that doesn't include the state term ID. So when the user is in putting the zip code value, it's taking them to URL that's missing that term ID. And then also the limitations with the view is that we haven't achieved any part of outcome number three. So when a user does enter a zip code but there isn't a matching local league, we want it to display all of the local leagues in the same state as that zip code. So this is where we get into the more complex thing. So to finish outcome number two, we use a hook views preview, which is used to change things before the view is executed. So essentially what we're doing in this hook is we're grabbing the value of the zip code that the user's entering. We pass it to a function called get state by zip. That's a function we created and I'm gonna show you how we did that in the upcoming slides. But essentially what it's doing is we give it a zip code value and it returns us the state term ID. And that we can use as a filter value. So we set it to arg zero. So we're putting the term ID back in the URL. So that it's used as a filter value and then it gives us the state league in that footer region. So now we've achieved outcome number two. And then for outcome number three, we use a hook views post execute. And that's used to alter results after the view is executed, but before it is displayed. So we want the view to execute because we need to test if the view returned any results. If it didn't return any results, that means there wasn't a matching local leak. So once we know there aren't any results returned, we do something similar. We grab the value of the zip code entered by the user. We pass it to the get state by zip function so that it will return us the state term ID. And then we put that in the URL for the view to use as a contextual filter. So if we remember an outcome one when it displays a summary list and then we click on the state name and it takes us to a URL with the term ID and it's showing us all of the local leaks or essentially giving that page back to the user once there aren't any results returned. And so like I said, I'm gonna show you how we created the get state by zip function. We use the Google Map Geocoding API. So here it is. We start by making a call to the Google Map Geocoding API with zip code and get a response. That response comes to us in the JSON format so we decode it into an object. And then we see that the state information is held in that administrative area level one array. And in the last third section of the code, which I think is the most interesting, we take the state name that we obtained from the response. We match it to the taxonomy term, the state taxonomy term, and get the term ID from there. And that's extremely useful because that's how we're getting our filter value and putting it back into the URL for us to use. And so now we've achieved outcome number three. And it's really important because we could give the user the standard no results tax. Like your search shouldn't return any results. But we're giving them something more useful, right? Because they're looking to join a local league and there might not be one in their zip code, but there are all these other local leagues in the same state that might be close to them or they could also join their state league. So next I'm going to discuss how we created a view switcher. So I basically wanted users to be able to switch the display between a card and list view. And we created a block view display with the masonry format. And in the global view header area, we added a text area with HTML markup for the view switcher. And initially we were thinking we could use masonry methods, which are actions done by masonry instances. And there's this one method called destroy that removes masonry functionality and we'll return the element back to its pre-initialized state. We ended up not going with this approach because we realized regardless of what it does, we need to toggle a class because we're going to style those displays differently. And so we ended up using JavaScript to just add and remove a class. So if a user selected, they want to see it in a list view. We added the destroy masonry class. And if they wanted to view the content in a card view, we removed that class. And that's how we were able to achieve this. But this approach was actually really important because if you notice on the view, we have some exposed filters. So if a user adds a topic filter and then they decide they want to switch from a card to a list view, those filters will still be applied. So it's a better user experience. There was another option to use a module where we would have to create a list view and a card view and switch between the displays. But then those exposed filters would be reset every time the user switched. So it was actually much better to just toggle a class and switch the styling. So if we have time afterward, we can definitely sort of show that in action. I know the screenshots show a lot, but it's kind of neat to see it actually change when you do that. So I'm going to be talking about two other ones. And they're mainly going to be around exposed filters. So exposed filters is a really great tool from views. And it gives our users a chance to change the view, to narrow down the content that they want to find. Most of the time, 99% of the time, whatever exposed filters can give us, that's great, we can use that. There's also modules out there like better exposed filters that will allow you to take some, maybe some simple dropdown list and change them to checkboxes. And it gives you a little bit of control over how you want those filters to actually show. But basically, what do you do if you just need more than that? Like you don't, I mean, checkbox, maybe you have so many lists in a dropdown that checkboxes would be clunky. Or you have a multi-select list and that sort of open select list that you have to use control click to try to click on, isn't just really what your users are going to use or what they want to. So we were trying to look at and see what are some other options out there that we have to actually make this multi-select list a better experience. So on the project, and it was actually, you can see, we have the view switcher on this project. So it's actually the same project that Amani was talking about. We have a view with exposed filters that a user can select from. It's a very long list. I'll show you what that list looks like on the next slide. But checkboxes weren't going to do it and control list type multi-selects weren't going to do it. And it just didn't give us the experience that we wanted for our user to show when they got there. And so we looked into some other modules. Chosen is one and it's great, but it just didn't solve the use case in this particular instance. I've used Chosen on a lot of other different projects and it's been fine, but this one we just needed just a little bit more than what the Chosen module could give us. And we just wanted to have a nicer select list instead of just having that open scroll. And then there's another requirement that we had and you can see under the selected filters, items like Chosen and some other types of those types of filters want to put your selected filters in the same box that you're actually selecting them from, which is great, except for if they're selecting 10 or 15 items, it'll actually push the entire view down the page because you need to have this box that gets bigger. And so we knew that our users would be actually selecting quite a few of these little filters and we wanted to give them a little bit better experience that wouldn't push the results all the way down the page just because they had selected a lot. So we wanted sort of a horizontal area that would actually allow us to put those selected filters there and it would give us a lot more room before that page started to push down. So what did I do? Well, went to Google because that's what all good developers do. I did some searches on different JavaScript libraries, things like multi-select, different types of things that would at least get me most of the way there, maybe not all of the way that I needed, but it would get me most. And I looked at the Bootstrap multi-select JavaScript library, which got me very far. So at least it would handle that nicer select list that I needed. Now there's no Bootstrap multi-select module for Drupal 8. So we had to do a custom module to go ahead and get this started. And I wanted to make sure that when I did this that Bootstrap, I only have to load that library on pages that actually needed it. I did not want to load this on every single page of the site. So then the other requirement, getting those select filters to show up in that horizontal area and you can see what Bootstrap is gonna give us there, just a nicer look. There had to be some custom work on that one. So that one we had to actually do some custom JavaScript for that, or jQuery for that. So my basic custom module, and if some of you haven't done this before or that type of thing, I just did a little bit of a folder structure. So you can kind of see as we're talking about parts of it where these pieces will go. I mean, your basic structure is gonna have a JS directory where all of your JavaScript and jQuery and everything like that will live. You have your CSS directory where any particular CSS that goes along with that will actually go in there. Our templates, we did need a little bit of markup change. So we had a twig template that we added. And then we have our typical info.yaml file which is gonna define our module and everything like that. So Drupal knows that it exists. And then we have our libraries file which I'm gonna go into and the modules file that I will go into. So the first thing I'm gonna do is actually define our libraries file. So in the custom module, if you're gonna use JavaScript, you're gonna actually define it so then you can be using it in different parts of your module. You'll see that I have two definitions. One on top is where I'm just defining my custom library. So this is where all of our custom pieces where we get those horizontal filters and other things that we need to do to actually make this Bootstrap multiselect actually work with our exposed filters are gonna reside in there. The second piece, you'll see the Bootstrap multiselect library. Now, I chose to download this and put it locally in my module. Of course, you can use the same definition to use an externally hosted library as well. There's some reasons why I chose not to do that. And mainly they were control. I wanted to make sure that things I did here wouldn't be changed or I don't know if something happened to the URL or that goes down. This way I can kind of control what I'm doing here. So now that I've placed those files in the files are in the module and that JS folder, the libraries have been defined in my library YAML file. Now I can go ahead and go about attaching them to the actual exposed filters. Okay. So in order to attach these libraries that we pull down and we defined, we need to just find the best hook to actually get them attached on the page. Now, since this was an exposed filter and I wanted all the exposed filters on there to actually get this library attached because we have a lot of these throughout the site and they're all using a multiselect type system. We essentially use the hook form form ID alter which our form ID in this case is views exposed form. So this way, once we did that, we're hooking into placing this on every single exposed filter in the system. So once we did that, we just have to do the form attach library and add those libraries that we've defined in our libraries YAML file right there. So now we know they'll actually load on the page that we're trying to put those exposed filters on. So that was really all we needed to do there. And now we know we have to make some adjustments to some of the markup of those exposed filters just to get what we want to do. And so that's why I'll have a hook theme on there defining a template so we can put our needed markup that we need there. So now that we've both defined our libraries, we've attached our libraries, we just need to make sure that our multiselect filters ready to the filter that we have on those exposed filters is ready to actually accept this functionality. You can see here that we wrote a little snippet that is in our custom JS file that we defined earlier that will make sure that every element on the exposed filters that has the attribute multiple equals multiple, because that's what views actually does, will it will go ahead and attach that multiselect function on there. And that multiselect function is defined in the bootstrap multiselect JavaScript library. And you can say like how did you know what function to actually attach to that JavaScript library to those multiselect. This was all in the bootstrap multiselect documentation. All of these libraries out there have great documentation files and you can see this is just pulled right off their site but they're very clear what needs to be done to actually get that bootstrap multiselect to work with your form. So I was able just to do that. And so for this section that we wanted to get that select filters to actually appear, there's a little bit, those ones that are horizontal, there's a little bit more code than I can really go into detail here. But at the end of the session, we can go ahead and put that up and I can show that to you. I just didn't wanna kind of put up a very scroll-y list of code. But that code basically will set that selected filter section and then once you choose them we'll actually take those filters and put them in that section, allows you to remove them with a little X to actually take them off. So it has a really a lot of functionality. So our final view is gonna be taking this a little like one step further. So in the last few, I talked about how to make a better select list out of this, a normal what views exposed filters will give you. In this one, I wanna go just a little bit further and talk about what happens if those views filters aren't giving you anything of what you want. You need something completely different. This one we're gonna be talking about taking a keyword filter and turning it into a select list. So the background of the project, basically we have a map that we want to plot content, basically no content on. We have a geo field in our content type. There's a geo coder module that will automatically take that city state from the geo field and put it as a latitude, longitude code. And then we use a geo field map module that incorporates with views that's gonna give us a nice map and we're gonna be able to just take that field and plot it on the map on the little pins. Gives you a lot of great functionality as far as defining what those pins look like, defining what your map looks like, you know, all sorts of stuff on there. So it's a great module. But that really wasn't the complex step of this whole process. All these other filters, number of sites and things like that or taxonomy terms, which are really easy. You put them in, get a select list, no problem. We're using chosen for this. So it gives us a really nice experience that way. It does push the map down, but we knew that the general experience was that people were really gonna look for maybe one or two states or possibly one or two criteria. So we knew that that wasn't a really big problem for them. But what we wanted, the big complex one was, they wanted the list of titles. So each one of these little pins has a node, so a content associated with it. And they have titles on there. And to even make things more complex, a good, many of them had the same title. So the same program would just be in different states. So they wanted to have a nice dropdown list that people could say, okay, I'm gonna pick access health. And I wanna see all the sites across the United States that are part of this access health program. So views will not do that for you. You can do a keyword search, like with an open field that you can type in access health. You can do a dropdown of some other types of things, but you cannot do a dropdown of titles. The best thing you could probably look at is like node IDs or something. But then again, even if you could get that to reference title instead of ID, you're only really gonna get one of the ones that you're trying to find to choose. You're not gonna get the whole list that you need. So we had to do a little bit of working on this one. So enter the views filter plugin. That's the Drupal 8 plugin system. It allows for all sorts of things to happen, especially with views. It will allow you to do custom fields, custom filters, custom sorts, other components as well. You can do all sorts of different things, footers and headers and things like that. So our approach was to use the views plugin system to actually get that functionality that we needed. The views plugin system really gives us a straightforward approach to creating our own filters, which is great because we can work within Drupal, we can work within the way Drupal wants us to work and get custom functionality. And so we're not trying to override as much as other types of things. So there's already defined filters in the system since views is in core. You can look at the views module in core and you can look at the plugins and you can look at they have them for fields and filters and all sorts of sorts and all sorts of things. And if you look under filters, there's quite a few of them already there for you. You have an in operator one, which is probably one that you're probably used to using with taxonomy. It allows you to say, okay, I want one of in this list and I want to multi-select this and I can expose the filter. They have string filters, which would you would use for your keyword type text filters. There's dates that you would use for the little date choosers and Boolean operators. I mean, there's a whole lot of different filters that are already in the system and they're pretty simple to see if you open up the code and you kind of look at the, just on the titles of the filters, you can pretty much tell what they're doing. So our approach, the requirement of doing a dropdown box that was really secretly a keyword search was to choose the best filter from that views to actually use as a base in the custom module that we needed. Since we really wanted the general functionality to be a dropdown, I went with the in operator one to start. So I went ahead and chose that in operator one just because it gave me everything I need, really. I just wanted to alter what the options were and what actually happened when you picked one, but I liked the way it was structured. I liked that everything around it could just be exactly what views expected. So we went ahead and go with that. And it gave me the multi-select option and things like that, so it was a really good choice for this one to choose. So our custom module structure on this one was basically copying what views already does in their views core module. I just copied the same structure. We had a plugin, we had views, filter, and then we had our special filter that we were trying to build called program titles. So you can see it's pretty easy to copy exactly what views is doing. I'm just gonna be recreating that here. So once you create your structure, you have to define your views plugin. And basically you're gonna do that in this module name, whatever your module name is, views.inc. That one is going to allow you to actually say what your view, what your plugin is. So Drupal knows you're actually registering a plugin for the system and what that plugin is. Is it a filter? Is it a field? All that type of thing. So once you do that and you copy that in operator, I just totally took the whole file, changed the name of it and use that as a base. You then, all you need to do is actually change the code that needs to be changed. The rest of it can be removed from your file. If things that are happening already within the in operator system you still want to happen, I just took that part out of my custom file. Because I only needed to actually override the things that actually changed in the system. So the first one was our init function. That one was pretty easy. It just basically defined some of the items in that filter. And then it told us that to look for the, as far as generating the options for that, to go ahead and look in our generate options function. So that's a pretty simple little override to make. I mean really the entire, the only thing that I actually changed on this was just changing the title to allowed program titles. So that was very simple. So a little bit more complex was the actual generation of items. Normally this would be taking a taxonomy list or some other type of list, but we actually wanted to specifically say only look at titles and only look at titles of programs. That was the content type that we were actually using in the system. So you can see we built a query. Basically I took the query that was already in operator and I just modified it some to say, if it's published, if it's a program, to actually give it back to us in a alphabetical order ascending. And I was able to just go ahead and generate this array. The stuff on the bottom, because these program titles actually had a lot more in them than just the item I wanted, they actually had, we used a module I think was automatic node titles. It would put in organization, program name and some other things. I have on here where I just want the program name and that's it. I don't want the entire title. So that's sort of a specific to how they wanted their titles to look and how they wanted it to show up in the views filter. So you see that that's why I'm saying, explode on the pipe symbol because that was part of the actual title. And then I wanted to make sure I didn't have any duplicates. So that's what the array unique is doing is is factoring out all those duplicates. And then I'm using a natural sort just so that all my list is in a nice alphabetical order. And that way I can, it just looks nicer and easier to find things that way. And at the end I'm just returning the option. So I say I'm just making a very simple query and showing those, we're going ahead and generating those options for it. And that init function is actually where those are called. So the only other function I had to change. So I have the init function and there's a lot in these files. So really I just had to change the init function, the generate options function. And then I wanted to go ahead and change one of the operations on there. And since the one I was using was the op simple, I have my original function, which is what in operator gave me. And then I have my customized function that's gonna make the query that I want, which is actually more of a keyword type query. So if you look here, most of the top part is the same, but I actually added a query in there that would say, okay, take the title and say like the keyword that they actually chose. So that way it's doing more of a keyword type query instead of just a direct this ID equals this ID. And that gave me pretty much the query that I needed. The only reason why I have it in a for loop there is because basically there's more than one and we wanted to make sure that we, if they selected more than one title that we were actually going through all of the titles that they selected since it was a multi select list. So then that was it. Now I had a filter that generated the option list based on my custom query that performed a search based on my custom query, but yet used all of the items that Drupal wanted to give us. It made my life easier. It worked within the Drupal system. So obviously it's gonna be a better experience just overall. And when you actually looked in your views UI, you did a thing I would like to add a filter. My filter showed up. I just had to add it say one of these titles and then say multi select and then do expose. And that's all I had to do to actually get it to work. So that was sort of taking it just a little bit further. Now what I wanna do is actually show you a couple of these in action. So let me go ahead and stop this. So I was gonna show you a little bit of what Amani talked about. This is the League of Women Voters site. So if we go ahead and just click this, we're gonna see exactly what she showed that we're gonna see with no zip code. This is actually just a list and it shows everything that we can do. We can select on that. It's, you know, it works great. We can put in a a league zip code and it's gonna give us one exactly the way we'd like and show us our, you know, our state league. So that is, and I said, and it's all built with views with some pre-execute, post-execute hooks. The other ones I can show you, whoops. Now this is a site that hasn't been launched yet and we're still working on things. You can see like this view switcher's a little high and that kind of thing. So there's definitely some styling issues on here. But this is one that we were able to do. This is kind of messing up with the, there we go, it's a little bit better with the resolution here. But we can see our multi-select, bootstrap multi-select in action. You can see the little check box. So instead of doing these control select, you know, trying to get it that way, we can see as we choose them what our selected filters are. And then it's filtering, that's why it's going down to just one item here with our test content. We can go ahead and remove some of these. Oops, there we go. And so you can see that that's there. We can change the views, the look of that view. Make sure it's, that's interesting. Live demo is always great, aren't they? I was gonna see if I had another one here that I could try. I'm not sure why that's not switching. Let's see. Oh, let's see, this one's all kind of kooky. There we go. For some reason, that one was not actually switching. But we can see that we have a list view and you can change that to the card view. The nice thing is that these views are actually the same view. We're not using two different views, we're just really using two layouts of the same view. So changing, if you have to change something or add a piece of content or something like that, you're just going to one place and it can affect both of your views there. And then I wanted to go ahead and show you a little bit on the map. Another piece that hasn't really launched yet, so I'm going to make sure I'm logging out of this. So here we have our program model name. So all of these are pretty simple, the target population. All of these here are just taxonomy terms. So views, filters, normal, exposed filters, handled all of these. It was this program model name. So you can see that we can go through and look at some of these. Again, this is a lot of test content, which is why it looks a little strange. But if we choose, I was going to choose like Kermore for instance. So we're only going to see, whoops. We're only going to see the items that are Kermore and these are actual program titles. We're not using a taxonomy term, we're not trying to fake it and somehow. I mean, there's other ways you could do this is actually put a taxonomy term and match the major program. You could put that as an additional field on the content type and just search on that. But it doesn't give your admins the best experience because they're having to do the same thing twice and they're having, they could forget it. So then they're asking, calling us saying, why isn't this showing up? But this way we're doing it directly off those program names. And if they change the program name, it will change it here as well. So that way we're able to really give them a good admin experience, give our users a good experience when trying to find something and working within the views plugin system. So I have our little shameless plug about our company. We're definitely hiring. If you are interested or you're looking, definitely talk with us. We'll be happy to talk with you. I'd like to, before we open up for any questions, we're gonna promote that the sprints are tomorrow. They're a lot of fun. So I hope you, I hope we see you all there. Obviously they're, every session we're asking for feedback. Please give us feedback on this presentation. We'd love to hear negative, positive, whatever you'd like to tell us. We would love to hear it. It helps us kind of refine this a little bit. And then this is us, Emanian and my name's Christie. So if there's any questions, like to just open up the floor for that. I'm wondering in the state list of chapters, was say a proximity search considered? We did. They, the client has very specific zip codes that are covered under very specific leagues. And when we asked them about a proximity search to show, like let's just show you the leagues that are closest to you, they weren't really open to that. They wanted to say, we wanna give them all the choices and let them pick from there. So that definitely would have been a consideration. Well, we'd like to thank you guys for coming. I hope you guys enjoy Drupalcon. We'll be up here for a little bit if anyone has any questions they'd like to ask us. And we'll see you guys all tomorrow. Sure. Okay. We'll be here as a text one. Zika, is there, why did you go with, you know, the, you know, Google Maps, that guy, Geo-Occasional, the person that's here, right now. Don't, for just a set list of, for instance, zip codes by State, for you, by Google. We just call it a little safer using Google and then something that we had to do updates. I don't know how many times a new zip code has ever generated it, probably never. There's definitely ways you can download a set of zip codes and have them march to the State. We just, at the time, we're looking for something that we just called pretty sure. I know Google's not going away. I know Google Maps API isn't going away. I'm just worried that it's a little back end dependency. It is a back end dependency. Yes. Or, you know, you can get, sometimes these errors that you've, you've accessed it too many times. So I mean, there definitely is something that we considered. The time, again, it was just, we just felt like it was the best way at the time. Yeah. They're trying to sort of maintain something. Cool. I was just wondering. Sure. Thanks. My question was also wondering, so do you think there was no result, right? For which one? For the zip code one or? For the zip code one. So do you think a zip code would be the same? No, that one would only run if there was, well, there's no zip code, right? No results. No results? Yes. So that would run every single time. So if the user is listening, they're repressioning it. Hey, if they're employer, they're going to be responsible for a full type of line. Yeah. Yes. We're looking at that where we have some, we have some skittish, with all this new requirements from Europe and things like that. We have some skittish clients about cookies and things like that that we're really trying to work with them to come up with a really good solution. Like, as soon as I sign up, like, that's a big list? It's a, it can be a load, yes. If you're reloading the page, yeah. Yeah. Oh, the map, map is actually coming live as soon as I get home. So, yeah, the only reason why it's not is because I'm here. That one is probably the end of May. Stop. It's supposed to be the end of May. The slides will be available on the session. Yeah. On the session page, yes. Yes, I can definitely share that as well. Yes. So, it's chosen, does it still have a list? Yes, so it's chosen, I was actually kind of showing that, we were having a hard time with that one, yes. The way, I think it was more about the way that they wanted those filters to look. So, if you see here, you'll see that this is actually using the chosen library. So, by doing this, normal chosen is actually inside of the field and the field kind of just gets bigger or it says one select or something like that. It was really trying to get our stuff to work with our designer's vision and how that sort of intersects. So, that was why that one, or why we decided not to do that on the other system, that they wanted that select list. Okay, thanks. So, usually, that's probably a D8 image. Oh. Which module is that? It's views argument substitution. Okay. It's a ridiculously simple thing. One of the things that we do is say, set up a no contextual argument, which just allows it to take arbitrary input and then you can actually use that value for any number of filters, like actual filters so that you can have a whole lot of things that you can filter on in a view that aren't necessarily exposed to actual argument. Okay. And what this can be really powerful if you use it a lot because the reason I built the thing is to have basically one exposed filter that can search many different fields. Okay. You can do that by having one contextual filter that is throw away. It's no, so nothing's done with it, but then we can actually use that as input to this or this or this and this and this and this and this. Okay. It's very complicated where it was. Right, right. From one field. From one field, okay. That's where we can search like final names and tags and a whole bunch of things with just one. And you said you're importing that to DA? I haven't yet. Okay. It's in D7, but I mean, it would be probably incredibly simple to import to DA so that it might be worth it. Views argument substitution, substitution. I don't think I've never used that before. I'm interested to take a look at that. Just thrown it out there because it might take about the same amount of effort. I will happily grant co-maintain her on. I'll take a look at it, definitely. Just my primary goal is to have a DA, so I have no... So you have no real driving motivation to do it, yeah. I need to take developer time to do this. For our sake, we don't have. Yeah. It's not going to fly. Yeah. And the other thing that I was just wondering about, it looks like to compile a list of possible names and all the statuses that they will just run the post and actually put it on the list of people where it's compiled in the greats. I think that it might be possible that it will return the posts that weren't published yet. If they have a title that matches... Right. ...a different one that is published. I'll take a look at that. Thank you. Yes. I think it's going to be a private price. Yes. Yes. Yeah, thank you. I'll take a look at that. We haven't launched yet, so yes, yeah. I'll take a look at that. Yeah, I'll definitely put in a where published equals one. Yes. Right. And then I think it's going to be a cash session. Yeah. Easy for the user to do that. Yes. Thank you. Yes. Thanks. Substitution? Substitution. Substitution. Substitution. Sure.