 All right, so you just heard a little bit about me. My name is Jen Lampton. I'm going to give you a little longer story. I started building websites back in 2006 with Drupal. I started building websites in 1997, a lot longer than that. But when I first started building sites with Drupal, I was a site builder. I just wanted to click all the blocks together and have it turn into a beautiful tool for my clients to use. And so I like to approach how I build websites today with that same kind of perspective of are the tools I'm using as a developer, friendly enough for site builders. So I'm going to talk a little bit about why that leads me to love PIN as much as I do. I started helping the local Drupal community in Berkeley in the San Francisco Bay Area in about 2007, which was where we had our first Bay Area Drupal camp. I'm now the lead organizer for the Bay Area Drupal camp, along with a lot of other really great community members who helped put on this camp every year for free, which is pretty cool. And in 2010, I was also one of the organizers for DrupalCon San Francisco that was held in the Bay Area as well. I've been writing modules for Drupal since about 2008. I stumbled across some need one of my client had where a module didn't exist, and I was like, I'm not really sure if I can do this, but I guess I've got to try it because they need it anyway. And it turns out it was really easy. And I kind of had really high expectations for what a module developer for Drupal was. And when I started mucking around in the code and realized that all you had to do was write a couple of functions in the right way, and you could make Drupal do exactly what you wanted to, I kind of fell them up. So in 2010, right after we held DrupalCon San Francisco, we had our first training day in association with the DrupalCon, and we trained over 500 people. And all of a sudden it became clear that Drupal needed training. There was this huge market for all of these people who wanted to learn Drupal and needed help. And so I was working for chapter three at the time, and they decided to start a training division. And I started writing a bunch of training materials on Drupal. So how do you teach people how to use Drupal? And we were mostly trying to train site builders. We wanted to train the people who were going to be using Drupal to build websites as opposed to launch developers and theme developers that we focused on later. But initially, I started writing a bunch of training also on panels, because I wanted more people to know how to use panels. In 2011, I had spent a year training people on how to use Drupal, and I felt that most of the time I was pointing at Drupal saying, we know that this doesn't make any sense, and at some point we're going to fix it. And I felt like I could have been one of those people who was fixing it. So I got myself involved with the usability team, and we did a bunch of usability tests both at the University of Minnesota, and then later in early 2012 at the Google usability labs to try and figure out what it was about using Drupal that was quite so hard and making some changes in how we named things, how we organized things that just made site builders have a much easier time working with Drupal. And shortly after that, we realized that not only is using Drupal from a site builder perspective really hard, but trying to teach people how to theme for Drupal, particularly Drupal 7, was way too hard. And so I started focusing not only on what we call usability, but also something I call learnability, which is trying to make Drupal easier for people to learn. And a big part of that to me was replacing our theme layer with something that made a lot more sense to people. So now I'm involved with trying to get Twig in for Drupal 8. So I'm obviously very heavily invested in this Drupal business. I really love it. I think that what I do every day is a lot of fun. I get to wake up and play with toys, basically, all day long, and then deliver products to clients who need them. And I feel like that's a really good place for me to be. Every single website I build, I put panels on. That doesn't mean you need panels on every single website that's out there, but I find a use for it and a benefit for doing that. So panels is also my favorite module in all of Drupal. So now that you know a little bit about me, I want to try and take a poll and try and figure who's in the room. Just so I've got a couple of examples at the end, I need to know how technical I should get with them. So other people in the room can be going to a show of hands. How many of you have been building Drupal websites for less than a year? So I'm assuming most of you are all working in Drupal 7? Okay. So how many people have you been building websites for more than a year? Okay. How many of you also built websites in Drupal 6? Okay. And so what I'm going to try and do is it's a little bit easier to relate some of what panels is trying to get you to think about how we used to do things in the past. Things did not change very much in a layout perspective between Drupal 6 and Drupal 7. I actually think they got worse. So panels is pretty much the same between Drupal 6 and Drupal 7. So I'll solve the same problems in a lot of the same ways. So we'll do some comparisons between the two of those two. So originally, this is like flashback to how Drupal got into the problem that it's in now with layouts. Drupal assumed that every website made in Drupal would use exactly the same layout, and that would be sidebar on the left, sidebar on the right, content in the middle. And back in 2001, this was really great, because everybody had websites that had lots of content that were going to use this kind of format, and it was trendy and whatever, and that's fine. But there's a couple of problems with this. For starters, this assumes that the content for any given page is always going to be in the middle of the page, and the way the templating system works is it actually treats the content as like a single variable. It just prints it out. It also assumes that the stuff that goes around it, this is what Drupal calls blocks, is always not really going to have anything to do with your content. So that when Drupal renders a page, it puts out the content, and it sticks a bunch of stuff around the outside. And as that stuff is being prepared, it doesn't have any idea what's going on in the middle of the page. So the stuff has no clue as to what's next to it, which makes it really hard for you to make your content relevant to each other on different parts of the same page. So that was a happy for a little while, we're like, OK, that's fine. We can print, make websites like that. And there are a lot of websites on the web today that still work like this, and they're perfectly fine. But there are some people who want it to do something different. A lot of people need different layouts for different pages. Homepage is something really common. Everybody's like, I don't want my homepage to have exactly the same layout as every other page on my site. It's different, it's special, it needs more attention. So we're like, OK, well, we can give you some tools for your blocks to control where they appear. You can decide, OK, this page should or this block should or should not appear on homepage. You can say this block should or should not appear for a specific user role. Or, hey, here's a box that you can throw in some PHP code. That's a good solution, right? We decided to make the one layout that Drupal comes with flexible. So we're like, OK, if you tell all of the blocks in the right sidebar not to appear, that page can just adjust and say, hey, there's no sidebar, I'm wider. Guess what? I'm a two-column layout, haha. But it's not. It's really a three-column layout just with nothing in that column. Well, that's fine until you have 18 blocks in your right sidebar and you add a new page that doesn't want a right sidebar and you're like, oh, I've got to add 18 block configurations that I don't show on this page, don't show on this page, don't show on this page, don't show. And after about the fifth time, you're like, screw this, I need a better solution. All right, so let's look at our template files. We've got code. We can change the code. Let's just go into the template file and create a special one just for some specific page. For example, here's the home page and say, let's just not print the sidebar, right? No sidebar on this page, no problem. Well, actually, that's problematic, too, because even if you're not printing the content to the page, Drupal still goes into the database retrieves all the content graphs and its theme function sticks it together and then just doesn't do anything with it. So you've wasted all of this time where Drupal's gathering information and getting her ready for display and then just not displaying at the end. So OK, that's not good enough either. We also ran into some crazy problems with the user interface on the blocks page, where what if you want some block to appear on the left sidebar on the home page, on the right sidebar on a subpage? You can't. It's either in one region or it's not. You can't have it in two regions with conditions. But guess what? We're running out of time to solve this problem, and we've got a shift Drupal 7, so that was Drupal 6 land, right? We're now moving into Drupal 7. So what are we going to do to let people have more flexibility in how we deal with this in core? We can add a crazier starting layout. So we changed our default from Garland, which is our previous theme to Bartik. And Bartik has lots and lots and lots of regions. And this is great because it gives you a lot of flexibility. You can say, oh, on one page, we're going to use this triptych region. And on another page, we can use the four column footer region, and then it's kind of different. And you can put, it's like a different layout. Only it's still one layout. You're just putting stuff places and not. And it came with some other problems. Now where we have this giant dropdown of what region do you want this content to go in? People look at that, and they're like, what? I don't know where these are. What the hell is a triptych, right? There's just stuff in here that it cluttered up our user interface and didn't actually solve the problems we wanted to solve. One of the problems here is that our content is still just one giant content variable in the middle of your page. So that didn't get solved either. So what is the solution? Well, as it turns out, there are five ways to solve every problem in Drupal. You probably all discovered that already. The solution that I love more than any other is panels. So panels lets you control layouts. That's the big thing. There's a lot of other stuff that it does that we'll talk about too. But layouts is the big win and the easiest place to jump into it. It requires that you change the way you think about the architecture of your site. And there's a couple of different ways you can use panels. There's kind of what I call the half in way, which is where you still kind of use blocks and regions. And then there's the all in way, where you just screw blocks, turn off the blocks module, just jump in and use panels. And it's a different way of thinking about stuff. So I'll walk you through how we're going to do that today. Sorry. OK. So you have to think about controlling the layout of your site, like whether you have sidebars or not, whether you have a triptych or whether you have a footer or a header. Instead of thinking about that as a layout in which your content is placed, you're thinking about all of that stuff as your content now. So if you take the garland model here, where you used to have a header and a footer and a left and right sidebar and content in the middle, panels lets you take control of that content area and say, OK, where this used to be one giant block of content, one huge column with your field order letting you control how it appears. Now we're going to split it into different areas. In this case, it's going to be two columns. Well, what if you wanted your site to have a two column layout instead of your content to have two column layout? You just don't have sidebars. And now your content is your site. And so you've got everything in two columns. Same thing with the three column layout, right? This is a layout very similar to what Garland's trying to do. You want to rebuild garland with panels. You build that same layout in your content area and then you don't have sidebars. So what we're doing is removing the stuff that blocks does with your layouts and your regions and replacing it with panels. And we'll walk through a couple examples of how you can actually do this later on. So this changes the way you're fundamentally building your websites now. It means that you don't need very many regions in your theme. Your theme becomes look and feel, style, font, color. It doesn't dictate where your content goes. And this is really hard for some people because front developers want to build layouts. And you can still do that with panels. You can do it in your theme. I don't recommend it. The reason I like to separate the idea of layouts from the idea of theme is because if I change my theme, I don't want my site to break. I feel like a theme should be a skin. You should be able to stick any theme on any site, and it should skin it, and it should be fine, and it shouldn't explode when you change your theme. And so I like to think of layouts as separate. So you can have a layout, and you can have a theme, and you can mix and match them. So panels is in charge of your layouts. Your theme is in charge of what those things look like. And you can add styles to them panels, and we'll talk about that a little later too. Another thing you can do is think about it as you're not really going to be doing anything with blocks anymore. My big saying is blocks are dumb. They don't really know anything about what's going on around them, so why use them? It turns out that if you use panels, panels gives you access to all of the blocks that every module that you're using provides. So if you want to use a block, that's fine. You can use it in panels. You don't use it in blocks, you can use the blocks UI. And Matt, I'm not sure if he's in there or not, wrote a patch against the core that allowed you to turn off the block module in Drupal 7. So if you don't want to use blocks, you don't have to just turn it off. You're fine to use them in panels. And then the last thing that's the biggest thing is that everything is content. It's not just that thing in the middle of your page. Everything on every page is content. And one of the things that we learned in doing our usability tests two years ago now is that this is the way most people think about a page anyway. Users don't think, oh, a block is an administrative tool, but a node is content. But that's how Drupal has trained us to think. And so for the longest time, we didn't understand that this was a conceptual problem for people. But now it turns out everything is content. So in panels, a block is content. Node is content. A user is content. A little piece of text you drop in there is content. Everything is content. You can put every piece of content wherever you want inside your layout. So it's just kind of a fundamental change in how you think about building your website. But it turns out it's a lot more true to how you would naturally think and a little less true to how Drupal people think. Which I think is good, but different. All right, so I'm going to show you a couple of pages in Drupal that Drupal does. Drupal does things for you. Right, yay. It makes it really easy, because most of stuff is already done. But I don't think it does things very well. It just kind of does them. And so what I like to do is go through all of the stuff that Drupal normally does, and make it a little bit better. And you can do that by using panels and all of the suite of modules that goes along with that. So the first thing that, here's the list of the pages that we're going to build. We're going to build a custom home page. This is the first place people usually find a need for panels, because they want to make their home page different. So it's a really good example to start with. We're going to change the layout of the home page. We're going to change the layout of two different node pages. We're going to show you how to make patterns that will apply to different types of nodes. We're going to talk about the user profile page, as the page Drupal does really badly out of the box. It's like, you've been here for two years. Oh, yeah. That's what I want to know about all my users. So we're going to replace that with some better displays of user information. We're going to go over the taxonomy term page. Out of the box, the home page and that taxonomy page are really similar in Drupal. It's just what I call a river of news, right, where it's like, post, post, post, just fine if you're writing a blog. But most people using Drupal these days are not just writing a blog. You're just writing a blog. Use Wordpress, but you're not. You're building a website. And it does more stuff. And you want the page to look different. So we're going to replace those two pages with some examples of how you can leverage panels and views, and views, custom content panes to make those better, too. And then I'm going to talk a little bit about custom landing pages. So you can build your own custom layouts. We'll talk about that, too, and how to manipulate them even from a kind of editorial experience as opposed to an administrative experience. And I have a bunch of code I can show you, too. At the end, we'll see how much time there's left. So you can add your own stuff to the panel, too. So I'm going to start with wireframes. I don't know what your usual development processes like. I usually run into two different processes. Number one is I'll get a finished design. I'm not a designer. No design skill whatsoever. So some fabulous designer will hand me something beautiful and say, make Drupal look like this. And then it's a matter of deconstructing that design into its component parts. And you're like, this is a node, and this is a view, and this is, I don't know what that is. I'll build it later. Or if the design is a long, painful process and they're working with the client to go through iterations or whatever, sometimes they just give you the wireframe. So they sign off on the wireframes. You start building this. So this is the process that I'm going through now, where we've got a bunch of wireframes, and we're just going to build this in a wireframe. No theme. We're going to use Bartik or whatever is on there already. And just make Drupal do these things. And then later on, when designs get approved, you can stick a theme on it, and it'll be fine. So here's a home page. We have a fancy rotator thingy at the top. We have a left-hand side article, just going to be an article node. And we have a right-hand side article, which is also just a node. So very simple home page. But you'll notice that this layout is something, even though it looks really simple, is something that's really hard to do from here. Right? This is our Bartik base, whatever. How would you turn this into a standard two-column layout with a giant thing on top? It's hard, right? And you think, well, it's a really simple layout. Truly, I can use maybe the left sidebar and the right sidebar with nothing in the middle. No, we can't do that. Can't have a page with no content. Yeah, so it's hard. So we're going to start there. Very simple example of using panels. So there's two ways that you can access panels in Drupal. There is a panels dashboard that lets you manage all of your panels right from here, which is fairly straightforward. There's some handy stuff on here. But I never use this page. I actually deal with all of my panels through page manager, which is a requirement. And this will show you all of the pages on your Drupal site. So page is one of my favorite words. What is a page, really? I mean, it's a content type. It's a view mode. It's a views display. It's, I don't know, whatever you want. It's one of these words that we use all the time in Drupal, right? We've now added a page manager module. It's what you manage your pages as a different kind of page. This is a page that actually has to be like a path with some kind of context associated with it. And what you're seeing now is a list of all of these pages that come by default in Drupal. They're all currently gray because the page manager module provides you a way to override what Drupal does by default. And panel's page manager, in particular, is very heavy-handed about how it deals with its display of your content. It basically says, Drupal, I don't care what you're trying to do. Throwing it out, we're doing it my way. So you want a little bit of what Drupal does and a little bit what Drupal does. You've got to kind of be careful about how those mix together. So what we're going to do here is start by adding a custom page. That's this link here at the top, add custom page. We're going to give it a title, administrative description. We're going to give it a path. And then there's a handy little checkbox here that says, make this site your home page. So guess what? Most people start using panels because they want a custom home page. There's a checkbox here to do it. Does anyone have any guess what this checkbox might actually be doing on the back end? Right, so there's a setting under site configuration somewhere that says, what's your home page? And then if you were going to build it some other way, you'd have to go in there and type in home and then hit Save. Well, panel's is like, let's just do that for you. So there's a little checkbox here to that same thing. We're going to come back to what some of these other things are here a little later. For now, on this page, I'm just going to tell it to make it my home page and click Continue. And right now, what we're doing is walking through a wizard. So this is like this nice, friendly, simplified interface to kind of get you into a panel, kind of like views. Like when you first build a view, it's like, what are you going to say, oh, this stuff. How do you want to see it? And you click Save and it's like, bam, airplane dashboard. Panels is exactly the same thing that we're doing now. OK, so category. This will come back to you later. It always starts at builders. Most of the time, you do not want a builder's layout. What that means is it's a flexible layout. You're going to build yourself. This is good for rapid-tip prototyping and we'll walk through it in a minute. But most of the time, that's not what we want. So instead, I'm going to look at the list of two column layouts that are available here. It comes with a bunch of like, these are common layouts. Shoes from here. You'll notice when you start trying to build your own panels that usually the layout your designers have carefully thought out and handed to you aren't in this list. You can add your own. And I've got some code at the end that can show you on how to do that too. So I'm going to choose this two column stack layout because it looks an awful lot like my wire frame. And we're going to click Continue and go to the next step. So now we're configuring panel settings. Most of the time, I don't have sidebars in my theme and I don't have any blocks positioned anywhere other than like the main content block. And that means that I can kind of ignore this checkbox. But if you're doing a half in version with panels where you're like, sometimes I want blocks in my sidebar and sometimes I want a page that doesn't have anything, there's this little checkbox that lets you turn off that blocks in the region's business. So for example, if you have an existing site and this is your first stable in the panels and you want a panel's home page, you can just check this box and on your home page you won't have sidebars. It'll work exactly how you want. For the example I'm doing now, I'm not ever going to have sidebars so I'm just going to ignore that checkbox. So there's also like some interfaces in here for adding CSS. I don't think it's a good idea to put code in user interfaces so I try to avoid that as much as possible but if you need to add like a unique identifier on here or something you can, people like that. All right, so now, I guess you can see it pretty well over there, you get kind of a wireframe of what your page is going to look like where it's like, hey, content goes in here and it looks kind of close to what we want which is pretty good. So I'm going to fill some stuff out here. Let's say it's like a welcome, put a little title on it. The top, we're going to add a fancy rotator thingy which I've created before. It's just a views slideshow, no big deal. On the left hand side, we're going to add a node. So when you add things in panels, there's like a little cogwheel at the top of every region where you can drop stuff in. So you can drop in content by clicking on the cogwheel and clicking add content. Guess what, in panels everything's content doesn't matter what you're adding. And then there's categories on the left hand side that dictate where this content is coming from. So this is like a smarter take on blocks where in blocks everything's just in one giant list. Panels tries to divide those blocks into different categories like activity. These are like blocks added by the user module and menus are like, these are blocks added by the menu module. So you can actually find stuff a little bit more easily if you have a giant site, lots of modules adding lots of blocks. It's really hard to find your blocks in the blocks list. So Panels is trying to make it a little bit easier. I've added my own category here called genstuff. I did this through the views interface. You guys have questions about how to do views configuration for panels at the end. I can show you a lot about that, but I'm worried about running out of time. So just say, hey, look, gen added a thing, that's cool. It also gives you the option here to add existing content. So if I just wanna add one node, I can click on this existing node option and it says hey, enter the title or the NID of that node that you wanna add. So it'll say, okay, let's see if I have a node that starts with A, we'll add that one. And then it gives you a bunch of options on how you want this node to actually appear. So if the title of this node is different than I wanted it to actually appear, I could override that. You can link the node title to its node. So for example, if I'm only gonna display a teaser here and I want people to get to the rest of the content, you can do that. It gives you an option to include or exclude those node links that usually print out at the bottom. I'll leave those two. And then if you wanted to use a specific template file to render this node, this is like a theme hook suggestion, you can type it right in here. And Panels will use that to render your node too. Again, I tend to like to let Drupal do as much as it can by default, but people really like changing stuff here, so you can do that. And there's also a dropdown here for your build mode. So if you added your own custom build modes and you wanted a front page view of your node, you can do that too. I'm gonna leave this as teaser and click finish. So we can do the same thing on the right-hand side if we wanted to add another node. Instead, I'm gonna add some custom content. This is Panels equivalent of a block. So it gives you an administrative title. So if you wanted this to be different from the actual title, you can. And then title, let's make it some dummy lipsum. And then the way Panels content panes work is you have the option of making them individual or reusable. So if this is a piece of content that will only ever appear on the homepage and I want it to be something like, welcome to my website, thank you for coming to visit. It's not important and I don't wanna index and it's just some little bit of content. I can just click finish and this'll embed itself right into this page and only exist right there. But if I want this piece of content to maybe also appear on my landing pages, like maybe it's a promotion for some feature that exists in my company for a little while. I can click this little checkbox. This also is provided by a different module that comes with Panels called custom content panes. And this will let me save this block. It's called the content pane for later. So I can call this, so this category box right here is asking me which category on the page where we choose content this'll fit under. So I'll show you this in a minute, but if I call this something like smart stuff, we'll see that in a minute. Okay, so I've created a smart block. I've added some standard node on the left-hand side and my slideshow at the top. So something's a little confusing. I just clicked a finish button, but I'm not actually finished. Panels is a lot like views where it's got that two-stage save where you can click update, update, update, update, and then when you're done with all of your updates you click save. It's the same thing with Panels, where you've got to update, update, update and save. Only occasionally you also have this update and save button, but you don't have it when you click finish. That's confusing, so we'll fix that. But you click finish and then you're not finished and then you click save and then you're finished. All right, so now if I go and look at my home page I should have a rotator at the top, which I'll rotate if I'm not on it, and then a node on the left and a piece of content on the right. So one thing you'll notice is that right now I have a block in my sidebar, right? Old school, Drupal block, Drupal sidebar, and it's messing up my layout, right? So there's two ways I can solve this problem. One of them is just take a block out of the sidebar. The other one is that checkbox on the panels page that says disable Drupal blocks and regions. So if I go back to pages and we edit the home page, gets under general, disable Drupal blocks and regions, click update and save and go home. Now it's gone, yay. Okay, I thought it was exciting. So this is one of those things where if you have a need for regions that are already built all over the site you've already got blocks in them and you want one panels page you can use that. I don't actually recommend doing that because what this is still doing is going into the database and getting your block and wrapping it in your theme function and getting it ready for the page and then panels go screw you, I'm doing my own thing, we're not printing this block and then all of that time is wasted. And that's just kind of how the block system works. So we're gonna ignore the block system entirely, turn it off if you want and just use panels. I'm going back to blocks. In this case I will just remove my main menu from the first sidebar and then every other page I build will not have a sidebar. Unless the layout I choose in panels has a sidebar in which case I can put that stuff in. So we can talk about that later too. All right, so now we have a homepage that has a fancy rotator, kind of going really fast but and the content I wanted on a page. Let's do another page shall we? That doesn't seem so scary. All right, so the next thing we're gonna do is configure a blog page and what we have here is blog post on the left-hand side and we're gonna put some information about the blog author on the right-hand side. So this is something where if you had your standard Drupal block system, you'd say, okay, blog post in the content area, no problem. Go and configure every block on my site not to appear in the left sidebar, now the left sidebar is gone. Now I need to go and add something to the right-hand sidebar that will be some kind of blogger profile information. So you can either write a custom module and put in your own hook that builds whatever this is and there's a block there and you can add that or you could try and figure out what combination of other modules will let you turn a node into a block and then you can put that in your sidebar or you can try and figure out how to stick a whole bunch of individual fields in there but the biggest problem is that the content that's in that sidebar doesn't really know anything about the content that's next to it. So how do you make sure you get the right author for your node? And there's some ways you can do this by checking the URL string and pulling out the ID that comes after node and then loading the node and then pulling off the author information and loading. It's kind of a mess but Drupal already knows who wrote that node. It loaded that node. It has all that data. Why can't it just tell the sidebar next to it? That's who it is and that's what panels does. That's the concept of context. This is another word like page where we use it. To me, lots of different things. There's a module called context. It's something the same problem. Drupal knows stuff it's not telling you about. There's stuff going on in the page. It knows who you are. Who's looking at this page? Do I know your user information or are you logged out? It knows the content that it just loaded. It knows information about the user who wrote the content that it just loaded. It's just not printing all that stuff out on the page. And so most websites are trying to be smart and dynamic and the stuff on the page knows what else is on the page but it's just really hard to get Drupal to do that in blocks. So panels are a little bit smarter. All of their content panes know what's going on and the rest of the panel only can talk to each other. So we're gonna build this page now by using the node context that's provided by the page manager module to put all the stuff about the node on the page. All right. Structure your pages. So you'll notice that one of the grayed out options here is node percent node. This is a panel's kind of token thing that's saying there's gonna be a path node slash one, node slash two, node slash whatever. And whatever that percent node thing is, that's the thing in the URL string that panels will use to build its context. And in this case, it's a node context. You can use these two. You can add these contexts to anything you want. So for example, in this case, there's a node percent node. That's the view of the node. You'll notice there's another one here that's a node percent node edit. That's the edit form for the node. So if you wanted to provide a layout for your node view that exactly matched the layout for your node edit, you can do that. You can leverage both of these things. If you're using some kind of module like web form where the path is node percent node slash web form, something like that, you can do that too with panels. You can just say, hey, here's the node we're gonna use and I'm gonna use this layout on my web form. So you can leverage these things too. And we can talk about this more at the end if people start getting all glazed over and don't wanna talk right now. But panels provide these for you by default. So you don't have to understand what that crazy context is. You can just use it. So that's what we're gonna do now. For one of these ones that's provided, you've gotta enable it or it won't work. So now this interface has changed where the first time you click this button it always says enable, so it's a little bit more helpful. But if you ever find yourself editing one and you're looking at a node and you don't see it actually doing what you thought it was supposed to be doing, make sure it's enabled. Cause it's really easy to build something while it's disabled and never actually realize that your code is working. So when it's enabled it turns black, so that's helpful. And then we're gonna click edit. So we have enabled this thing, but it still isn't actually doing anything because we haven't added what panels cause a variant. So this is another one of these crazy panels terminology words that means a variation on the same thing. So you can have one version of a node display that works for a blog node and another version of a node display that works on an event node. And that's what we're gonna build. But you can also have something like a page node that isn't affected by panels at all and it'll fall right through. So the default behavior you're here for our panelists is to say, I'm gonna do nothing until you want me to tell me what to do. So we've enabled it but it's still doing nothing because I haven't told it what to do. So we're gonna start by adding a variant here which will use this context. So we're gonna click add variant. And there's a couple different ways to do that but I like this tab at the top. And we're gonna give it a title. And this first title here is a sanity thing for you after you've added a bunch of variants. You're gonna need to know how to tell them apart. When you first just add one it'll say something like panel which isn't very useful. So just think about what you wanna call this. In this case we're building a variant for a blog type node. So I'm gonna call this blog. There's only one option. Well, I guess we're only gonna use panel for variant type that you can do other stuff like if you had some blog where only the blog posts were publicly available and every other content type required a login. You can put a response code on there to do an access denied message. Crazy stuff like that. We won't do that today. All right, so the next thing we're gonna add here is a selection criteria. So if I don't add any selection rules this would fire for every single node on my site. But I don't want that to happen. I want it to only fire for blog nodes. So I'm gonna choose this option and in the next step when I click create variant it'll ask me what the selection criteria are. So this is very similar to using context or rules or anything else where there's conditions that you're adding. When should my thing I'm configuring actually happen? So here we're just going to add a check for node type. So I'm gonna click node type, add and then say when it's a blog I want this variant to be used and click save. It also gives you options to say like no do it when it's not a blog, however you wanna handle it. So we've added a node type variant for when it's a blog entry. We're gonna click continue and now it goes back into that standard wizard thing. What category of layout do you want? I think it was a two column layout. Oh but looky here. So the layout we're trying to build is like 60, 30 right in the split. But if you look at the layouts that are provided under two columns we don't have a 60, 30 option. So now we can actually go back to that builders category and build our own. Like well, I just need to show this to the client and make sure it's actually what they wanted. So I'm just gonna build this really quickly right in panels. So again we don't need to disable for bull box and regions because we've already turned off that block. So the first thing we get to when we get to this wire frame is kind of an empty wire frame that's like we're gonna give you one area we're gonna call center. But there's a little button here that says show layout designer and this is what lets us build our own layouts. So this is a little bit confusing because there's a lot of different elements. You kind of can think about it like an HTML table. Don't worry, I won't print an HTML table. But that's how I like to kind of try and figure out where I'm adding stuff. And in this case I really just wanna add one column. It's gonna be like a sidebar on the right. So under the canvas option which is the outermost container here there's an option to add a column on the right. And so you can add a class there if you want. But if you just let it be fluid and click save panel gives you this handy little like ooh I can drag it to whatever percentage I want. Which is pretty cool. So I'm gonna make it like 66 close enough. And I've got a 60, 40-ish maybe close enough. Layout. And then in the column on the left-hand side I need to add a row because I'm thinking about like a table. Table has a row and a column. And then inside that row I'm gonna add a region. So this is equivalent to the regions from your template files that you're used to working with. The region is the only thing that absolutely requires a title, I'm gonna call it right sidebar. And so now I've got a sort of a layout here I can work with. And if I click create variants it'll give me a wireframe that looks like the layout that I just built. So a really easy way to just drop stuff into whatever you want. So now I can go ahead and add my content. On the left-hand side I'm gonna add the nodes that I'm looking at. So when I go and click this add content cogwheel that we've been using before you'll notice that there is a new category on the left-hand side called node. This is only there because the node context is available to us in this page. This is something that Drupal's added for us. We're using the default node percent node thing. It has the node context there. If you wanted to do another one of these things for yourself you'd need to add node as a context to the thing and then node will appear in the left-hand side. So under node there's a bunch of stuff in here that you can use. You can use node content, which is what I'm gonna use. And this just renders your node like it would normally render it. It lets you choose a view mode and just drop it in. But if you wanted to do something like pull out individual fields and display them differently you also have the ability to do that here. And this interface is smart enough to know that I have already limited the node type to blog. So it's only gonna show me the fields that are on the blog node type. So it's kind of, you know, panel's nodes, this is a lot, this is another crazy interface that Eromeil has invented to do absolutely anything you could possibly imagine that makes it hard to use. So it's trying to kind of thin out some of the options that are not anything that, there shouldn't be anything on there that's gonna break anything. So I'm gonna use node content and just drop in my entire blog node on the left-hand side. It gives me some options like, which node do you wanna see? Well, I wanna see the node that I'm looking at. But if you had added some kind of relationship like if you had a node reference field or an entity reference field, you could choose to show the node that this node references instead of the node you're looking at. It's getting all complicated, but crazy stuff you can do. I'm not gonna link the title to the node because I'm looking at the nodes which is linked to itself, which is a little silly. I'm going to include the links and node extras is a little confusing. Right here it has some information that's actually wrong. I like to think of node extras as showing stuff like comments. It says here like CCK fields, but that's obviously, this is Drupal 7, there's no CCK fields anymore. Just hasn't, help text here hasn't been updated. So I'm gonna show comments. And then it gives you an option here of how would you like to see this content. It's a little bit silly to put a teaser display of your content on the node display page unless you had some use case where you wanted people to pay for a subscription service to your website. And if they weren't paid, you wanna show them a teaser and then after they've signed in and paid, then you can show them the whole content. Most of the time, if you're on the full node page, you want the full content to display here. All right, so we've added our node content to the left hand side. In the right hand side, we wanna add some information about our blogger. So maybe their photo or their whole user profile. So we're gonna go ahead and add some content and you'll notice there's a user option here. So under user, we don't have anything available because we haven't added any information about any particular user here. So under node, we've got like the author name, which I think it's just called author. This is something that comes when Drupal 7 loads a node, you know who created it. So it'll load like the theme username function and load that, but it's not our profile. That's not all of the information we want about our author. So we're gonna go ahead and close this window. Save this, just, you know, it's always good to save stuff. And then under the, this is not where I wanna be. Under, so we're gonna go back to the page manager interface and we're gonna try and add a relationship. This is a little bit confusing. So views has things called relationships, panels has things called relationships. They're not quite the same thing, but what we're basically trying to do is take information we don't know from information we do know in both cases. So what we have here that says the context available, we have a bunch of information about our node. We need to add a relationship between this node and its author. So under relationships, I can go to user from node. You'll see this is a very common thing people wanna do, so it's provided here. You can add your own too, we can talk about that later. And add the relationship. So it'll say, okay, which node? Well, obviously the one I'm looking at. What do you wanna call it? I'm gonna call it something a little bit more useful like author. And then it says what do you wanna call it? Keyword, this is just for your own sanity. User's gonna be fine for me, so I'll leave it there. And so now we have a relationship for our author user on node. So this should give us a second context available. So now we have all of the information about the author here also. So if we go back to the content display where we were adding stuff into the sidebar, click on the cogwheel and click add content, we should now have a bunch more stuff available under user. So this is all of the stuff that Drupal knows about that user. For example, the user profile information is also available right here. So if I click finish, update and save, we should be able to look at a blog post. So actually I'm not sure which of those are blog posts. So we're gonna go here and grab a blog. And we should have a giant blog display on the left, the fancy develop generated image and some content on the right with our user and how long they've been there, standard user profile information. All right, next task. So we've now created a page for a blogger. If we wanted to do exactly the same thing for an event, it's the same process here. This does not actually have an author context provided, but you could do something like if you had, I don't know, you're offering trainings and all of your trainings were offered in one of eight locations. You could have that location be another node where you're like, this is a facility where we train. And you could do exactly the same thing by adding the event information on one side and then the referenced node information on the other side by building that relationship in. My demo site, I don't have that kind of relationship. So we'll just really quickly walk through adding second variant so you can see what that looks like. We're gonna skip the location plus map step here on the sidebar. So back to structure pages. And we're still editing the node template because we're changing the way nodes look. But now we have one variant here. It's called blog. We're gonna add a second variant for events. So again, the add variant button at the top, we're gonna call this one event. We're going to add a selection rule because we still want it to apply only the event content type. Under selection criteria, we're gonna choose node type. We're gonna select event. And then if we go back and look at our two column layouts, you'll notice our two column layout from before isn't actually here, right? We built one and it's not here. So what I'm gonna do, I'm just gonna choose a one column layout with nothing in it for now, but I'm gonna go back and edit that other layout. So really quickly we'll just create this variant so we can come back to it later. But if we go back to our blog content type and look at its layout, you might have noticed this before, there's this button here that says reuse layout. So in the real world, if I was gonna build this on an actual website, what I would have done is built one prototype, showed it to the client, said, is this what you want? They would have said yes. And then I would have written my own HTML and CSS to create this layout rather than using this layout builder thing. And there's a couple reasons for that. Number one, anytime you're saving information in the database, when you can be reading a file from disk, it's slow. And I don't like to build anything into my website that I know is unnecessarily slow. So if you can have a HTML template, that's really fast to read that from disk, especially if you're using APC. It's just, here's your file, no problem. What we're doing here is not even just saving like configurations, there's like a bunch of calculation that has to go on. It's like, where did you drag that thing to? What value was saved in the database? How do I write the CSS file to put it exactly where you want? It's just a messy process to build a layout using a drag and dropper. So it's really cool for rapid prototyping because you can build anything you want really fast. But in the real world, as soon as the client sends off on that, I know most front-end developers would be like, don't show me any markup output by panels. And this is just another place where you can make your own nice, pretty layout at the end. But people need it. Here's a reuse layout button. So in this case, we're going to take our previous layout that we created, we're going to give it a title, something like a right sidebar, or to call, whatever you want to call it. And here's the category. So if we want this to call and layout to appear in the same category that was on the little drop down for two column layouts, you can. But you've got to get exactly right, which I think is columns, colon, space two. If you forget the colon or the space, something, it'll add a new category. So we'll see if that is going to work. All right, so we've tried to reuse that layout. Go back to event. We're going to choose a layout. Let's see here. Columns, colon, space two. And we should have a two column right sidebar. Now, does anyone notice anything wrong with this picture? There's a picture there. And it is not a two column right sidebar picture. This is really frustrating. There's an issue against panels. We're trying to fix it. Or Earl's like, fine, make me a picture that's better. And then none of the people in the issue knew how to make pictures. So we're like, OK, maybe somebody here is going to make a picture. Anyway, so it's going to show you this picture for every single layout you've built using the flexible layout tool. So if you have like eight custom layouts, they're all going to look exactly the same. And the only way you can tell them part is this little tiny bit of descriptive text at the bottom. When we get to the end, if there's time, there might not be, I can show you what a custom layout looks like. And you can add your own icons and make them match your website design. It's really fun. But we'll see that. We might not get there. OK. So if you change layouts in panels, it'll ask you, OK, well, we're changing from one layout to the other one. Where do you want me to move your stuff from? So you can drive stuff from one region and drop them into another. In this case, we didn't actually have any stuff. So it's asking us, where do we want to move our stuff? But it's not there. But you can. If you have to move it in, you'll notice it's pretty cool. All right. So we're going back to content. We can add some stuff into the center column. Again, this is just our node. So under node, we're going to choose node content. Full node. We're going to uncheck this link box. We're going to leave the extras. OK. Right sidebar. And this is a case where we could add. You'll notice that this is not tokens. This is the event type node. So the fields that are available here are different than the fields that were available on the previous node type. So if I want to do something here, add the date field separately on one sidebar as opposed to the other one, you could do that. You can choose either override the title. You can use the label from the field settings if you wanted. You can control that here. You can choose a formatter that's different than your field settings formatter. All of that crazy stuff that you control through field UI is also mushed into your panels interface. So it's messy. But everything you could ever possibly want to do is possible. OK. So we've added a field. Now, one thing you'll notice if we go and look at an event node is that we're going to have the date on the right-hand sidebar where we wanted it, as well as in the left-hand side. So there's a couple of different ways you can solve this. You can either add every field individually onto your node layout. I don't like to do that because I think that in the future someone will add a field to my content type. And if it doesn't display on the page, then that's bad. I want it to be there automatically. So instead, what I do is every time I display an individual field separately, I pull it out of the node display. And I do that using field UI. So yay, structure, content types, event, managed field, display. And so here you have the display of date information. So we can just say, don't show me a date, save. And then if you go back to your node display, your date won't show in your full node view. And it will show in the sidebar. Another, if you really like view modes, you can create a view mode that's like, this is what my node looks like in its panel. Or you can have a left sidebar view mode and a right sidebar view mode and group this stuff together. There's lots of different ways you can, anything you want, possible. So running out of time, next one. So user profile page is like the worst page in Drupal by default. You can, obviously, rearrange this to look however you want it to. It works exactly the same as a node. There's a context provided in page manager. User, user, right? If you enable this, you can override it. Define your layout, define your content. I think we should skip this one because there's cooler stuff I want to show you. Taxonomy term page, this is really cool too. OK, we'll do this one really fast. Same thing here, where there's a taxonomy term context provided. All the stuff in core is duplicated in panel. So you want to override this too. So we're going to click enable here and do the taxonomy term one. So taxonomy term template, edit. Again, no variance. So if you wanted to have your River of News style, this is all the posts in the category, whatever, be different for your vocabularies. You can do that. So if I wanted to leave the default display for tags, you can do that. But if you want to change it for categories, you can do that. In this case, I'm going to put an add in the top left events only in the top right and then the rest of the articles underneath. So I've got an events content type. I've got an articles content type. And I want those things separated out on my listing page. So people can see, oh, here's events that are relevant to San Francisco Bay Area. And here's all the articles that are relevant to the San Francisco Bay Area, and maybe like your SpotoGat. People don't really just want a River of All content in a category. So this is a good way to split those up. So we're going to add a variant here in the same way. So we're going to add selection criteria. We're going to call this one. I have one vocabulary called category and one called terms. So I'm just adding one here called category so this will match my vocabulary name. We're going to add a check for the vocabulary here and make sure we're using category, so tags. And then we're going to continue to the layout. Looks like two column stacked again to me. Keep going. OK. So in the left-hand side, we just had some kind of add. So I'm going to use a custom piece of content and say this is an add. Not going to reuse that. Right-hand side, events in this category. So I've already created a view that shows only events in this category. It's called term events. So I'm just going to drop that in. And at the bottom, we have our standard text on any term view, which is called term content. And this view has been configured to exclude events. So finish and then save. OK, so now if I go back to my taxonomy list, find a category and look at it. We should have a list of events, the top right and at the top left and stuff at the bottom. Now taxonomy is pretty interesting because not only did we override a panel that was provided from page manager to get that context, but I also had to override a view. So the views module provides a view that overrides the default behavior of Drupal, right? So there's a lot of stuff going on here. By default, the taxonomy module provides a page that gives you a river of nodes. Then the views module says, hey, people like to change that. Here's an override of that core page that spits out all of these modules. And then the panels module gives you a panel that overrides the views page. So it's a little nuts. The way that I deal with this is I come into the views interface, enable the view that's provided. And then the only thing you have to change is the page display. The views module provides has a path. And in order to get panels to work, panels need access to that path. So if you change the path that the view provides, panels then can use the path that core provides. So all I did was change this from taxonomy to taxonomy old. And that also gives me a way to test to make sure the stuff I'm doing in my panel is doing the same thing that the view used to do. And then I can make sure stuff is actually working. So views also has a special type of display called the content pane that is meant specifically to work with panels. So just how views pages have individual settings that only relate to pages, like a path and a menu. Content pane has particular settings that only mean anything to a panel's user interface. So in this case, we have a way to label this view, which is called an admin title. A category, this relates to the category that's in the side when you add a piece of content to a panel page. And you can create all of your views to match to the kind of things that you want them to go with. So in this case, I named the category here taxonomy term. So that would appear with all of the other stuff that panels provides by default for taxonomy terms. There's also other ways you can think about it. If you have, depending on what your site administrators or editors are gonna be dealing with, you might have 500 views that have to do with news and you wanna have them in a group of their own. So if it's a news category or like news recently or news, whatever, you can have all of those news stuff together instead of what I did here is to group it with taxonomy terms because I wanted all my taxonomy stuff together. So kind of thinking about how people are gonna interact with your site means you can customize your panel's user interface to match your user workflow. So it's bad, panel's user interface is bad. You can make it a lot better just by thinking about how people are actually gonna be interacting with it, which is pretty cool. There's also some options here that you may or may not have noticed when I was dropping in a views content pane into a panel. You can allow per instance things to be changed about your view, like whether you want the title to be overridden, this is something that blocks provides, right? When you put a block into a sidebar, it says what do you want the title to be? Panels can do that too. There's also other things you can override about panel panes, like what if you wanted a different number of items in different places? So if it's in an area where you only have a limited amount of vertical space, you can say show me three instead of 10 or if it's in a place where you wanted to have a more link or you didn't, you can choose that when you're putting it on the panel. And this doesn't actually change the views settings, but every time you use the view, you can do it differently. So if you wanna take this list of content and put it in several different places, you can have it different in different places without having to change your view because you've changed it in your panel. Whoa. All right. There's also some other cool stuff, the contextual filters. And this is a little bit confusing too because in Drupal 6, these were called arguments. And so when everything got moved into Drupal 7, half of the interface got changed. So on the right-hand side here, it says contextual filters. And in the metal, it says argument because this is the panel spark that didn't get updated, but the views, it's the same thing. It's confusing, but it's the same thing. We're gonna fix it maybe in the future. So contextual filters. Never understand what these are in views land. Okay. This is something that when you put a view into a panel, panels wants to know where do you get that value from? So if you have something that's like taxonomy slash term slash two, two is the value that you need to get into that view. And if you're now saying, I'm gonna put a view in a panel, two is the value that needs to get into the panel. And then the panel needs to pass the value to the view. So it's basically like this handoff of like, I have this number two and panels is like, I stole it from Drupal. And then views is like, well, I stole it from panels. And then all of your content panes can steal it from panels also because it's available. This is this context, right? It's something that Drupal knows about and then panels knows about and then everything in your panels can know about. Your view is one of those things in your panels that can know about it. So in this case, we have a way to configure which arguments are being used. So taxonomy term actually takes two, right? It takes two arguments. The first one is which term and the second one is the depth and you can pass both those through. So here is where views is saying, where do I get these arguments from? And you can say, get it from the panel. So this gives you the ability to pass any number of arguments and your panel can say, well, I'm gonna use, the thing on the right is gonna use the first argument. The thing on the left is gonna use the second argument. And depending on that page, you can make your panel super rich and dynamic. Crazy, all right. So we've got two minutes. Should I see, what do you guys wanna see, code? Or do you wanna do another example? Okay, custom layout templates? Anything else? Okay, so we're gonna jump to code really quickly. I thought you might wanna see custom layout templates. So it's actually really easy to provide a template to panels. This is the plugin system in panels. There's a new plugin system in Drupal 8. It's kind of like loosely similar because we're doing a lot of stuff similar to how panels did it. So what you just have to do is say, hey panels, I have a new template. Its title is new column, its category is two. This is the little icon that matches the rest of my site's theme indicates what it's gonna look like. This is the theme function that gets called. This is the style sheet that gets added and these are the regions that are inside it. So it's a lot like a info file for a theme. Only this is just a PHP array. So it's module speak. I've got this in a module. You can put this in your theme too. I don't recommend it because someone you change your theme, your site will break. So just find a plugin just like this and then you define a template file. So in this case, this looks a lot like the code that panels outputs. HTML and purists would be very upset about that but I just copied it just for example here. So I've got a container with a container with more containers inside it and then there's like some content in there somewhere. Prince out the name of the region that we defined in our ink file. Then there's a style sheet. Includes all of the styles that dictate the region or the layout. So there's kind of a trade off here where you have to decide how much of your style is married to your layout and how much of your style goes in your theme. And for me, it really depends per project where that code lives. Because sometimes when I, let me just turn on this module so you can see what it looks like. When I go to put content into the page, I wanna see like this has a gray background or this has a green background so I know which row stuff goes into. So I have a module here called custom panel. So I usually do this for all of my websites for all of the customizations, the stuff that I write for panels goes in and I also can put the panel's exports in code in there too, which is kind of handy. So now if I go to my page manager interface and edit say some existing content, like a blog, if you wanted to change the layout, in the dropdown you have a new option here that says new. In here you can have like cute little color coded icons that indicate what the layout will actually look like. So if I change this to this two column layout here instead of the two column layout I had before, it says where do you want my content to go and you can say well let's put the right sidebar content into the right sidebar and then if you go and look at that, let's see it was a blog, right? So there should be a, whoo, I didn't like. Did I save it? Oh that was a page, look at that, blog entry. Okay so then you've got this like gray background on the left hand side. So it really depends on your layouts, like whether you want that style in there or whether you just wanna say this is left, this is right, which is based on site. So the way that I organize my fouses and sites all modules or site sub-site modules or whatever, I usually divide my folders so I have like contributed modules, I downloaded from dribble.org, then I have a folder for all of the custom modules that I wrote myself. That way when it gets around time to upgrade, you know the stuff you can just upgrade via Drupal and stuff you have to write your own code for to upgrade and then all of my custom code I put in that folder. So this is code I wrote to control your layout so I put it in a module I called GenPanels in this case for this example, inside the custom folder and then inside that module is just an info file like your standard module and then you just define two functions, in this case we've got one called this is where my plugins live and you drop your layout in there, you can copy and paste this from any existing Panels module, it's not too scary in fact I can even post this code after this so you can see it. And then making sure you have the right version of the C-Tools API and this, well I'm running out of time. But so then you have in here I've got a folder called layouts for all of my layouts for this particular site live. I've got one here called one column layout which I have a little blue bar at the top and then I've got new two column layout which is left and right. And then as long as you just drop your code like your ink file right in here, Panels will find it and it'll provide it and load it into your interface for you. So it's really easy to write your own layout, it's just like writing your own template file. There's a couple of other stuff I like to add to all my sites like didn't actually get to this but for any custom content pane or content pane you've added to any page there's an option to change the styles. So after you've added a piece of content into a region there's a cog wheel on the right hand side that lets you configure that content. One of the options in here is the style, right? So by default Panels renders these things the way it wants. There's a bunch of options, right? If you wanted to render it like a block there's a system block style that'll use the block dot tpl dot php instead of the panels dash pane dot tpl dot php. You can also say don't put any markup in there at all. I hate panels markup and leaving it out. There's also some options like rounded, rounded corners, it's a style sheet that Panels adds that adds little rounded corners everywhere. I like to add my own. So if you want a really easy way to change your title tags, right? If you have a landing page it's really important you don't want to have a, you want to have a h2, it's an h3 or something you can do that if you have little tiny ones that are important on H5 you want no title at all. I find this much easier than clicking the box it's a title override and typing in none in those little alligator black brackets. So I provide my own styles and sometimes they have other colors, this one's blue, this one's red, whatever. And those are also really easy to add. So those you can just drop right in here too and it's just another plugin definition that says, hey, you know this is a style and this is the theme function that you should call and then here's the theme function and what it returns. So this is more like programming theme stuff but you can also provide your own template, right? So if you had like, here's the H4 version and all it does is print like an H4. You can, you don't need to. I would not recommend it. If you're already using panels and if you're already using Context you should not have panels also. They do, they solve the same problems. So you don't need both of them and if you have both of them you're just gonna get yourself into a world of hurt and then both trying to do the same thing. So just for a single page. So yeah, I still would not recommend using Context and panels at the same time. I just think it's like, it's too much of this, like there's gotta be a way you can solve that problem with like display suite or something else with Context. You still need panels for panelizer. It comes with C tools so it's still there. It's just a lot of code. So this is the thing where like in Drupal land like you can solve any problem many number of ways, right? And I would recommend not solving the same problem two different ways on the same site. It's just architecturally gonna be really hard for you a year from now when you're like, I'm not great at Drupal 8 and you're like, uh, just, that's the closest thing I can go. No, I don't know. I mean, so I solve every problem with panels because I know panels, I've been using panels for years, I love panels. Every problem I run into that needs a solution that Context can provide, panels can do too. It's this kind of thing where like, you know, display suite can do what panels can do, Context can do what panels can do, PHP can do the Contemplate, whatever. All of these things, all of these problems that all of these other modules solve, panels and page manager can do. So for me, it's like less code on my site if I can solve it one way. You might be running into a use case where you're like maybe the tools you have right now can't solve that problem, but there's probably a little tool you can add that can solve the problem that's not as big as panels, page manager, panelizer. Yeah, I think it's just, you just need a smaller tool for that job. Or yeah, you could remove Context and use panels for everything Context is doing. No, I mean, so this is the thing where like, it's really easy to get 80% of any project on, right? Just like click the pieces together and the last 20% is really hard. And sometimes like, the last 20% is like, oh, let's just remove the 40% and then it's only 5% more. I don't know, there's probably an easier way to do it. Yes, over there. Yes, yes.