 Last night about 11 o'clock as we're heading back from the Pantheon party, my wife sent an email that said the news last night in Denver said that today was take your child to work day, which somehow seemed quite appropriate given the presentation we're about to do. So we just thought it was, the timing on it was just so amusing that we had to add a slide at the last minute. A little bit about me. My name is Greg Marshall. I work for Accenture Digital currently on loan to Accenture Federal Services as a digital technology developer manager, which I have to think about. Basically, I'm a Drupal architect. I've been on Drupal.org since 2006, so I have about 10 years with Drupal. My very first DrupalCon was 2010 in San Francisco. That's when I made the decision to stop using Drupal as a CMS and become a developer. My background is in programming, but I was doing channel marketing at the time, and it became clear that there was a lot of demand for developers for Drupal, but not so much demand for channel marketing consultants. So I did that. I happened to be an aquia grandmaster twice, once for Drupal 7, once for Drupal 8, and what sort of the genesis of the original version of this talk was I wrote a book on views, and there's some discount codes on postcards lying around in various places in the room. Hi, I'm Amanda Marshall, his daughter. I have a bachelor's from CU Denver in business administration and a graduate certificate in energy and sustainability, and when all that education could not even get me a job interview, I kind of decided to try Drupal. And I did Mike Canelo's Drupal Easy Academy. I just finished around the new year. And I've actually been a Drupal.org member since 2008 because he tried to get me involved with Drupal earlier, but I thought it was more important to focus on my bachelors. This is my first Drupal gone. I've been doing an internship with the UN on their humanitarian response site, and I'm still looking for my first real Drupal job. I work for a large corporation, so I have to put a disclaimer up. Basically what this disclaimer is saying is, I'm here presenting as Greg Marshall. I do not in any way represent Accenture or their views. So with that, let me set up the reason why this talk came to be structured quite the way it is. The family has gone, you know, we'll go out to Sunday brunch, and historically, when I'm having a conversation with Amanda, it would be about gardening or crafts or sewing or travel, never Drupal. And about last Thanksgiving time, she was about halfway through the Drupal Easy Academy, and we're sitting at one end of the table having a discussion about a problem she's having with a Git repo. And it hit me that meals at our house would never be the same again. So we're going to sort of adapt that discussion to talk about views. And so Amanda, how's that UN project going for you? It's going really great. We're diving deeper into Drupal themes, and I've been able to build a few views. I thought during my class that I really understood Drupal views, but now I'm kind of having trouble with some of the terms. Yeah, that happens. Views is like all Drupal, many things in Drupal is an overloaded term. So we have lots of different meanings depending on the context for any given term. So let's talk about what views is, Amanda. Views, when you see it in the plural, is the views module typically. And so up until Drupal 8, it was a contributed module. As of Drupal 8, it became part of core. But when you think about what views is, it's a way of creating dynamic lists. Or for those of you that have been around, maybe not quite as long as I have, it's a report writer like Crystal Reports, if anyone can remember that far back. And then when you see the word view in the singular, it's typically one particular list or the configuration that creates that list. So you'll hear about view and views, and you have to sort of know which one you're looking at. Why would you want to use views? So let's think about the circumstance where you have a blog, and you want to have the five most recent blog posts on your front page. So if you were doing it manually, what you would do is you would add the blog post, and then you would go over to the blog, and you would edit the blog, and you would delete the oldest blog post, and you would add the one you just added. So two basic, two steps. With views, what you can do is add that blog post, and automatically the front page will update with the five most recent views. So that's where the power of views really comes into place. When views was a contributed module, it was the number one module. Now technically if you go and look at the list, yes, Ctools is ahead of it, but Ctools is one of the support modules that several modules use, so it tends to show up more often. But about 80% of all Drupal 7 websites have the views module installed. And now as of Drupal 8, the front page and many of the Drupal administration pages are views now. They're not hard coded like they were in Drupal 7 and before. So just looking at a few examples, Amanda, we got the front page, which is now a view, and could be modified. You have the content list, which we've all been to at one time or another. And that's a view with exposed filters. You have the files view, which has a view, so now it's actually a view instead of just being a term for a view. The who's online block is a view that's predefined in Drupal Core. And finally, the user list or the people list is now a view. So when you manage a user in Drupal 8, you're actually using views to do that. Let's talk about, you know, how views made up, and that'll help you with some of those terms that you've been having problems with. So basically what you have is you have a base or a view type, and that's when you create a view, it's what the view is going to display. Now, probably about 90% of the views you'll ever build are views of content, probably filtered by a single content type, but they're views of content, but you can do views of other things, and we'll talk about that maybe. And then once you've defined the basic view type, then you have a display. And a display might be something like a block, it might be a page, it could be a REST API, but there are a number of already defined display types that are built into views. Once you've got the type like a page, then what happens is you get a format, and a format might be something like a grid, or a table, or an unordered list in the basic views, or things that are added by contributed modules, and then once you've got the format, you have a display type. It's either something like a content, or a teaser, or a view mode, or my favorite, which are fields, because it's a very flexible way of doing it, so you could do it as a content and manipulate the display mode, but I like to use fields, and then within that you've got filters, and finally sorts, and those are the various parts of the major parts of it. So if you look at what happens when you create a view, is you get the view edit screen, and I know you can't read this. So let's look at it. Basically what I wanted you to see in this version is that there are three columns, and if we look at the first column, what I just described is pretty much defined there. So at the very top you have the display, in this case it's a block, but we could add a page. You can have multiple displays per view. Then you have the title, which is just there. The format, which contains the format, and the settings, and whether or not you're going to do fields or content types. In this particular case, because I've selected fields, I get to select which fields I'm going to display. Then the filter criteria, and then finally the sort criteria, the order of it. In the middle, if you look at that middle column, in this particular case, because I've defined a block, it's the block settings. If I defined a page it would be the URL, the menu that it might appear on, and in both cases you can actually control access using the Drupal permission system. Then you have a header, a footer, and a no results block. Most of the time the thing you'll pick are just blobs of text, so you might have an explanation of what you're displaying at the top and the header. At the footer you might have a legal disclaimer, and the no results behavior becomes very powerful if you're doing exposed filters, because you could have visitors that might select a combination that produces no results and you don't want to just give them nothing. You'd like to tell them they picked something that might not have worked. Then finally pagers, so Drupal automatically in views supplies the ability to navigate forward backwards through a large list of content. Finally in the right hand column you have what's called the advanced, and if you don't turn on the setting in the views settings part, you'll see it just as a collapsed field, so it just says advanced, but when you click on it it'll open up. Contextual filters and relationships are the two parts of this column that people tend to use the most. Very honestly, most of the rest of it I would be surprised if you end up using. Why don't you take an existing view, the content list, and I know you're working on a real estate agent side project just for fun. Why don't you set it up so the real estate agents when they log in can go to a page and see just the properties that they're allowed to edit, the ones that they're responsible for and make it a more user friendly kind of experience. So we want something that looks perhaps something like this where you've removed some of the exposed filters, you've renamed some things, you've gotten rid of extra fields that don't make sense to a typical content editor. Do you think you can do that? Yeah, so the first thing I'm going to do is to duplicate the content maintenance view. That way if I make a mistake I don't screw up everything. And then I'm going to change the title to property maintenance by clicking on the word content and under title. In the field section I remove the bulk operations form by clicking the field name and clicking on the remove link at the bottom. I'm also going to remove the content type and the author user name fields since this view will only display the properties with the current user. And then I also remove the translation language filter since the site only has English. And finally the content type filter, I'm going to change from being exposed to being fixed and select the property content type. And then the most important step which I often forget is to click save so that all your changes are applied. So this shows the before and after edits. It was relatively easy but in a fresh copy of Drupal you only have two content types, basic page and article and they don't have very many fields. So why is views around? Is it only for administration screens? Good question. So where views becomes really powerful is when you have structured content. And from Drupal 6 to Drupal 7 the CCK module became part of core and became the fields module. And what it did was it added the ability to add a number of fields to a content type and structure your data in a way that you could use it more powerfully and recycle it. So it's a very powerful thing. So you have things like text, number, boolean which is true, false, file, image and reference fields which are relationships between one kind of content type and another content type or between a content type and a user. In Drupal 8 it became very, very flexible. And then you can add additional fields using the various contributed modules. So one of the ones that I use in Drupal 8 is the geolocation field. In Drupal 7 I used to use the location field but it wasn't ready for Drupal 8 when I started playing with views. And so if we look at your example and this is impossible to read and that's okay. Basically if we have a number of content types that we've defined, one is the property which has a number of fields, a large number of fields which is why it's so small. But things like the address, the number of bedrooms, the number of bathrooms, the asking price, the square footage, the kinds of things you would expect in a normal property listing. And because you have owners and realtors and you may have one or more of those, we used a different content type for the owner or realtor that you use as a reference from the property type. And then finally you have open houses when you're going to show the thing. And in this particular case we actually set it up a slightly different way so the open houses are referencing the property instead of the property referencing the open house. So if you look at this as a picture, which is much easier to see, you've got the property in the middle and it's relating to or referring to the realtor or to the property owner and you can have numbers of those. It also has two other references which we tend to think about as references but they really are and that's the county and the neighborhood and those are taxonomies which are taxonomy term now is basically a reference. And then finally we have the open house and the thing I want you to look at is notice which way the arrows are pointing because when you go to build your view you want to follow the arrow if you can. Views will let you go the other way but you pay a performance penalty for doing that. So why don't you walk me through how you would create a view? These are very easy to get going. It starts with a simple form but as you check boxes in it it becomes a bit more complex. The new view wizard only does the most common use cases which are page and block. Other displays like attachment have to be created manually on the edit page. So if we look at the starting widget page where the first questions are pretty easy you have to give your view a name which will automatically create the internal name that Drupal uses and then you tell the views what view type you want to create or what kind of entity or what entity you want the views to be based on. Content is the most common so it's also the default and then assuming you pick content you can select the specific content type like property and the initial sort order. Finally you can check boxes to create a page display or a block display or even at a rest endpoint. But of course nothing in Drupal is as simple as it appears so once you click create a page you get a whole bunch of additional settings. We'll zoom in on just the settings you see. Here you can set the page title and the path and you can select what kind of display you want on the page. Since my property maintenance view was a table I'm just going to do that here as well. You can also set up the pager for when you get too many results for a single page and you can also add a RSS field or feed. Fortunately except for the basic view type anything can be changed in the view edit screen. So dad what are the various parts of the view. Okay well we talked about them when we defined the terms but let's go back and look in a little more detail. So if you look at the base view or a view type you end up with content which again is the most common. And then because of the way Drupal 8 is structured with everything being entities a lot of additional things become accessible to views. One of which is the content revisions and when I first looked at that I went what do you do with content revisions. And I was talking to somebody who works on a government site and they're required to display the current content plus the log of every change that they've ever made to that page so that people know if something's happened you know the regulation that might be on that page has changed in any way. So there is a use for content revisions. Comments are now not part of a content type they're actually separate and so you could do a view of comments and you could sort it perhaps by the most popular comments. Or the most recent comments things like that. You can actually do a view of the log entries that Drupal keeps internally typically for errors which is a very interesting concept except that when you go to production one of the recommendations is that you turn off the module that maintains the log entries and so it's probably not a very useful thing in a production site but it could be handy when you're debugging. You can do views of files or taxonomy terms or users so you can actually build views with users in them. You can do views of custom blocks because now blocks are entities. You can also do views of custom block revisions because it's very symmetrical. And then just as importantly you can do views of things that are being defined by contributed modules. So I've actually written a module or two that use tables for performance and I can expose them to views by defining that table to the views with a certain kind of interface file. Once I've got the view type defined then I can define pay displays and again the most common ones are page and block that's probably about 95% of the case. The third option master is actually in every view but as soon as you create another display it disappears unless you've set the setting to always show it. So in view settings there's a way to always display this but what makes it sort of a useful display to have is that all displays are created starting with that as a base and then you do overrides against them. And so it's very handy if you want to affect, if you have let's say two blocks and a page and you want to affect all three of them together, if you edit the master it'll affect all three. If you edit just one of the others it could be overridden in such a way that you wouldn't affect the other two which is good most of the time but sometimes when you want everything to happen. Attachment is a kind of view that is attached to another view so you can literally in the case of your real estate agent have a view of properties and then create an attachment that goes with it that's a view of the open houses that match the properties that go with that page. So as the pager moves the properties that are being displayed also change. You can have an embed view display which is something new in Drupal 8 and frankly does nothing. The actual code for the embed says at to do no more. But I think the intent was to there's a function call that you can use inside Drupal called views display or views display view that literally let you embed a view output into your code and further manipulate it. And I think the idea was they wanted to be able to limit it to only embed type displays they just didn't quite get that in included in core. I would recommend you go ahead and use it anyways even though it actually doesn't generate any special cases because that's a signal to anyone else that visits this site as an administrator that this particular view is being used in code somewhere and you might not want to play with it because you could break things you don't recognize. Then you have the entity reference display and this is a very powerful new display for views. So if you create an entity reference in basic Drupal it's an autocomplete field based on the title of the entity that you're trying to reference with the entity reference you can actually change that widget from autocomplete to a view and you can use all of the power of views to select just the entities that you want to be able to select from. So you go from an autocomplete potentially to a select list that might only have 5 or 10 values depending on things that are happening inside your site. The last two feed is an RSS feed and that's been around for quite a while but it's a way of telling other sites or like if you're defining a podcast you can actually tell iTunes about any new podcasts that you've defined. And finally REST import because Drupal 8 has got REST built into core and you can now using views create data that can be accessed by either a front end program or by another website. So you have this very powerful again with all the power of views to be able to select and narrow and reformat all that data. Once we've selected the data and we've sort of picked what we want then we have format options and so built into views are like the grid which up until Drupal 8 used a table, HTML table and so it wasn't considered a very good way. Drupal 8 actually changed it to divs with CSS so it actually functions the way you would like it in a modern browser. You can have an HTML list either ordered or unordered you can do an unformatted list which is really just dump the data I'll deal with it myself or you can do a table and tables are very powerful and allow you lots of things and we'll see that in a minute. Finally contributed modules add more format options so three very common ones that I've used before are the accordion. So views accordion module adds an accordion display style which is when you click on the title a bunch of other stuff appears with JavaScript when you click on that title again it disappears and you can click on a different title and see that. The view slideshow which is the carousel generator that we all hate and have to use but it's there and then finally maps so you can actually use Google mapping to display the results of your view. So once you get defined a format option you have settings that go with that in this particular case it's the table and the table is probably the most powerful and rich of these so it has very complex settings. So you can actually reorder the columns of the table without reordering the fields you can align them different ways you can actually make a table responsive because Drupal 8 is a fully responsive environment so you can cause various as the viewport narrows different columns will disappear based on their priorities when you set it up in the column. You can also add two columns together and add separators to them so that you can reformat it in a way or you can actually put them one above the other in the same column so lots of things you can do with with the table. Oh and you can make them all click sortable so even though you've set a sort one way you can actually let the user or visitor to the site come back and change that sort order within the table. As I said I really like fields so the next thing you'd have would be the list of fields that you're going to select and in this case I've got a title and asking price number bedrooms these are the kinds of fields that you would pick. I like this over content types because I have a lot of flexibility and it's very visible what you're seeing what's going to come out from from this point. And then because it's Drupal everything has settings and so for every one of those fields there's a number of settings. You can have a label that either is there or not there so when it's a table it's very handy to have when it's a grid or a ordered list very frequently you'll want to get rid of the labels so you just very simply select it if you have it you can change what it is it doesn't have to be the default that is given to you by views. And in this particular case I use I'm showing an example of dates so you can change the format of how you want your date to be represented. Do you need a long date with the day and the month spelled out or do you need something that's very short do you want the seconds to show do you want the minutes to show all those options are available for you. You can actually go in and add CSS to every field and use that to help with your theming and then you can do my favorite which are field rewrites. And so field rewrites allow you to change what's coming out based on what on the field and at the bottom of the slide you have these replacement patterns. So for every field that was above the field you're at you get a token that you can use to rewrite. And so you can put those together so you might have a URL and a text a title and you want to make that a link clickable link title you can then hide the first two and come back and create the HTML that would make it a clickable link with the with the attacks. So it's exceptionally powerful that you can mix and match your various fields and basically get formatting that you might not be able to get in any other way. And when I was doing this in Drupal 7 the replacement patterns are the token format so it's a square bracket a name and a square bracket. And in Drupal 8 it became the double curly brace which is used in twig and I just assumed that it was you know we're bowing to the new format of twig. And then I got thinking about it and I tried something and it turns out that that rewrite field is a twig template complete. And so you can actually put anything you put in a twig template inside the rewrite field. And so just to show what can be done I put a control structure in twig that walks through the first letters from A to M. Upper case is them I'll put some with an asterisk in between them and then loops back and does the next letter. And so what you end up with is ABCD through M with asterisk is in between them. So you have that power it's really a very powerful capability. So Manda I've been talking for a while. You're probably bored. Why don't you tell me how filters work. Well filters let you select just the part of the data that you want that of you might return. For example a show that we both watch is Tiny House Nation. And that's about houses that are smaller than 500 square feet. So I thought it would be fun to have a tiny house page on the website. So what I did is I set a filter to limit the results by property square footage less than 500 square feet. I could do that on an extra display of the main property listing view so it was really easy. Exposed filters let visitors choose what values to use. So in the real estate site this view lets visitors set ranges for things like square footage asking price and number of bedrooms so that they can find just the house they're looking for. So dad I can see that for a neighborhood I can filter by the neighborhood taxonomy. But do I have to create a different display for each neighborhood. Each with the filter set the way I want or is there a better way. Of course it's views. And so the contextual filter in the advanced column is really just a view filter like any other filter you would define except the value you're comparing it to for the filter is actually contained in the URL. And so by passing it through the URL you can actually say I want to pick this particular taxonomy term or that particular taxonomy term. And if you'll notice this URL has a little problem it has a percent 20 in it. And that's because when I set up the taxonomy terms inside the vocabulary I wasn't thinking about contextual filters and I use spaces. So I have to be a little bit creative about how I pass that data to to the contextual filter. But it's there and allows me to select by neighborhood simply by passing the right URL to it. The other so you set it up by by adding a contextual filter and then configuring it and one of the most powerful parts of contextual filters is the default action. So you don't have to pass that value by way of of the URL. There are other ways to get it there. Probably neighborhood isn't a good example but if I wanted to have a view that displayed something in a block blocks don't have URL so it would be really hard to pass the URL to it. But I want to have a block that let's say goes with a particular node or content display. I can actually set the default to use the existing page node ID as my contextual filter. So you have a lot of power that you can do with this default capabilities. So you know we've talked about filtering. Why don't you talk about sorts? Well views wouldn't be too useful if everything was just sorted by date. But as you said this is Drupal so anything is possible. In views I can change the ordering or sort criteria to be any field and it can be either ascending or descending. I can also have multiple levels of sort so if the first sort criteria is neighborhood then I can and it returned me a lot of results. I can add a another level of sorts like title and sort within that group. So looking at the settings for sort criteria fields I see you can expose the sort to let site visitors change if they want ascending or descending. In this example I'm sorting by a date field which adds a granularity option so I can sort down to the second or even the date. And then use a second sort filter or second level sort to sort by another field like alphabetically by title. Sorting is pretty easy but using the structured contact like you described I want to have a view that shows fields from the realtor in my property. But when I try to add the field the fields don't show up. Is there any way I can do that? Yeah so what you need is a relationship. When you have a reference field all you see in the base view is that reference ID. You don't see the fields in the other content. So if you go over again in the advanced column and add a relationship that says this particular content type is related to this particular content type. Then when you go back and add a field you'll notice that all of the fields in the second content type are now available for you. And this is where it becomes really important to follow the arrows. So when you bring up let's say the open house you have content that's referenced from the open house and you have content that's using the open house. So if the open house were in the property we would be following it the right way. When we have to use the referenced from views is actually having to go in do a query pull all that data in then sort through it and figure out which one's pointing at me. So that's why you take a performance hit. But even if you do that you won't see the field you want. You'll add the field it won't display it'll just be blank. And the reason for that is you actually have to go into the field settings and tell it which reference to you or which relationship to use because you can have more than one relationship. You need to be very explicit in that even though there's only one. So you end up with with things that look like this where you have the title is twice. And at first you think why would I want to display the title twice. Well it actually turns out the first one is the title or the address from the property. And the second one is the title from the realtor and you'll notice that one's hidden. And the reason why it was hidden was I was using a field rewrite in the realtor phone to be able to put the realtor comma and their phone number and have it collapse down in the table. So you don't have as much space. So Manda why don't you I know you haven't started the theme yet but why don't you go ahead and show me some of the things that actually happened now that you built your views. Well on the front page we have two views using contrib modules. The picture of the house is actually a carousel or a slideshow that changes about every five seconds. And then below that is a map of available properties. And when you click on a map pin it opens up a box with all the relevant data. As you can see here I need to figure out why it's duplicating all my data. This is the basics what's for sale page. It shows the views with various exposed filters so that visitors can sort or limit their results to houses that fit their search. It's in a table format and it has groupings by neighborhood. This is another display from the main property display that uses like utilizes the context contextual filter to show only the city center neighborhood. And then finally this is a views infinite scroll picture gallery of available properties. So it starts off just showing four properties and then as you scroll down it'll add four more properties and then four more properties. And it's kind of like time what are kind of like the Facebook timeline so you can just spend forever in there. Wow that's pretty impressive and a lot of you got a lot done in a single weekend. So does anyone have any questions so views can get pretty complex and you can put a lot of work into it. Can you talk about strategies that you have for importing exporting views or migrating them from one environment to another in Drupal 8. Of course you have full support with the configuration management. So as you export configuration you will export your views with it. You also have the ability inside views to import and export an individual view and save it as a text file. It does it by when you export it it just creates it in a field block that you can then copy into a file and then copy back in when you're on the other site. So both ways work and of course if you have the features module you can add views to features. So you have basically three different ways. I mean it's Drupal there's more than one way to do anything. Other questions do because of the recordings would you mind. This is a pet peeve of mine with the default for the display is all displays. And so often you forget that you want something just for this page or block and you mess everything up. And I was hoping and praying that with views in Drupal 8 the default would be this display and then you can make it or use the master to do that. And it's sadly not there. It sort of brings me to one of my my maxims which is save early save often because you will I don't think I've built a site that I haven't done that at some point during building the various views. It's like you know you wish there was also and or an undo button that could say undo the last thing I just did because obviously I didn't mean to really do that. But sadly I'm not the module maintainer. I just happen to be a user. So I don't have a lot of control over that. I wonder if there's an issue on the issue queue if there isn't you really should otherwise chime in on it and say yes I want that. Other questions comments night remarks. Hi Greg. Can you speak a little more about the performance hits that you would take when you're sitting up your contextual relationships. I mean you showed that diagram of like hey this is the content that's related to this content type and it's related to this content types and you were saying hey follow those arrows. Are you basically just saying put the relationships in the same direction. Like to follow the arrow so you want to go from the content type that has the reference field to the content type that's being referenced. Okay because if you go the other way basically what views has to do is pull a bunch of data in from the reference content type and then sort through it in memory to figure out which ones are pointing the right way. So that's how you're determining that is like when you're when you're setting up those content types and you're setting up field references you want to make sure that your views basically go the same direction. Right and sometimes it makes more sense at because of that to define your view what I would call backwards so you'll you'll define it by the thing that's pointing to things even though 95% of the data you want to display is actually in the referenced field. And so you'll you'll you'll set it up the one way set up the relationship and then pull almost all the fields out of the thing you're pointing to and just one or two fields out of the thing that's pointing. Okay. Cool. Thanks. Hi. Is it possible to create conditional statements in view? Yes. No. Maybe. I think it sort of depends on what you mean by conditional statements. You know, like I've seen some things where you'd like to be able to display a field under certain conditions. If because of the field rewrite being a full twig template that really becomes relatively simple. If you want to be able to to conditionally display rows based on things other if you can't get it into a filter or contextual filter, then you've got a more interesting challenge. Okay. At first I was thinking like, let's say if I have certain node IDs that I would like not to display because when I choose a content type, it just displays everything. Let's say, okay. You can do that. You can do that with filters. So what you would do is you would say, I'd like to filter by node ID, not equal, not one of and list the various node IDs that you want to hide. So that's at that level, it's you can do it. But if you wanted to say display a row based on the value of a field in that row, that would become more challenging. All right. Thank you. Hi. When you mentioned the advanced settings column, you said that there's not really much to pay attention to be below the relationships. They tend to be used less frequently. As somebody who's inherited several dribble sites, I'd like to say that you probably should look at one thing and that's the machine name. Because it can get very confusing going through things and seeing everything listed as block one, block two, block three. And if you just take a second to name it, relative to what the block is, it becomes so much easier for you, for future you, who doesn't remember what past you did. And for people who inherit your site. Very good point. Hi. Thank you for your presentation. It's very nice. I wanted to put in a plug for the D7 views mega row, which does everything a table does, but allows you to basically on click it, it inserts stuff between rows. So you can pull up data and view it. And it's Ajax. So it's not hitting, it's not a performance hit. And I'm wondering if you knew about it and if so, is it going to be in D8? I never knew about it and I would ask the module contributor whether they're going to port to D8 or if you're ambitious, volunteer. And then on the address a little bit of what he mentioned, it's a fun and not often leveraged piece that if you have the no results setting can interpret zero as no results. So you can take any list that is an integer list and you can basically say if the list value is zero, you don't display it. If it's a longer list and you want to toggle the other pieces of it, you can use the global math and just subtract. So you get zero for the value you want to include or exclude. So it's a fun trick. Lots of tricks with views. I probably don't know half of them. Or maybe 10%. Good morning. Do you know if view handlers are still supported by Drupal 8? We use a lot of custom view handlers. Yeah, in fact, code wise there aren't significantly different. The code base for Drupal 7 and Drupal 8 views got some extensions because of the fact that everything's an entity. But the fundamental structures and things really are relatively common. And views was sort of written object oriented before it ever got to Drupal 8. Perfect, thank you. It didn't have a major refactoring like lots of rest in Drupal 8. Hi, do you know if filters can be set up hierarchical or conditional like top level filter? Yes. It's setting defines what's... When you get into the filter section, you can create groups of filters that are either handed together or together. So I can say I want this filter or this filter and this filter or this filter and or... You can nest them to an insane number of levels. So the UI is really sort of picky about how you drag it around. But once you go through the patience of actually doing it that way, it does work. I'd like to thank you all for coming and hopefully you go get lunch now. It's like... Not sure if I'll feel...