 Good morning everybody. In only one person. Good morning everybody. That was just great. Thank you. Heartwarming. In traditional DrupalCon fashion, we're starting a little bit behind here today. Also in traditional DrupalCon fashion, there's a lot of information to cover here. So on the one hand, I'm going to try and move through things quickly, but on the other hand, especially since this is a session that's for people to start to understand the possibilities here, I really want you to interrupt me with questions if you have them. Just stick your hand high in the air if you have a question. The only thing is, I need you to get to one of the microphones to ask the question. And it's not because I can't hear you and it's not because our friends here and the audience can't hear you, we're all just fine. It's for all of the millions of people who are watching breathlessly on YouTube. Breathlessly. All right. Welcome to Panel's Display Suite and Context. Oh my. How many people here are familiar with The Wizard of Oz? Excellent. Oh, you know, I'm never sure which cultural references will work and which ones won't, so I'm happy this one will be okay. So first of all, an introduction. My name is Campbell Vertesi. I work for Forum One. And I've been a Drupalist for nine years. Still scary every time I say that. I've been lucky enough to work on sites for big nonprofits and non-government organizations and some government organizations. It tends to be my specialty. So I do sites for people like Mozilla, the German Marshall Fund United Way. The tools that I'm going to be talking to you about today are absolutely my bread and butter. They are as much as I can give credit to specific modules for making my life easier. Being able to combine these modules intelligently is really how I make my living. So first of all, this is a confusing area to talk about. There are lots of big, complicated modules involved here. There is the core block system. There is context. There is panels. There is display suite. And there are extensions and customizations on each one of those. Things like panelizer, field group, context, plugins, and lots more. It's actually quite a lot for you to get your head around. There's also a bit of a turf war involved in layouts. Layout is the job of the themeer, right? Hands up, everybody here who is a themeer, primarily. I shouldn't put my hand up. Hands up, everybody who is a coder, primarily. Yeah, interesting thing about layouts is that it kind of belongs to both of us, so we fight about it a lot. People get legitimately upset about this stuff. I'm actually going to give a whole talk about this on Thursday morning at 10.45 in the big room. I'm going to kick some themeer butt. All right, all of you coders, make sure you're there on Thursday morning. Get out of my session. I don't want your kind here. Adam Gerrand, everybody. Little hand. You're going down. That's the Batman voice. Right, back to this talk. Part of what's tricky about this is that there's a lot of people out there who are going to tell you what you should use and how. This is an open source community, which means that in open source, opinions are like belly buttons. Everybody has one. There are lots of blog posts and articles about how to do layouts exactly right for every single site using just one of these modules. In fact, just last week there was this reddit post about exactly this subject. I thought I had to include at least a screenshot of it, but we're going to look at some of the top comments here for a sampling of the kind of advice that you get. So, AB Web US, right? Custom theming plus hook, block, list and info and alter as may be needed for all the more complex layout logic. So this guy, all he uses is core blocks. Hands up, everybody here who does their work with just Drupal core blocks. Hands up if you are AB Web US. I mean, I've got to check, right? Right below him, Stankylizer Fart, I love it that we have to say this with some dignity, right? Stankylizer Fart says that display suite seems to do about 80% of the heavy lifting for him or her. So it makes sense for me to keep as much there as I reasonably can. Hands up everybody who uses display suite, primarily. That's interesting. When we get to the gang war later on, the block guys have better bring zip guns. Dubui, Doud Boil likes to do things with custom code, with Tau specifically, one of the great base themes. He finds display suite to be slow. And Voice of Experience says that he prefers panels. Per component caching and the ability to fall back to DS means sites are easy to maintain and very fast to use. Hands up everybody who uses panels, primarily. Hands up everybody who thinks that panels is fast. I like you. Right, it's an unusual thing to say about panels. The problem is that on the internet everybody has an opinion and everyone thinks that they know what's best for your site. And in reality there's only one person who knows all of your needs perfectly and who can advise you on exactly what to do and that's me. But seriously, since Drupal is an open source community, there's lots of advice about how to do layouts right and none of it is going to be right in every circumstance. So my objective here is to help you understand the major tools and when to use them, what they're good at, what they're bad at, what are the edge cases that they can sort of manage. And the end point is that you should build your next website somewhere a little bit safer than beside a tornado that you can make some intelligent decisions about how to mix and match. So I'm going to help you make sense of the crazy world of layouts in D7, but before we go it's important to remember that the goal is not just something that works. I know that the goal for most people who are starting out in Drupal is just something that works because it's complicated, but we actually want something that's a bit more than that. So the objectives that we're going to evaluate with each one of these systems, not only what does it do and what does it not do and what does it do well and what does it do badly, but we're really interested in having it minimize complexity. We want to avoid unnecessary modules whenever possible. Every time you add a module to your site, you're increasing the amount of memory that you need to run the site. You're increasing the amount of complexity that you have to deal with as a site maintainer. There are lots of downsides to having unnecessary crap running, and we're going to really try to avoid that. Also, complexity in terms of the administrator interface is something that's really important to consider. We're going to try and use systems that make it easy for you to have repeatable patterns so that when someone else is looking at your website, they don't have to guess on every single page layout how did this person build it, what bizarre Love, Crafty, and Horror combination of modules did this guy use here. We really want repeatable patterns and maximum transparency so that it's clear and obvious for the next site maintainer to understand. We want to use repeatable patterns and maximize transparency so that whatever you do, it's clear and obvious for the next site maintainer to understand. We also want to incorporate cats because we're from the internet, and that's important. So we're going to start with Drupal core block system. I'll move pretty quickly through this one. So who here has used core blocks? I am surprised by everybody. Who here has not used core blocks? Okay, that's actually very interesting. I was expecting those guys to be not awake. Can I have a volunteer to tell me what is the core block system like? Actually, just start shouting out individual words. That's totally cool. Fast, slow, overwhelming, that's a great one. Easy, unwieldy, that's even better. Limited, backward workflow. Yeah, core blocks is one of the things where we talk about building from the roof down. Interesting. All right, so core blocks is the right place to start for most people. Obviously, it's included in Drupal core, so most of us get a chance to use it. So it's very simple. I'm going to run through this, but in your theme, you list your block regions in your themes info file. You just mark out what are the names of these regions, and then in your template files, you just put little placeholders. PHP, print, sidebar, left. Totally easy to understand if you can understand the surrounding HTML. In your code, you make a list of blocks that you're going to have in hook block info, and you write the actual code to make them appear with hook block view. It's fantastic, it's easy, it's simple, it's all done in time for T. All you have to do is deal with the block admin form. So this is this real screenshot from a real site that I built this year. More than 300 blocks all listed on one screen. I think we're, oh, I see we're missing a little bit of one side here, but we're somewhere between the E's and the F's here. 300 blocks on one form, and it's drag and drop, and it's easy, right? Maybe we won't have T quite as soon as we thought. But that's okay, because it's great for complex site maps with lots of different layouts, right? Well, only if you're okay with having a lot of theme regions. This is the .info file from Bartik, one of our core themes that's supposed to be the demonstration of how you do this. Bartik does a good job if you only have one page layout ever. It has 16 block regions to do that job, so a simple use case done well is more or less 16 block regions. You had better be prepared to work with a lot more if you're going to build any kind of complexity or complex varying layouts into your website. I would not advise T at this point. Yeah, is that legible, right? Yeah, it's legible, good. So this is the only system I'm not going to bother to demonstrate, because we've all used it already. We're just going to jump right to the pros and cons. In the pros column, it's in core. That's actually a big deal. As far as reducing complexity and making things transparent, it really doesn't get any better than this. Core modules only is a valid legitimate approach. Because it's in core, it integrates well with lots of different modules, especially including views. This is another important note. It's one thing to produce a fantastic custom layout module. It's another thing to have it work with anything else in the ecosystem. It's in core, but it's in core. I really started to run out of pros here. Cons, it's unmaintainable in the UI. It is difficult to maintain in features or in code. This is a bit of a tricky one. You can export some block information into features if you use the features extra add-on module, which works most of the time. There's no dependency detection. There's no guarantee that the blocks will be there because the theme regions are going to be there. If you are actually declaring your blocks in custom code, it's an even bigger pain in the butt to not have an easy way to export changes. I've actually seen shops that do core blocks only, and they disable the entire admin interface for blocks because they're so worried about somebody, some developer going in and moving a block to a different region. It's just really hard to keep track of. It's not particularly flexible. I've lost my mouse cursor. It's not particularly flexible. It is hard to add theme regions or layouts to an existing theme without a fair bit of work. Once you've built 90% of the site and the client says, hey, I want this other cool page that's totally critical before launch, you actually have to do quite a bit of re-engineering. Flexibility is one of the great strengths of all of the other systems that we're going to look at today. I think it's one of the primary failings of the block system, and so we're going to get a good sense of how this falls down. That's right. Only simple display logic is allowed. So core blocks, we all know it will let you choose whether your block should display yes or no based on content type, based on path. You can even include some complicated logic using PHP if you want, and you can even do that in the UI if you want to go to hell. We have very few commandments in Drupal, but code in the database is definitely a big one. The big problem is you can't reuse blocks, and reusing regions on multiple pages gets really difficult. What if you want that user login block on top, on the front page, but on the bottom of a totally different theme region on another page? You actually can't do that with core blocks because you're building a duplicate block and therefore doubling what you have to maintain. So in our rating system, assuming that you can get core blocks to do what you want, it's definitely simple. So we minimize complexity, but it's not particularly transparent, and it's very hard to repeat patterns, and it's actually even hard to notice the patterns that you should be repeating when they already exist. In fact, the complexity goes up a lot if you have tricky layouts. If you have a lot of theme regions, if you have, for example, 43 of them, which I saw on a project two years ago, 43. How do you even work with that? So even though this gets a thumbs up, it's important to note this is a Garfield thumbs up, so it's a little bit meh. All right, now we're on to some of the non-core stuff. Context module. Hands up, who here knows what context module does? Good, I'm impressed. What are you guys doing at a session about this? All right, call out some words for me. What does context module do? I can wait. Flexible. You just knew that I wanted to hear that. All right, context lets you apply different behaviors on your website depending on contextual information. I had a site that had four different URLs and applied different color schemes and block layouts depending on what URL you were using to access the site. It sounds ridiculous, but it was actually perfectly legitimate use case. But that's the power of context. So now I have to switch into screen mirroring mode here, which will take me just a moment, and mirror displays. You guys can see behind the curtain now. All right. I'm going to wear this for when I'm looking at my own screen. So I have a demonstration site set up here on my local machine. It's called Omai. I've populated it with development content. Everything else is out of the box, Drupal, except I enable a couple of convenience modules like admin menu and module filter, things like that that don't affect layout. I also enabled context. So we're going to play a little bit with this. Let's go up here. All right. So first we're going to set up, you guys can see that note, can't you, right? I should have printed that out. First we're going to set up a front page context so that we get a sense of how this works. So here's the context, admin backend, and we are going to add a new context. The unique ID we'll call this front page because I like being semantic. And I'm going to give it the tag front page. This page is the front. It is not the back, but the front page. Now, this is where the meet comes in. We get to set conditions and reactions. That should happen when all those conditions are true or when some of those conditions are true depending. So for this really simple context, we are going to say the path should be front. And you can see down here we have instructions that explain how you should write paths, but it's the same thing that you've seen elsewhere in the Drupal interface. So as long as the path is front, the reactions, and we could do a variety of things including setting CSS body classes, there's just tons, we're going to set blocks. Oh, yeah, you guys are missing the best-looking part of my browser, that left part. Oh, yeah. Oh, yeah, that's satisfying. Yeah, I know, the slides are hard because it's full screen and magic unless you have a clever trick for it. No, all right, that's just the way it's going to be. Good, thank you. All right, so we're going to set some blocks and I'm just going to set some blocks for fun. Let's say I want to see powered by a Drupal at the top and I like system help. We'll put those up in, let's put them in the header. Just click add and by magic they appear there. And who's new and who's online? Let's put that into the sidebar. Nice and simple. Any questions about what is happening so far? Good, I would be worried about you if there were. This is quite simple. We're going to hit save and let's have a look at that front page. All right, there's powered by Drupal in the header. There's our who's new and who's online. Everything is working perfectly according to plan. Can anybody tell me what is not going according to my context here? Has anybody noticed the blocks that I did not put in context? Search. Navigation, where did this come from? I didn't put that in context. Because context complements the core block system. Those are the blocks that are there by default in core. System help up in the top. Main page contents, which we can't get rid of. Search for navigation. So let's just disable those. Make this a little bit clear. Interestingly, you cannot hide main page content in the blocks interface. It won't let you. So you cannot use context for a complete total page layout. Core blocks has to handle where the main page content is coming from. Great. That makes a lot more sense. And if we go to some arbitrary node, suddenly we don't have those elements that we put in context. Makes sense. Nice and clear, right? So let's have a look at some of the things that are a little bit trickier with context. We're going to add another context here. That's just going to notice if I'm admin. Actually, we'll do one first that notices if I'm anonymous and one that notices if I'm admin. No last pass. I don't want anything there. Conditions. User role. Anonymous. Reactions. Blocks. Let's put our login block somewhere incredibly prominent. Like featured. Oops. Single click. Sure. That's all we need. And we open up a private browsing window. See? Oh, great. It noticed that I'm anonymous. There's my user login and enormous characters. Actually, it's not a bad idea if you really want to make people register. Register now. We also have the other blocks that we positioned on this page. Fine and clear. Let's add our next context, which is for admin user. Same thing. User role. Administrator. Blocks. Next time, I'll do some of the more interesting ones, like let's put backup migrate. Let's put arbitrary PHP. Yeah, that's just fine. And we'll put that in the sidebar. And then let's also do the context inspector here in content. Great. So once again, hard refresh, please. You'll see because I'm anonymous in this browser window, I don't have those new blocks because I'm an administrator. I have my cool new blocks. So here's the first thing that's a little bit tricky. Why is who's new above the backup migrate stuff? Like the order of these is kind of weird. Who's new backup migrate? Who's online? Then PHP code. Then switch user. Can anybody with a show of hands, does anybody know what's going on here? Just call it out. What do you think is happening? The weight of the blocks is set to zero, which is exactly the problem, but it's a bit tricky to describe it that way. Actually, what's going on is that there are two contexts that are actually evaluating to true here that are trying to control what's going on with blocks. And what happens is they all just put them into the region and then core blocks tries to sort out, all right, well, what block should go in what order? And unless you're careful about it, it comes out more or less random. So we'll go back to our context interface here and let's look at our front page. There's the blocks. Magic button that is usually only used if you have JavaScript problems, but is very useful in context. Show block weights. These are the weights that are respected even across contexts. So actually, I'll open up the other one in a separate tab and we can have a look. Admin user locks. Sidebar first. Oh, yeah, we're already there. So you can see negative 10, negative 10. So that happens alphabetically. Who's online is negative nine. So that goes alphabetically beside execute PHP and then negative eight. So if we really want to make sure that things go in the right place, you really need to manually set these. So I'll make sure that the admin things go at the bottom, for example. Is everybody familiar with the concept of weights in Drupal? Marvelous. Oh, would you like, sorry, is that yes or no? Yes. Yes, good. This is the same concept that we use again and again. So we'll just hit save and now we can see where it is. Great. And now all of the admin stuff is at the bottom right where we put it. Wonderful. The other thing that's a little bit tricky with context is especially once you have a complete site, figuring out where the heck did these blocks come from? It is not unusual to arrive at a page and go, well, who's new? Where the hell did that come from? The context inspector is a fantastic tool for it. It's why I enabled it for admin. So this is actually a Krumo output of the array that context is using to decide what's going to be displayed on the page. And you can click through to see, all right, well, there are two contexts that are evaluating here. Front page. This is the basic information. Here are the conditions that have to be true. Here's the reactions. And again, this is actually coming right out of the array that context uses itself. This is from the horse's mouth. So there are no layers of interpretation or assumption that are involved here. It's quite a good tool for figuring out what the heck is going on with your context. Let's see what I'm missing. Overlap, context inspector, relative block weight sucks. Yeah, we got it. So the one really useful use case that I'm going to show you is one that I like to do on some sites when I'm going to have clients acting as administrators, I like to make it really visible for them. Really visible for them, the fact that they're logged in as administrators. I'm going to use the same admin user context we set up. And I'm just going to say, I'm going to add another body class. Admin user, great. Now as long as you're logged in as admin, let's have a look at inspect element here. As long as you're logged in as admin, body gets this extra class, admin user. And it's very easy to make a little theming change to make, for example, all of the text red. I definitely do that. Punishes the user. They shouldn't be logged in as admin anyway. Keeps them paying my bills. This is a really useful tool. Does anybody have any questions about context before we go to sum up context and move on to the next? Yes, in the back. You're going to have to run to a microphone though, or just yell and I'll repeat it. If you have two context with, well, constitutionally block views, for example, admin show search, home page don't show search, what happens if you're an admin on the home page then? That's a very good question. Context works by a white list of what to show, at least the blocks do. So you can't explicitly say don't show this block. So it's a purely additive model. So if you have two contexts and one doesn't say anything about search, and the other one says show this, search will appear. Good question. Any other questions? Yes. So it seems context is a better UI for the block system. I wholeheartedly agree to a point. And actually this is going to be a great opportunity for me to get out of mirroring mode. Hope that you guys get the right one. I seem to have lost that one entirely. Let's try this again. Interesting. Did you guys see another presentation? Oh yeah, there it is. Ho-ho-ho. Demonstration time. Excellent. Right, so that's the magic of context. That's me, your nerdy magician, and you can be too. Context pros and cons. So in the pros column context extends core blocks and templates, which means it's a pretty minimal add-on as far as weight. You still get the nice contextual menus to edit blocks. You can still get the benefits of core block compatibility with everything else in the world. This is a big winner for simplicity. You can reuse blocks and regions, which is a part of what makes this way better than core blocks. You can get around that pesky problem of a thousand regions or duplicate blocks. You can actually get the most out of those 16 basic regions. Context is extremely flexible. It's easy to add a new context for a very specific use case and completely change the layout or styling. There are plugins for context that allow you to say, change the theme entirely. Right, the same way that we changed to an admin theme when we're at anything that begins with slash admin, you can change your theme entirely based on something much more subtle. Is it Tuesday? We'll have the Tuesday theme. I actually did this once for talk like a pirate day. I had a pirate theme. I also had too much time on my hands. Let's try not to spill around the electronics. Let's see, need a new layout? Just one click away. Context are C tools, exportables, which means they are totally supported by features. This means that your context are easily exported and controlled in code, which is a massive win. And with the context inspector, you can debug context pretty easily. You can see which contexts are active at any point in time and generally figure out what's going on and why. In the cons column, this is where we start to get the limitations. Context doesn't actually do anything to help you exporting your blocks. If you have any blocks defined through the core block system, you're going to have a hard time getting them into code, just like we did in the first example here. Context is very flexible, but it's also completely unstructured. This is a hard one to demo, so I have to do this conceptually. How are you going to categorize your contexts? You're going to end up with 20 or 30 of them if you do context only for your site. So what are those tags? Path-based? User-based, so like on the conditions? Or is it on behaviors like block contexts or style contexts? Or semantically, by what region of the site this applies to? It doesn't matter if you have three contexts, they're completely fine. But if you have 15 or 20 or 50, this suddenly becomes really important, especially when the project is 90%. Done and the client says, I want this really cool new layout, and you have to figure out where are all those site-wide contexts, where are all the things that are adding these blocks. And almost every time, you end up having to rewrite all of the other contexts that are involved just to make this one new page work. If you are really mean to your clients, but I haven't found a better way. One set of regions still has to handle all of your layouts. In our example, so what if I had a layout that only has two regions, and two regions that are quite different from the 16 that I've got already. What if I have one that needs 17 regions? What if I have a layout that still needs 16 regions, but in a different position than what we had here so those region names don't mean anything anymore? What if sidebar left is now positioned in the header? All of a sudden, this gets actually really hard to manage. You get into some very unsemantic situations. If you really have several layouts and several set of conditions that significantly change the site, the context UI gets awful very, very quickly. This is a huge minus on the transparency front, and this is a limitation that I think it shares with the block module. In our rating system, context does a little bit better than core blocks. I've never seen a purely context layout site that wasn't really hard to wrap my head around, and that's just the way it is. If you know how to use the context inspector, it can be quite transparent on a page per page basis, and a well-done set of structures is built around simple structures that repeat and get destroyed by the client before you get to launch. Every time, every time. Other things that you may want to look into if you weren't terribly familiar with context before, spaces, which allows you to do a lot more behaviors based on context and actually have what feels like totally different sites and a lot of different site-wide variables, different site name depending on context conditions. Actually very, very powerful for multi-site. Perl, which I hate because it sounds like the programming language, but it's not. This is context per URL. This is what I use to get four different URLs that produce different behaviors. And, of course, the ability to roll your own custom context conditions and reactions. There's one piece of black magic, and that is C tools, plugins. They are confusing to learn about the first time, but they allow you to do things like custom context conditions. That is an absolute must-have if you're going to use context on any really large-scale Drupal site. There is a good blog, there is a fine, beautifully written blog post about it at othehugemanity.org that you guys can have a look at. All right, yes, question. No, I actually haven't had to use Delta, but would you like to give us a quick explanation? So I'm just going to repeat for our YouTube millions. Our YouTube millions, no problem. So Delta is the module that lets you change themes based on context. And you can have completely separate themes. You could have one that's Zen, one that's Omega, and one that's completely built from scratch by your nephew. Or they can be different variants on the same theme. Multiple variants of Omega. Or I think you can do even the same theme with different settings, right? Right, actually very useful. You're completely right. I should put that on the list for next time. Yeah, context conditions are what makes Delta a switch. All right, any other questions or comments about context, other cool modules that are worth mentioning? All right, I'm sure we missed some, but it's okay. YouTube comments will trash us for it. Now it's time to look at another big popular C tools-based methodology, panels. Who here has used panels? Why are you guys here? This slide is a little confusingly titled. I know I said panels, panels everywhere. It was a meme reference. The trouble is that there is also panels everywhere, which is a methodology. That means no core blocks, no template files, no theming for the layout at all, no code. Just panels for everything in your entire site. It's a pretty cool methodology. It should tell you something about just how powerful panels is that you can actually replace half the theme layer with it. But it's not really what I'm going to talk about. We will mention it a little bit more. But let's take a closer look. Demo time again. Mirroir, awesome. All right, do I want to disable context entirely? Sure, let's disable context entirely. It's gone. Our beautiful layout is gone. All right, and we're going to enable... You know what, I'll do this in the UI because it's way more legible. Panels, lots of modules come with panels. I'm going to skip panel nodes, extra layouts, in place editor. There's a Views 1, 2 that needs to be here. Content panes. Okay, that was great because it was off. All right, so the basic concept behind panels is to give you a drag and drop interface for dragging blocks around layouts. That the solution to this infinitely long list of 300 different blocks that can go anywhere and having to drag them around is to instead have an interface that looks like the layout of your page. A little bit revolutionary, I know. And you should be able to drag a block from one region to another. It's amazing. That's the core concept behind it. So we're going to walk through, first of all, a simple case that is really common. We're going to use panels to... No, we have to activate page manager, but then we're going to use panels to create a front page. All right, so we're going to use... We're going to use one of their little wizards and you're going to very quickly discover the big bugaboos about panels. So we're going to create a new page, front, the page, which is the front and which is not the back, but the front. And we'll give it a URL and make it our site home page. So the first thing that's confusing is this is actually... This interface is not provided by panels. This is provided by the page manager module, which comes with C tools, which means that it has no idea what you're creating this page to do. What page manager does is it lets you create a new URL and do something with it. Out of the box, what it lets you do is just give an HTTP response code. You could have a URL path that always gives a 302 redirect, for example. It's a pretty edge use case, but panels hijacks this to say, oh no, no, we want to have a panel happen here. Oh, man, that path is already in use. Let's change this. Fronty. May as well be cute, right? All right, so, panels makes it relatively easy to define your own custom layouts in your theme, which means that there's a lot to choose from. I really like working with a module called Panels Extra Layouts, which I highly recommend because it comes with some incredibly flexible layouts like this one that you see before you. This is not the number of block regions that you've got, but you never have to see them in just a plain list, so it's okay. We can just drag things around. It's also adaptive, which is pretty cool. It means that blocks expand to the right to their nearest neighbor. So we have three block regions in the top here. If you have something on the far left and nothing to the right, it will take full width. It will take something a bit simpler that I think comes out of Panels itself. Though to be honest, I'm not sure. Let's take... How many columns do we feel like today? Let's do two columns. Now we'll do something different. 6337 stacked. This is going to be the fronty page. We have the option to try and disable all of the Drupal blocks and regions. This works on some themes, not on others. I'm going to ignore it for today. I'll play with to see if it works. And I'm going to include the in-place editor because it's cool. And then I'm just going to hit Finish. It looks like I should do something here, but trust me, I want to get out of the pages interface and into Panels. All right. This is the Panels interface. Finally, we had to get through a bunch of wizard steps that looked like they were being friendly and giving us options we cared about, but actually give us options that we don't care about. We're going to ignore everything on the left for now. Most of that was set accurately, was set fine for us in the wizard, so we're just going to say no title. And some things I happen to know are provided in hard code by Bartik because it's naughty. We're going to put things in the left side. Add content. Views. Let's put the front page view. That's a nice one to have. And we'll pick which display we want. We could put the feed on the front page if we really wanted to. Oh, and there are all these nice settings for how this view should display, including giving it special arguments or overwriting the URL or using different pager settings, things that are all quite handy if you're going to be moving things around. And here's the magic. Do we want that in the header? Left or right? Can I get applause? Left. That was tepid. Right sidebar. Make it ugly! Header. Right sidebar it is. And I can do that sort of thing because I have a grown-up drag-and-drop interface. And we're going to add something in the left sidebar so that it looks nice powered by Drupal. Sure, let's put something else in there though. You get some kind of a sense of what sort of options that we have here. That's not the menu. Yeah, okay, new forum topics. What that happened? Update and shave? Let's have a look at our front page and see if I forgot anything. No, there we go. So two columns powered by Drupal in the main column in new forum topics because I hate those UX people anyway. And here on the right is our main page content because who really needs readability? Are there any questions about how that just worked? Excellent. So that's the simple use case. And that's something that's playing to panel's strengths. Let's do something that's a little bit trickier now. We're going to do nodes. We're going to actually change the way node layouts work. If you recall, our nodes have no layout right now. So let's go back to panels and we're going to enable the node template. You should notice here on the right side, so these are ways to override things that have built-in templates in Drupal. So if you want to customize the way the node add edit form is, this is probably the easiest way to do it. You can drag and drop the form elements. If you want to customize the way your users look, this is not a bad way to do it either. But we just want to say node template. So we will enable that guy and edit. We're in this really weird interface and nobody knows what to do with it. So the reason this is totally different is because when you are overriding a template, a panel has a system of variance. Kind of like how there's a view and then there's like 30 displays of that view. And they're all kind of the same thing but all kind of not. Panel's variance is a similar kind of model except that it will go through checking each one in order to see which layout should be applied here. So right now we have no variant so it's just going to fall back to Drupal. We're going to add a new variant and we'll do this for forum posts. And then everything else we're going to do is exactly the same. Let's get another layout this time. Two columns. I like this even two column because it's kind of useless. We'll do the in place editor again. Continue. And create variant. Update and save. Same steps that I did before ignoring most of the wizard because it's just hard to know what's going to end up where. So in our this is going to be just the same as what we did a moment ago. We're going to say what do we want? So now we have some options here that come from the node. We can take absolutely any field and add individual fields. So let's put some things in the left sidebar. Let's put the image in left sidebar. And I don't want a label and images a great formatter and I don't know that's a nice image style. That's pretty. Add content. Node body this time. Now we also can set the title of the page. This gets set the HTML header element as well as the H1 element at the top. And we're going to use a system that looks a lot like what you get tokens elsewhere in Drupal and honestly it works very similarly on the inside but more reliable. You can look through this list of substitutions. We're just going to take percent node title and update and save and let's go look at a page that's been updated and saved and let's go find ourselves a forum post a forum topic. Oh, there's no image on this one. Dun dun dun Maybe there's an image on this guy. Either that or my image formatter is not working but we can see that we're in the right layouts. Yeah, that's a really good point. I thought that I do. Let's look. No, good call. Good call. Great. So one thing that you should note now if you haven't already is that the UI for forums is a confusing mess for panels is a confusing mess. The basic drag and drop functionality awesome but you run into problems like this all the time where why isn't that field showing up? While I'm at it I can show you some of the extended things that panels can do like we can set CSS properties. We can say oh this should have a special CSS ID or class. We can set a totally different special style system that has nothing to do with anything else anywhere in Drupal. Rounded corners how the heck does that work? Nobody knows but it happens. We can set special visibility rules to say things kind of like what we just did with context. This should only be displayed if the user has the permission to edit terms in forums for example. I'm not going to do that because that's terrible. We have special caching rules that you can apply. Actually panels has a built-in caching system that is relatively easy to write custom cache plugins for but even their basic simple cache is pretty cool. Set a lifetime and set granularity so for example if your page has arguments like a node ID for example and a separate page cache for each node and with a lifetime of 15 seconds that will work for authenticated users as well. You just got yourself a really fast site for authenticated users. For context if you have any special context conditions that we'll look at in a second in panels that the panel is aware of this will separate it out by context conditions. Yes. And you're doing these caching per field now because if you do want it for a whole page in the top, I learned it just a few months ago. Yeah. So this is caching specifically per pane, per individual component of a page. This is actually for authenticated users really useful. It's very common that you have one block that has custom information for the user and everything else can be cached. This saves you a lot of load. The big downside with all those options I just showed you is that you're never going to figure out that you set them again. You're going to look at this and go why the hell do I have rounded corners? Where did that CSS class come from? And you're going to just get you're going to drive yourself to cutting over it. I had a themer almost kill me. Go for it. Or just yell a few. I'll repeat it. It's fine. Yes it is included in Cache Clear All. One of the great things about Drupal 7 is that it's easy for people to declare their own, for modules to declare their own own. It's an easy way to use the tool that you have used in your code. It's a pretty simple tool. You can do this with different type of plugins. Panels does as well. I'm pretty sure that in the admin menu no I know in the admin menu it's included in page and else which is everything else. But if you hit flush all caches here or if you run Cache Clear All like happens on Cron, it's going to include panel big upsides that I really wanted to show you is this cascading behavior. So we have forum posts right now and we know that apart from the fact that forum posts don't even have an image field that works great, we're going to create another variant. I have no idea what time I'm supposed to stop. Can somebody tell me? Two minutes ago? You're stuck. We started late, so actually this is an important concept so I'm going to finish this one and we will jump to summaries and the elixir of life. And you guys can leave if you need to. If you need to, I won't feel insulted for long. So we're going to add a new variant. This is going to be the default variant. This is going to be the thing that it falls back to. Again, exactly the same wizard steps that we did before. Finally I'll use whatever the adaptive layout is. Continue. Title type. Default variant. Foo. And let's add. Dasio, I'm totally hurt. And here I'm just going to add a couple of things quickly that I'm sure are involved in some of the other ones like image. Finish. And maybe we'll drop something on the right-hand side like title. No title. Great variant. So what's going to happen here, and I'm going to tell you before I show you because it's faster, it's been saved, is that when Drupal hits a node, it's going to go through these variants in descending order. So it's going to first check and see, oh, does the forum post variant apply here? And it will if it seems like forum post is right. And if it doesn't apply, it's going to go to the default variant. And the rules that it uses to tell if it should apply are under selection rules here. Oddly enough. So we're going to say that forum posts only applies if the node type is forum topic. Again, quite a lot like context. Great. That's saved. So forums are going to get this same layout. And let's find out that it's not a forum. And we get a default variant on every other kind of node. What this gives you is a really easy way to build repeatable structure that's visible at a glance. You have one panels interface that shows you the content types that have special layouts and falls back to a content type to the default that handles everything else. All right, I'm going to jump back to this, and I'm just going to jump through the summaries because that's what we've got time for. And it's a pity. I've got superheroes. Panels is the magneto. Because if it's made of metal, panels can handle it and do everything with it. So panels, very broad power, very high granularity. You can get down to the field level and individual CSS selectors. It has great failover structures for repeatability. The in-place editor actually is nice for novice users. You can hit a button on the actual page and drag elements around. It looks kind of Drupal 80 if a bit more clunky. And it's context sensitive just like the context module was. Cons, soul wrenchingly bad UI, heavy code base. This does have a big memory impact on your site. C-tools plugins are weird. When you have to write something custom for panels, it's very similar to writing something custom for context, but it's weird and hard to wrap your head around the first time. Also, very good blog posts on OtheHugeManity.org about it. It's overkill if you have simple layouts. If you have two layouts on your website, don't use panels. And it's honestly difficult for individual fields. If you just want one column and you want to lay out title above body and then the comments below it, don't use panels. So we can see that panels has its own downside and complexity, but it's sweet in repeatability. It's sweet in transparency in its own way. There isn't time for anything else, but these are the ones that I really wanted to get to. And we're going to jump through DisplaySuite. I'm just going to go right to the pros and cons. Gene Wilder. I'm sorry, Gene. DisplaySuite works just like the Drupal field display interface. It's really easy to use. It has very high granularity. You can even clean up your DOM with it and specify simplified classes and HTML. You can use the exact same layouts that panels supports. So the same list of crazy adaptive layouts that I showed you apply in DisplaySuite as well. It's incredibly flexible and it has great features support. Konzar, it only handles individual entity layouts. So that means individual nodes, individual users. It doesn't do well. It doesn't do well if you have a page that is an assembly of other content like a front page might be or a landing page, for example. There is no structure across different content types. So this means that with DisplaySuite you work with teaser mode, full build mode, and you can define your own. There is nothing that makes sure that that teaser mode looks the same on blog posts as it does on articles as it does on forums but looks different on events. This means you can get into situations like I did a couple weeks ago where I was doing an audit of six different DisplaySuite display types across 24 content types. It sucks. Sucks. There are still some hitches with features. Field order is not great still with DisplaySuite. We're working on it. So DisplaySuite has its own downside, especially in repeatability. There isn't time for fences, which is a really nice way to have clean HTML. There isn't time for field groups which makes it look pretty or object cache and entity cache which make it load fast or for how to roll your own DisplaySuite fields but I encourage you to go to othehugemanity.org and read all about it there. And that's not really it because I just told you why everything sucks. The reality is that's just another way to say everything is kind of special and has its own benefit. Core blocks with context is great for site-wide structures. You only need a handful of contexts in order to do that and context is cool if you only have three or four contexts. Panels is great for non-entity and multi-entity layouts like your front page or big landing pages. And DisplaySuite is the best thing for individual entities. So my theory is the Megazord theory. And this is the Megazord theory in a nutshell. I like to use context for the relatively permanent page elements which in most cases means the header and the footer but in your case it may mean a sidebar element or something that pops in an overlay if you want to go to hell or if you have something that needs to slide in on the right side. I like to use panels for the main content area. This is the area where you have the most variability in what blocks you want to display, in what layout you want to use. Sometimes it's a left sidebar, sometimes it's a right sidebar, sometimes it's something totally different. And the great thing about panels is that it makes that part easy to manage and it builds structure for you. You can see at a glance that the content types have different structures. You can enforce consistency across them and you can see that there are three other URLs that have totally unique layouts. Finally, whenever I'm displaying an individual node, whether it's in a whether it's one response in a view or whether it's buried in the middle of a main page, I use DisplaySuite. Panels has one of those fields that you can add for node is complete node. And it just takes whatever Drupal is handing back to it, which includes DisplaySuite, includes cache DisplaySuite, and it takes everything that you've got for it. And what this means is you have a nice cascading structure. So your themeer is happy because every page has a consistent structure, no matter how weird the layout is. The permanent fixture elements are displayed in exactly the DOM they write into the template every single time. Thank you very much context. The structures that change have all the flexibility that they need built into the HTML with the crazy multi-layered DOM that panels can provide. So they can find a consistent way to theme even the most variable parts of the site. Thank you, panels. And the content elements all have simple consistent HTML with custom classes. Thank you DisplaySuite and optionally fences. So Megazord is my way of getting everything that I want. The nice thing is you document it once and everybody knows that on any page, if you don't know where an element is, first check panels and see if it's listed there and then check DisplaySuite. That's all you need to know. You can see if you're running, if you're using DisplaySuite, you can see if you're using a custom layout. All right. I know that I've got to let you guys go. I'm going to hang out up here for any questions. Please do come up and talk to me. And I guess I'm going to have to find a buff because we're out of time. Thank you very much.