 Hello. Let's see if we can adjust that a little bit. Probably should have done this first. Can you hear me in back? Hands? Thank you. Awesome. Okay. You're at DrupalCon. You're in room 401. It's 215, and this is ViewModes, the many faces of your content. I'm Tim Cosgrove, and I'm going to get started. So just to allow people to escape quickly, if they think they're in the wrong place for some reason, just mention quickly who this is for or who this is intended for. Themers, obviously. This is a good place for you to be. In particular, if you are slightly older Themers, if you did Drupal 5 and 6, this might actually be kind of more interesting for you. New Themers obviously, very welcome. Designers, a lot of what we're going to be talking about will impact the way that you might structure your designs for a Drupal website. Site builders, obviously, ViewModes pretty much is a site building thing, so you're very welcome here. Awesome people. If you're awesome, you're very welcome here. I apologize in advance. I say awesome a lot, and it's just this verbal tick that I've got, and that's just how it's going to go. So I apologize. And so awesome people and also developers. I'm actually, I'm kidding. I'm actually as much a developer, and also I think Themers and developers are kind of the same thing. I don't think this dividing line is very useful. So yeah, I think so. So that said, this isn't going to be a very code heavy session. There will be a little bit of code, and there will be a link to more code. So if you're wanting to get down with C tools, internals, and stuff like that, that's not happening today. At least not here. And also I'm going to be showing a lot of pictures of cute animals. And so if you like cute animals, then this is a good place to be. There will be more of that kind of thing here. So do the little about me. About two and a half years ago, I started working for Treehouse Agency. And over the course of time, Treehouse grew deeper roots and went through a process of transformation. And today, as of Monday, I am a member of Phase 2. And we're very excited about where that's going. So very happy to become part of the Phase 2 family. The clients that are basically informing this talk, we did work for the Department of Energy, EnergyGov, which we launched in August of 2011. And also work that we've done on Argonne National Labs. Laboratory, excuse me, not labs, singular. One of the work that we did really helped us cut our teeth with Drupal 7 and helped inform a lot of what I'm going to be talking about today. As for me, I'm Tim Cosgrove at Drupal org. I am a fan of being represented as myself. I don't have any alias or anything. So I'm Tim Cosgrove at Drupal. I've been a member for five years, which makes me annoying, know-it-all teenager in Drupal years. On Twitter, you can find me at Tim Cosgrove, big surprise. And you are most likely to find code that I've put up on GitHub rather than Drupal org. So I'm Tim Cosgrove there as well. So I assume some of you use GitHub. Yay, GitHub. And just remember that GitHub loves Drupal, even if Drupal doesn't love GitHub back. So, you know, we can talk about that another time. So what are view modes? Why are we here? Well, view modes are awesome. Thanks, right? Ha ha, that was funny, sure. Okay, view modes are awesome though. View modes are going to allow you to theme faster. They will allow you to write less PHP. And really the main thing is that they allow you to create easily reusable layouts. And all of that is going to help you with the other two parts. Basically, and we'll get into more detail about what I mean by this, view modes are named ways of displaying entities. So you might think of a node as a full page. And that's sort of what you think of as a node display. And you know, we might call that full or default. We also might want to have a way to display a photo and a title, and that's it. We might call that a photo teaser. You'll find I use the word teaser a lot. I wasn't feeling super creative about the names. A dated teaser, for example, with a date on top and a title, small summary, but not the full body. A subtitle teaser, which features a subtitle in addition to the other content. The important thing to remember is that these are all different displays of the same node. And it's not a special mechanism for picking and choosing fields out of something. You're looking at the node. View modes are core. There are no contributed modules that you're going to need to do this, although there are some that are very helpful. View modes have nothing to do with views. This is a confusion that we run into. View modes are not views, although they work very well together with views, and we'll be looking at that. In fact, I might go so far as to say it'll make working with views much better for you. View modes are built into all Drupal 7 entities. So nodes, obviously, taxonomy terms, users, the rest are slipping my mind, but each of those have view modes that you can use to display that entity in different ways, in different situations. For now, I'm going to be saying node a lot. That's partly because I'm an older Drupal guy. I only go back to five, but whenever I do say node in this presentation, pretty much in all cases, you can also assume that what I say applies to any entity, not just nodes. So we're here because you have problems. Don't you love hearing that? Isn't that great? You might not know that you have these problems actually, and I could be nicer and say maybe that you have habits that you might want to look at and maybe think about doing things a little bit differently. You might want to break these habits. So one of them is that you probably have too many templates. You probably have way more templates than you need. Your template PHP is probably out of control. It might not be. You might be really all tied down, but most likely you're writing more in your template PHP or whatever includes that you use to take care of that than you actually need to. And you're using views to do theming. And that that's actually a problem. There are better ways or different ways. Let's not value judgment things just yet. There are different ways of doing that and you might want to consider doing those different ways. So just again to summarize, you use too many templates. You write too much PHP. And don't take this personally. I mean I'm you know, this is an abstract view. You use views to do theming. These are your problems and you don't have to do that anymore. You don't. So that's what this talk is going to be about is basically getting you to look at different ways of doing things. So just a little bit of history to show us why we are where we are now. How many people have worked in D6? And how many people did not use CCK in D6? One. Congratulations. That's awesome. Okay. So that's good. Did anybody remember hearing about build modes in CCK 6? Yeah. Me neither. There's a few of you. And you're more learned than I, which is great. So build modes were part of CCK at least in 6. I didn't do the research to go see if they went back to 5. And what they were, similar to what I said earlier, they were named ways to present different displays of nodes in different contexts or areas. If you managed to enable the UI, it looked something like this. It gave you the fields that you defined in CCK and it stacked up the build modes that you had defined. And it had a couple problems. And this is nothing against CCK. Those guys are giants and I'm a little flea standing on their shoulder. But there were nevertheless problems. When you used a build mode by default, all the fields were labeled. And there was no admin way to turn that off. And similar to all CCK, the fields were just sort of shoved in there under the body. And you had to jump through all kinds of hoops to make that not happen. Again, you might not be aware that these are hoops. But they're sort of hoops. Also, in the build modes, you couldn't trim the body. You kind of were stuck unless you did some crazy pre-processing, which again, we'll talk about pre-processing. So we needed more than that. We needed more than what CCK gave us out of the box. We started using multiple templates for all our nodes. And we wrote a ton of pre-processing code to get things into the positions that we wanted to and to modify them a bit. And we used views for node output. And that's specifically for the theming of the nodes. We needed to. We didn't have the tools that we needed to do it another way. So Drupal 7 introduced view modes. Yay! I was looking for like a neutral hollywood kind of thing. And you know, pretty. So view modes again, these are all the same. This is all an article type. It's a slightly enhanced version of the vanilla article that comes in Drupal 7 Core sort of standard install. And again, we have the sort of node view. We also have this photo teaser again, which is, you know, just photo and title. This dated teaser. And you know, just showing you these different things. The important thing to remember here is that these are all the node. There's no special mechanism happening here. There's no pre-processing. There's no templates. There's no views. None of that is happening. This is just sort of standard Drupal core way of producing output for nodes. Has anyone read the Phantom Tollbooth by any chance? It is a fantastic children's book and you should all go buy it after my session sometime. And this character, this very kind of weird looking photo is a minor character called the Dodecahedron. Dodecahedron is a 12 sided platonic solid. And this character had one of those for a head. And when he was angry, he'd sort of flip his head around and show you his angry face. And when he was sad, he'd sort of turn his head around and show you that. The point being that he had all these different sides to him, but it was always the same person just showing different aspects of himself. Maybe a more conventional metaphor is a jewel, a diamond. You sort of hold it in your hand. You see all these different things as you look at the different facets, but it's still the same jewel. And similarly, that's how I want us to think about entities and nodes with respect to view modes is that you're really viewing the same node just from a different angle perhaps or a different way. View modes are Drupal 7. Are there people still working primarily in 6? Okay. Please join us. I understand that there are budgetary and organizational reasons why you might still be primarily in 6. It is so much better. It is, yeah, better? Drupal 7? Yeah. I mean Drupal 6 was better than 5. Again, so much better. But I really encourage you to move whatever mountains you need to get your site or your organization onto 7 because it's a happy place with puppies and rainbows. So view modes. How do we use view modes? The sneaky thing is you're already using view modes. You just may, you may not know it, you may know it. So this is a managed display page for a node. And these little guys over here, these are view modes. Default and teaser. You are probably very familiar to anybody who's done Drupal in the past 4 or 5 years, maybe even longer. So there are built in view modes in Drupal. Default and teaser are active by default. These view modes apply specifically to nodes. There are different default things for users in taxonomy terms. This is specific to nodes. You also have full, which is the named way of doing the full page node load. You have an RSS view mode. So if you want to display your node differently to an RSS feed, you can do that. Search index. If you want to expose different information to Drupal's internal search indexing mechanism, you can use that. And similarly, search results. If you use Drupal's core search results, you can format them any way you want. And through the admin without having to do any of this crazy jumping through hoops. So how you turn these on, you may never have clicked this open. You might have. Down at the bottom of the managed display page is this custom display settings. You pop that open. And those are view modes down there. And if you want to style things specifically for full content or for RSS, search index, whatever, you just click this little checkbox and they'll be made available to you. If you don't do that, then Drupal will fall back on the default. So that's where those are available to you. So let's look at this full article thing. So this is the standard page display of an article. Let's just break down what it is exactly. We've got a title. This is Rocket Science. Sorry. We've got a subtitle. This is a little custom text field I added. Nothing special. We've got user. It's very standard looking stuff. Date, image, body. And this is the managed display page for that view mode, for that full default view mode. And so let's just break down what we've got here. We've got the default fields that came with the article type from Drupal. We've got my little subtitle custom text field. It's just a standard text field, Drupal 7, query, field API. We've got extra fields. We've got title and author and post date, which is the created date. It's when I ended up calling it. What are these extra fields? Extra fields are this not very well known thing in Drupal 7 field API that you implement them in code. And what they allow you to do is to expose non-field information in the admin to be ordered with field information. So you can take things like title and date and author that you probably actually care about when you're creating your nodes and allow them to be sort of dragged up and down with the table drag and exposed. It's an alternative to doing things through pre-processing, which is how this stuff is traditionally done and traditionally being the keyword there. And I think it's better personally because you can just do it in the admin, do it all at once, and not have to go somewhere else in pre-process. You will leave here with an example of how to do this. I didn't want to dive into the code for this because it would have taken half the session and it's not worth it. But you will have a URL that has a downloadable module that will show you how to do this. So just for the moment, just be with me that the title and the author and the post date are rearrangeable in the admin at this point. So we got our node. Yay. So what? Why is that awesome? What's so special about that? This is a bunny. I love Drupal a lot. And so I named my buddy node tipplePHP. She's really cute, you know, she's kind of cool. And one day I got my bunny a friend and I named him node article tipplePHP. You can probably see where this might be going. Pretty soon I had more bunnies. And even more bunnies. They just kind of kept coming. And you know, they're cute but don't be fooled. These things will mess you up. Bunnies are scary. So has this kind of thing, has this happened to anybody, anyone? Node block, node blog, node client, node, node, node. This is a small project. This is from something we did two or three years ago before we knew better. There's like 12 templates there. You don't have to do that anymore. You just don't. So we generated this layout and it's not a complicated layout, but we told it how we wanted things ordered without touching the template. You can do all your node types this way. You can arrange them in the admin. There isn't even a theme-specific node template here. We're using core. And you can do that now. You don't need to have the stack of node-specific templates anymore. If you really want to, that's great. You kind of probably just want to have one bunny. It's easier to take care of one bunny. It doesn't get out of control. Especially if you try to customize your bunny. And do things to it. Now imagine just one bunny that's not so bad. You got to hold him down and glue the thing on him. But if you had all these different bunnies and you had to make a similar change to all of them, you're going into each one of those templates and it's just not very constructive. They're cute. Don't get me wrong. Too many templates and by inference too much PHP. We're taking care of those problems. We're starting to get somewhere. So that's great. We've got our basic node. But we do want to be able to build all these other types that Drupal doesn't automatically give us. We want our photo teaser and our dated teaser and our subtitle teaser. We need to be able to configure those. We need this. We need to actually have those in the admin so that we can access them and define what they actually display as. So we need to create custom view modes. How do I add more view modes? I'm going to show you three ways. Very quickly the entity view mode module, the display suite and code. Yes. I'm going to show you some code. Entity view mode, great module. Very simple. It does exactly one thing. It allows you to define new view modes for your entities. That's all it does. It's very lightweight. The one caveat with entity view mode is that it keeps all of your view mode definitions in one variable. So if you use features which I imagine quite a number of you do, you're going to get all kinds of crazy dependencies if you try to use this with features. If you're not using features, rock on. It's very simple, very lightweight. Go with it. Display suite. How many people use display suite? Some of you. Awesome. Display suite is great. It's extremely powerful. It's four modules, many, many tools for controlling your display and presentation. Really great stuff. And it has a better way of exporting your view modes. So if you do use features with display suite, those go together extremely well, you won't get the dependency problems. The thing with display suite is it does a lot of things. And if you turn it on, it's going to do, I mean, it's not going to transform your site automatically, but a lot of stuff will be made available to you. If you want that, that's great because it is a really great module. But if all you're wanting to do is add a couple view modes, then this probably isn't the way to go. And finally, the way that I personally tend to do it, but your mileage may vary, defining view modes in code. Scary. Oh no, it's code. My coworker JR actually has five of these in his living room, he told me. This is a goblin shark. Beautiful, beautiful animal. And we've scared the bunny. Sad. But you know, it's just a little bit of code. It's not a big deal. We're just going to do some code. So this is how much code you have to do. It's really not bad. So what you're going to be doing if you define this in code is implementing hook entity info alter. And specifically you're altering the entity info for the node and you're adding view modes and you just create a machine name, photo teaser. It can be anything it wants provided it's a normal machine name. You give it a label and custom settings equals true means that it will be on by default. So that little list of check boxes that we had you don't even need to bother doing that. It'll just be on. That's it. Six lines of code. It's really easy. You just throw that in a module somewhere. That's fine. And once we do that, we have our view modes and we can sort of get up and running. So let's take a look at this one down here. Again, I called this subtitle teaser. And let's just break it down again and look quickly at what it does. It's got an image. Notice that the image is if you're thinking sort of in markup it's above the title technically. We've got our title. We've got our subtitle display. And we've got a trimmed version of the body. And also just notice that this doesn't wrap. Not a big deal. This is not rocket science but it doesn't wrap. And I'll show why that's actually relevant. So this is the image display page for subtitle teaser. Notice that we've selected that. We are in fact working on our new view mode that we've defined. Notice we've put the image at the top. You can start doing this. Once we implement the extra fields. There's a couple little tricks I explained in the code that I'm going to give you. You can start putting stuff above the title which is we found to be a really common design case that people want to put an image above the title or the date perhaps. So let me cut this guy. Field group. How many of you use field group? Yeah. Field group is great. Field group used to be part of CCK back in six. It's its own contrib module now. It allows you to create field sets, divs, other containers around groups of field output. And incidentally you can also use it on the admin side and it's super useful if you have a complex node type with many fields you might want to group those together to make it easier on your clients because otherwise they're just looking at field soup. So we've got our, I just made a div. It's very simple and it wraps up those three things. So it wraps the title, the subtitle and the body. And there we go. That's it. Incidentally, all these settings that we are creating, you're probably going to want to export these at some time. How many of you use features? You're done. Sorry, I should have kept the slides up with me. You're done. If you use features to export your content types, this is all already happening. All the different view modes for your content types are being output and they'll just come back in. So you don't need to even think about it really. So we've got this. Yay. What might we do with this? One idea is a node reference. I'm making you guys raise your hand. I'm sorry. It's good. It's exercise. How many node reference? It's like everybody practically, right? Like it's a super handy module. So this is an example user profile page. And it's pretty straightforward. That's standard user profile stuff. I got to go bowling in the White House. That was a really cool perk for working on DOE that was neat. I added a bio field, nothing special. And I added a featured content field and I actually made this a node reference thinking partly just for this use case for explaining. Thinking that an author might want to, instead of having their content listed automatically to choose to highlight, I really like how I wrote this article. And so this particular thing is a node reference. And this is our managed display. Notice that there are view modes for user as well as nodes. They're different. And we're just going to work with the default case. We're not going to do anything crazy with the view modes in this case. And I really just want to look at the actual node reference field and specifically what you might choose. You can display node references in a lot of ways. You can choose rendered node. And then in the settings, you just pick subtitle teaser. And you save. And there you are. It's dropped in. You don't have to pre-process. You don't have to do any hoops or anything. It just drops right in. So why is that awesome? You still only have one bunny. No templates were written in the making of that profile. No pre-process code was written when we did that. Everything, your tool set, I like to think of my template PHP kind of as my tools. And I tried to keep it kind of to a minimum and keep it in good working order. And you're keeping things kind of simple, which is good. So, too many templates. PHP, we're still doing good. You don't have to do those things anymore. I mean, again, you might want to, but you don't have to. Just probably talk about views. Isn't Colorado beautiful, by the way? It's like crazy beautiful. I've only been here once and it's ridiculous. Anyway, views. So we really should talk about views and why you are maybe doing too much views theming. Take a look at these. You can think of these as blocks. The thing on the left is a page. Looking at this, how many of you would say views for building things like this perhaps? Like a related content list block perhaps like a list of recent features, something like that. Yeah. So views is really well suited to selecting those nodes. It's really good at that. Views is a visual query editor. It's basically a way for you to construct complex queries of your content without actually having to dig into the sequel. You might want to reconsider. Why might you want to reconsider using views to design and theme your output? This is separate from the selection process of the nodes. We're just talking about theming for a moment. This is what happens. This is what happens if you use views to theme your outputs. Has this ever happened to you? Anybody? Again, this wasn't a very big project, this project. That's kind of too small to read even. What's one of them? I guess I can sort of look at it. Views dash view dash unformatted dash dash view dash homepage dash banner dash dash block dash one dot tipple dot PHP. That's easy, right? You're never going to mess that up. You're never going to not know where to find your theming, right? Yeah. The other thing about using views to do your actual display, your theming, is that views displays aren't really portable. You can export them, but if you want to use a display that you've created and move it from one view to another, you're kind of SOL. And even if you, sometimes once you've split, if you want to make a similar change in two of your views displays and they've diverged, they're specific to that display, you have to go into each one. It's kind of a pain in the butt. So this is maybe, how many use the fields output in views? How many use, mostly use the fields? Yeah. I mean, we do. We did. Historically, we needed to. So you have your fields and you go through that long, long list of all the fields in your entire system and you pick out the five that you want and you hopefully got the right ones and not some weird variant that you don't really understand what it is, but it's there. And then you fill in all this stuff and it's just easy, right? Views. It's easy. You don't have to do that anymore. Okay? Again, if you want to, if that's your thing, if it spins your bow tie, rock on. But you can use view modes to output your views results. Now I will show you how. We've got the little format and field section and what we are going to do is click where it says, well it already says content. Maybe previously it would have said fields if that's how you're used to working. And you click on that and you select content and not fields. It's good. And then you select the options and you pull down the view mode that you've already created and defined and done the CSS for and you select it. And then you get this beautiful sentence, the most beautiful sentence I've ever seen, which is the selected style or row format does not utilize fields. It's poetry. It's so good. And you're done. You know? This is this views page that I mean I can't remember the criteria I came up for deciding which these things were. The important thing is this is a page of views, maybe it's recent hot features on your site. This is the subtitle teaser. We already defined this. We didn't have to do anything. Once you define it, you can use it over and over and over again. This makes using views a lot faster and a lot less painful. It's good. It's a really good thing. So too many templates, too much PHP, too much views formatting. We knocked them all off. High five. Good time. Good dog. So other uses that you may come up with for view modes. Like I said search results is a view mode. So if you are using Drupal core search, which not as many of us do these days, but if you are it's very capable, and you can output your nodes in a specific way by activating search results and it can be different per node. You could have a photo gallery and that puts out two or three of the photos in your search results. You could have a small video for a video note. However you want to do it. Again, search index is also a view mode. So you might want to expose more information to the search index than you actually display to the user to make a broader range of search results return an item. And this allows you to do this. And also it can be messy because the search index doesn't care. The search index is just about finding content. Custom blocks and functions. Let's take this a little bit contrived example that at the end of an article we want a related content block, say. And you know, this is our block and we don't as themeers, as site builders, we don't necessarily even care about the logic. We're going to give that to our developer. She's going to come up with, you know, whatever set of criteria to decide that this node is related to the other node. That's not our concern. And conversely it's not her concern how it gets output. All we have to do is tell her output this node with a teaser. And we're done. You didn't have to theme that. You didn't have to do anything. Provided that view mode already exists, it just outputs again. And that's so much better than having to theme things similarly over and over and over again. This is a more actual real world example. This is from EnergyGov. It's a news blog aggregation page. I highlighted the nodes on the right, the contributors, although, yay, Secretary Chu, that's awesome. But the first two columns, those are all the same node type. And we're actually, this isn't views, we're using Bean, which I'll mention again briefly a little bit later. Bean is basically a way to easily build lots of custom blocks that might have queries in them. But again, these are all the same node type. They're just displaying differently. You know, we've got this one view mode that has this large image and the title and the date. The other ones have the date above and a small little teaser. The ones down below have no teaser. Those are all different view modes. And again, it's all articles, it's all the same content. What if you change a view mode? What if, you know, your editorial team or your business team or whoever come and say we really need to have a date in all these places? And, you know, okay, so we drop in a date in this view mode definition. And boom, there it is. Boom. There it is. Boom. It all happens at once. You don't have to go into each of these different places and change this template and change that view and have all these different mechanisms for doing those changes. You change it once. It's good. Yay! You know, yay, happy. Of course, there's always gotchas. There's always problems. You know, you're not getting a free lunch here. You never do. So design issues. Consistent design is pretty key to using view modes effectively. And what I mean by that is grid based design for one, but also design that makes use of repeating elements. So these are, I apologize for the sort of low JPEG quality of these things. These are from Ggov. And simple, you know, these are blocks with little thumbnails and a title. This is a sort of different setup, but it's still the same size thumbnail and a little title underneath it. That's a CSS problem. We don't need to make another template for that. This is, again, a similar thing. Thumbnail title right next to it. So the more that you can get reusable elements like that into the design, or you can encourage your designer to do that, the better. That said, there are some inconsistencies here. You notice there's couple, maybe they're taxonomy terms, or it's the user associated with that article. Those are inconsistencies and those are going to bite you in the butt. So if you can encourage your designer to let go of those, or your business people to let go of some of those, it will save them time. It will save you time. It will save everybody money. So when you're reviewing a design and thinking of how to build it, looking for inconsistencies like that is going to help you a lot. And pushing back, if that's possible in the way that you work on those things and saying maybe you want to do this a little differently. So you do need to watch out for that. Honestly, your designer should be doing this already. If your designer's not doing grid design, if they're not using these sort of repeatable elements, then you might want to educate them. Or something. You might want to do something. Views issues. Specific to views. This doesn't work with tables. If you think about it, tables are inherently a collection of fields and that's kind of what you want from a table. This also won't work if you're trying to output multiple entities, or rather fields for multiple entities at once. Remember the view mode is you're picking a whole node, say, and displaying it. So pulling things from multiple places doesn't really work. You could maybe try to re-architect your things with some judicious node reference or user reference information. But if you're really pulling from many different entities using a lot of relationships, you're probably still going to have to go with fields. Theming issues. Consistency is good. And consistency is also kind of boring sometimes. So you might have to give a bit in order to have a design that the designer's happy with. You might have to give some. You're not going to be able to make everything regimented into tiny little boxes necessarily. And you might not want to do that either. Also, I keep saying this, you don't have to do that anymore. But sometimes you do. Sometimes you're going to have to pre-process something. Sometimes you might actually need a separate template. You might. And there's not going to be, this isn't a magic bullet. Sometimes you got to override. I'll let you on a dirty secret. I did some pre-processing in my mock-up little site. There's some pre-processing in there a little bit. There's no special templates, but there is a pre-process. The thing is that the way that we were given the way that Theming was presented to us in five and six and what we actually needed to do forced us to do all these other things. It forced us to use pre-process. It forced us to use different templates for every single node type and in some cases to use views. And we had no other options. And so it became the way that we theme. And it still can be the way that you theme. It just doesn't have to be the default way that you theme necessarily. You might be more comfortable theming that way and full respect. That's great. But you don't have to do this by default anymore. You don't have to just assume, oh yeah, I've got a node reference. I'm going to pre-process everything. And I'm going to have 20 templates for all my node types. You don't have to do that necessarily. So in summary, ViewModes. They will help you prevent an explosion of tipples. They will make Theming views less painful. They will get you out of writing PHP or at least as much PHP or at least less interesting PHP we hope. And really ultimately they create reusable style for your entities that you can use over and over again. They basically help you theme faster. And I think that's something we all agree is a good thing. So your loved ones miss you. Your children, they miss you. Your puppy misses you. Your panda, your panda misses you. So stop wasting your life doing things that you don't necessarily need to do. Unless you enjoy doing that in which case rock on. But otherwise, please use ViewModes. These are some resources. These are just the three modules that I talked about in here. You don't need to write this down. What you do maybe want to write down or just bookmark right now is bit.ly. Sorry, bit.ly slash view dash modes. And that will take you to a little site on, it's on treehouseagency.com right now. I'm sure it will move to phase two, but it will always point you in the right direction. And that is explanation of the resources, some additional material, and in particular a detailed explanation of that extra fields thing that I talked about at the beginning. Which it's too detailed to go into in a session of this length. But there is an explanation and also a module that you can use to get that up and running for yourself. There's also a couple buffs that are not directly ViewMode but they're related. Entity field query is really, really awesome. How many people do stuff with that in here? Just out of curiosity. Yeah. Entity field queries are really awesome. And there's a buff tomorrow at one o'clock in room 206. And then beans. Anybody using beans yet? Okay. Beans are awesome. I say awesome a lot. Beans are basically custom blocks that you can create. It's a little like node block but it's not really like node block. And there's a buff on that as well tomorrow at 2.15 in room 206. And there's all kinds of ways that ViewModes are friends with these two kinds of techniques. So if you're interested in what I'm talking about, these are good places to go. I'll also be at those buffs and if you want to ask me questions about that, please feel free to do so. So in conclusion the takeaway, ViewModes are awesome. Thanks. So we've got time for questions if you want to answer any. I'm sorry, I just love the bunny. I'm not a Photoshop guy but I really had fun making that. If you do have questions please come to the mic at the center of the room so that the people on the video can hear you. Good. How are you? First off if you're not on reddit.com you're a natural redditor. I like some rage comics. I do. One of those that has kind of exploded with TPLs and we have just a ton of conditional... Can you lift the mic up or speak into it? We have a lot of conditional logic that has turned into a lot of TPLs. So do you have any suggestions about how to do something conditionally with related nodes, node references that will help us to avoid some of the TPL madness? Well, you could redo the site. That's not the right answer that you want though. The question was there's a lot of conditional logic in their theme and many, many TPLs and how might we go about reducing that. It does work better if you start from the beginning with this in mind which is not a great answer actually. I would start maybe looking at similar cases where you might be able to reduce things down. People get really caught in the way that their content is structured currently and sometimes it's hard for them to see that they could maybe structure it a different way but so maybe looking at some of these many TPLs and seeing which of them actually could be conflated to reduce the number of things that you're working with. That's what I would probably suggest but like I said it really does work better if the design and the information architecture has it in mind from the beginning to be consistent. Does that answer something? Okay, thank you. So I was wondering in the view modes in your templates you can do like if teaser then do this, if not or full page then do this. With the added view modes could you do if photo teaser in your templates? You could do that, yes. It's one of the variables in your pre-process function so those are available to you. I do do that in pre-process. You could put that logic in your template as well. Really, really recommend that you put that logic in the template PHP itself in a pre-process function but it is an available variable for you, yes. Yeah, it's definitely available to you. Thanks for your awesome session. Thank you. How did you manage to have the fields author and available on the managed field display UI? That's that extra fields thing that I was talking about. The question was how do we make the title and the author in the post-date available in the fields UI and that's the extra fields thing that I talked about at the beginning. Again, it's a fields hook field extra fields and if you go to the URL that I showed there's a long explanation of how to make that happen for you and how to both make those available to the managed display admin UI and how to output those into your content. You could also use DisplaySuite, yes. Again, DisplaySuite's great. This is just a different way of showing it. Yes, I can show the URL again, absolutely. That was the question. We'll also tweet this. I'm sure my company Treehouse will tweet this. I'm sure Face2 will tweet it. as well. One of the questions earlier was if you're in a position where you have a lot of TPLs how can you leverage this on an existing site and I just want to also add a tip to the answer that Tim had. I work with Tim by the way. There is a way to easily switch a theme. My suggestion to add to his answer is that take a lot of the CSS and stuff that you have and just start a new theme and use, I can't remember what the hook is but it's like hook build something. I'll get it to you later. You can just switch the theme and as you are rebuilding the new theme then use the view modes in that case. Once you've gone through your entire site for your various content types you can switch based on content type of what have you. Once you've swapped them all out and using the simpler view modes and simpler templates then you can get rid of the old theme and you've slowly transitioned to the new view modes instead of having to destroy what you already have and you can keep your production site going by just starting with the same CSS, the same JavaScript you may have in your old theme but use the base set of templates and then just create a quick module to use and I apologize for what I can't remember what the hook is but it's hook underscore build underscore something else and just switch it by the content type and then as you're putting the view modes in each content type you say okay I'm going to use the new theme for this one because I'm using view modes for that and then once you get them all switched over you can get rid of the old things. Okay I'm going to ask you to write that up as opposed to Frederick. Actually thank you. That's Frederick Mitchell. He works for phase two also. You have a question? That's the delta module? Okay. Okay so just to repeat that the suggestion is one other way of doing that would be to use the delta module along with perhaps the omega theme or another theme to do something based on context using the context module I'm assuming. Delta module and context to do theme switching so that you could have some of your site in one theme and other parts of your site in another theme. That's a good suggestion thank you. Okay. It gives you a second set of settings. Okay if people do have things to say I really welcome it but I would love if you'd come to the microphone so that everybody can hear you. Does anybody else have questions? Yeah please. So I'm totally on board with view modes. It's awesome to get session. Thank you. When do you or do you ever decide to still use like I feel view and views over using a custom view mode? That's a very personal decision. No it's well of course are the cases I talked about like if you have a table view you're going to have to use fields. If you have multiple entities being displayed at once. You also if it's a really special display case that doesn't match anything else you have in your site that might be a reason to go with fields. The real win of view modes is having these repeatable displays and so if someone's really married to this very specific layout that you don't have in use anywhere you might not want to do that. I've just remembered I'll tweet this also. If you wouldn't mind rating me they want to rate me or they want me to tell you to rate me. So if you feel obliged but yeah so if you had a really specific use case then I would say maybe stick with fields. If you remember the view modes being displayed at the top of the managed display page we've done sites where we end up having like 30 of those and that's not good either. It's not good to have too many of those things. We end up actually rather than using 7 for the admin theme we use Rubik. It's pretty much specifically because it has a different mechanism for dealing with that. You don't want to have too many view modes either. That can be the same kind of suck that you get out of having 15 or 20 templates so you kind of want to avoid that as well. Yes. View modes are tied to content types? Yes they are. Is there a way to share between content types? So actually they're not strictly tied to content types they're tied to nodes so well let me take a step back. That's a really good question. The names so say I have my photo teaser that view mode is tied to the node entity the sort of abstract node entity so when you create that it's available to all your content types. That said you do have to go into like your article and your photo gallery and define photo teaser for that. That's actually a good thing because it allows you to have different node types with the same view mode so for example your views don't need to worry about content type anymore. You can just say I want a bunch of stuff with a given taxonomy term. You don't have to worry about the field output anymore. You're just displaying so like you could have things that are tagged you know awesome puppy. I wish I had a better thing than that but so all your nodes tagged awesome puppy that are in a like say the search results and so the video could have like a thumbnail of the video and the photo gallery could have like two or three thumbnails and the article could have an entirely different display but because those displays are all functionally being used together you can do it that way. Does that make sense? Sorry real quickly the hook is hook custom theme. Thank you Frederick. That's the hook he was talking about earlier. You're still gonna write a post about that I hope. Yeah. Gonna make you work. Anybody else have any questions? Well I appreciate your time. Thank you and enjoy the rest of DrupalCon. Thank you.