 So today, we'll be talking about layouts and landing pages. That's what all of you are here for, right? Start off the day with some site building and some theming. My name's Suzanne Dagacheva, and I work for a company Evolving Web. We're based in Montreal. And I do a lot of Drupal things, particularly like training. So I run a training program at our company. Also do some site building, some theming, some development. And you can find me on Twitter at Suzanne underscore Kennedy, so a little easier to spell than Dagacheva. Today, we'll be talking about layouts and landing pages in Drupal 8. So I think there was a presentation earlier this week about content layouts. So we won't be talking so much about just standard content types today. We'll really be talking more about how to make landing pages that look interesting and work well. So we'll walk through planning out landing pages, because that can be a bit tricky. Whether you're a site builder or a themeer, you're probably hopefully involved in that process a little bit. We'll talk about different options for configuring landing pages, so hundreds of different ways to create landing pages in Drupal 8. We'll talk about maybe five of them. We'll talk about maybe creating a layout in your theme, the overall layout of your site, and then also different approaches to theming those landing pages you've set up. So how many of you are like wear a theming hat sometimes? Like you walk into the office and you're writing CSS? How about site builders? We're all site builders, right? Who's not a site builder? Who doesn't touch views? Someone asks you, configure me a view, and you just say no. Anyone? Anyone? Yeah, you guys are hardcore. Awesome. Got to delegate that to the site builders. Leads them something to do. So really planning your landing pages. We're going to be talking about this more from a site builder's perspective. So if you're wearing your site builder hat and you're the one who's going to be making all those views and creating all those content types, what do you need to know from your design team? What do you need to know from the client before you start building? Because there are so many different approaches that you have. So take a look at any landing page. Did you all know Drupal.org has this new fancy landing page? How many of you have seen this? Yeah, how many of you think it's awesome? Woohoo, Drupal. Some of you seem non-plus. I could do better than that. Yeah, so landing pages are there to target a particular audience usually? Maybe in this case, I don't know, Drupal developers, Drupal people like us. Usually there's a lot of marketing content there. So unlike a typical page that's more like a standard content type, you have a lot more marketing stuff, like calls to action. Do we use the word calls to action here? Is that part of your vocabulary? Calls to action? CTA. You see that written on mock-ups and wireframes? You're like, oh, I hate that word CTA. That's supposed to mean. So usually landing pages like this, they have more of a marketing feel to them. The marketing team gets involved. Everyone at your company is arguing, what are we going to put on the landing page? What goes first? And so usually there's more of a distinctive layout. This page, this doesn't look like Drupal.org to me. What kind of layout is this? It doesn't really fit with the flow, right? Usually there's some kind of desire to funnel users towards other content. So you see a lot of content aggregation going on. And sometimes you see actually things that you can do on a landing page, like sign up or start a search or something like that. And so these pages, like I said, they take typically more planning than just a standard content type where you're building up the fields and you can easily figure out how to theme it. So some questions to ask. Like you're sitting there at the kickoff meeting and people are planning all these landing pages and you're like, whoa, whoa, whoa, slow down guys. How many landing pages are we talking about? Is this just the one home page of Drupal.org that's super fancy and then we can go back to business as usual? Or are there going to be hundreds of these things? So you really want to know is this a template that you're building out or is it actually just a one-time thing? And who gets to decide what's on the landing page? Like is your marketing team going to be sitting down every morning saying, OK guys, what are we going to put on the landing page today? Or is it going to be Drupal that magically figures out the best content to put there? Keynote has a mind of its own this morning. And do calls to action need to be reusable? Like calls to action, you'd think that if there's a call to action that's good on the home page, maybe it's good on another page too. So you've got to figure out how much of your content's actually going to be reusable. Is it going to be updated all the time? Do the editors need to be able to move it around? And is someone going to come along every week and decide to change the layout? Like is it really going to be a volatile kind of design environment where anything goes? Or is it going to be like a preset layout for your landing pages? So these are all things to figure out. Tough questions. Your designer might be kind of upset with you, but you've got to ask the questions right off the bat. So we'll talk through three main use cases today in terms of configuration. Creating a reusable landing page that's more like a template, like a landing page content type. Setting up one-time use landing pages, so more like the Drupal.org home page. And the third one, creating a landing page with a flexible layout. So that kind of more cowboy style where it's like anything goes. We want to be able to change the layout at the drop of a hat. So reusable landing pages. So I'm looking at a design like this. This comes up often. Have you guys seen designs like this? Or is this the type of thing that you're seeming? Yeah, you're like, yeah, I have to go back to the office on Monday. I'm going to be working on this. Yeah, so these two pages, they look pretty similar, right? There's this green banner thing up at the top, and then there's these kind of marketing texts that somebody wrote further down the page. And they kind of follow a pattern. There's these bands of content, but there's some differences, right? Like spot the differences. You've got videos on the left. If you look carefully, there's like a download link. There's supposed to be a file that you can download from one of those. There's some images. There's background images. There's like light on dark text and dark on light text. And you're just starting to shake your head like, oh, I have to theme this thing. How is this going to work? Why don't we just write this all with like inline CSS and call it a day? But then you come to the list of requirements. Like you do your job, you plan ahead, you ask the questions and it turns out, yeah, we need to be able to build tons of these things. So it's got to be some kind of a template. You have to have a consistent styling, like because you don't want to go, you don't want to have ridiculous expectations of your CSS, right? You want to have some kind of some patterns that you can identify that you can actually style. So you don't have inline CSS. Editors need to be able to update the text, maybe move things around. And it turns out that, yeah, you have these different types of calls to action. They're not all exactly the same. You've got the videos. You've got the text. You've got the images. So you've got some work cut out for you. So if I'm looking at this as a content type, okay, there's a landing page content type, easy. You've got the banner section up at the top. Let's just say those are fields. And then you've got these calls to action. And this is really where you're wondering, like what approach you should take. So another similar kind of mockup might look like this. Similar pattern with the banner at the top. And then these calls to action and you're still scratching your head. So one approach we can take is using paragraphs. So how many of you have used paragraphs? You're on the bandwagon? Yeah, paragraphs. So you can create some kind of paragraph type for your calls to action that have these consistent kind of fields, right? And you can edit the paragraphs when you edit the landing page. So this is important. I think we're kind of site builders, so we're used to clicking around in Drupal. But the fact that you could click edit on this page and edit all the things at once, like that's a big deal. Editors are gonna love that. So don't make it seem too easy. Say, yeah, this is gonna be a lot of work, guys. Making this page editable with one click. Just watch me. So yeah, you can define your call to action. So this is nice, like with paragraph types, like paragraphs are gonna be like this kind of entity. We can add all kinds of fields. It's gonna be great. We can set this up in no time. But then yeah, it turns out that not every call to action is a background image, text, link, title. Like not all of the content on this page follows that pattern. So we've gotta start talking about multiple types. You've got like a video call to action, a file where you can upload some kind of document or something, then just a text version. So ideally we'll have multiple paragraph types. And the nice thing about paragraphs, I think the reason everyone's like, yeah, I use paragraphs. It's because with paragraphs, unlike with something like field collections back in Drupal 7, we can only really reference one type. So here we can leave it up to our, hey, I can move over here. We can leave it up to our editors if they're creating a video or some other kind of call to action. Since ruining my presentation, I can't keep the future slides a secret from you. Okay, so there are some alternatives, field collection. How many of you are excited about using field collection in Drupal 8? Yeah, hands down. There's also entity reference fields, right? You could just create a new entity type for your calls or a new content type for your calls to action and reference it and use the inline entity form. And this is kind of nice because then your calls to action could be reusable. So that's another kind of requirement you might have. Editors who want to grab this call to action over here and use it on another landing page. So that's something to figure out before you start building these things out. Okay, one time use landing page. So we've got kind of our reusable landing pages, but it might turn out that the landing page you're building, there's just one of them. You're not gonna make it content type if there's only one thing, right? So you get thrown a design like this and to be honest, it's not a very long homepage. If you keep scrolling down, there's more. You could keep scrolling and scrolling. How many of you have built landing pages like this? Home page that goes on forever? Yeah, we can do it in Drupal. Okay, so you have your requirements. You're talking to your designer and they say, okay, we have this really distinctive landing page. It's probably the homepage. Maybe it's some fancy marketing page, but it's something that's, there's only gonna be one of them. They assure you, they promise. It's only one of these. And of course, there's gonna be content from this landing page that you're gonna use elsewhere. Like clearly, if you're writing this much content somewhere, it's probably gonna show up elsewhere on your site because the marketing teams spent days coming up with this material. So some of the content on this page, it's gonna be aggregated from other parts of the site. Like it's not all just on the homepage. And you might also have to move sections around. So hopefully you're not moving things around every day on the homepage, but marketing wants it to be, wants to leave their options open. So planning this out, this is really where you could probably build this a hundred different ways. But let's say that we wanna be able to reuse these calls to action all over the place on our site. So maybe we build these calls to action here as a custom block type. How many of you use custom block types in Drupal 8? Yeah, fun, okay. And then of course, there's gonna be some views too. Because we haven't done anything with views yet. We've gotta use all the tools. So it calls to action view. Why might you build that? So the nice thing about building a view is that you don't have to edit it. You don't have to curate this list. It's something that's gonna be automatically pulled in. You create new stuff and it appears in your view. So if you can curate something as a view, all the better. If your requirements are gonna allow that. So this example of a view, this is gonna be like a list of featured pages on the site. The ordering, the selection, it's predefined. So in your view, you've got some filters that are deciding what's gonna show up. And then the content in this view, you're linking off to these maybe these other landing pages or these featured pages, these audience specific pages on your site. The content for each one of these is just being pulled from that page. So if you're linking off to this page for developers, the page for developers is defining like some call to action text as part of that piece of content. So this seems great to us. We're like, yeah, we build this view and we're done. We don't have any more work to do. We don't have to create this extra kind of paragraph type. And so of course, like a less complex solution seems a lot better. The one downside to building this as a view and just pulling in the content from those other pages is that you lose that one click effect. So that magic thing where the client says, oh, I wanna change some text on this page and you just click edit and they can change everything. That's kind of gone, right? Cause if somebody wants to change this for developers text, they've gotta go over to the for developers page and they've gotta edit that and they've gotta scroll down to the bottom where you've hidden the call to action field in this collapsed section and they have to figure out that that's where they edit the text that's gonna go on their homepage. So pros and cons of different approaches. In terms of call to action blocks, so this is another way of implementing your call to action. You can have a custom block type where you have fields for your different components. So maybe you have your links, you have your title, you've got a background image, you've got a text and you define this as a type. So it's easy to create lots of them and reuse them on your site. And we all love blocks, right? Everyone loves the new blocks you add in Drupal 8. Woo, so much better. You guys don't seem that excited. We're all like, already used to Drupal 8, like, oh yeah, it's been this way forever. We've always had that place block link. So blocks are great because they're reusable, they're fieldable, you can move them around and they're in core, so you don't have any modules. You can be like, yeah, we're building this totally from core. But there are some downsides, right? If you've got your Drupal site set up today and this is your solution where you've got all these blocks on the homepage and your editor says, yeah, but I wanna be able to move this thing up here because sometimes this is more important than this. And you've gotta tell them, yeah, you have to go over to this block layout page and you've gotta, but you can drag and drop, it's really cool, but you've gotta go over there and then if you wanna edit something, you've gotta go to the blocks UI and you've gotta find the block and you've gotta click edit and their eyes are glazing over and you can tell they're gonna be calling you in a week asking you how to do this again. But for those of you who have been paying attention, there's some new blocks, some new features for blocks coming up in Drupal core. So have you guys heard of the settings tray and the place block module? Yeah, everyone's shaking their heads. You guys have been doing your homework. Awesome. So yeah, with these modules, it's gonna be a lot easier for us to place blocks, a lot easier for editors to place blocks. They're gonna have an interface that's kind of built into a page where they can move things around, where they can edit content. So they don't have to go off to this other obscure section of the site to move these things around. So that's kind of nice. And then in terms of block visibility, we might have all been waiting for context to be ready to use in Drupal 8 so that we could have something like a homepage context or a campaign landing page context. But there's also this module, is Ted here? Ted Bowman wrote this module, block visibility groups. So you don't need to wait for context if you want to, if you want control over your block visibility, you can use this thing. And it's, you know, you could have something for your fancy landing page here where you're just controlling the visibility of those landing page blocks. So again, that's just gonna make it a little bit easier to go with this blocks option and to be able to define easily where these things, in a single interface, where the blocks are positioned on the homepage to easily edit what the blocks are. So if you're using these three modules, then the block solution becomes a lot more attractive. Okay, creating landing pages with a flexible layout. This is where I start to cringe like, flexible layout, that doesn't sound fun. Who here loves groups.drupal.org? Woo-hoo, one guy. How many of you have ever tried to edit one of these groups' landing pages? Yeah, I made this one back in the day, this was my best work. Three column layout, who knew? Yeah, so groups.drupal.org, every group gets to have their own layout, which is kind of fun, but you know, a little bit, a little bit ridiculous. Like you're coming to groups.drupal.org for the first time and you're like, why are all the pages different? Like what's going on? But this is a common requirement, right? Like you get, you read RFPs, you look at requirements documents, and it's like, yeah, you need to be able to easily change the layout of a landing page to anything. We have these 20 different possible layouts that we might wanna implement on any given day at the drop of a hat for our homepage. This is like features. So yeah, requirements. You might have a series of landing pages on your site where the editor actually wants to be able to change whether it's the one column or two column layout. And they wanna be able to move the content around in those layouts. So it's not enough to just have like a template that's always gonna have the same kind of look. You actually have to have these options set up as part of the editing interface. So you want the one click edit, but along with being able to edit the content, you also wanna be able to edit the layout. So panels, yeah, we finally got to panels. Who here's used panels so far in Drupal 8? Yeah, is it good, thumbs up? This is like the old Facebook, like we only have thumbs up, no thumbs down. Yeah, panels. So why would you use panels? So panels is great, because it has this one click thing. You click edit, maybe it's like a standalone panel, maybe you've got like some panelizer thing going on. You click edit and you can edit the content and you can edit the layout. Or you can use the in place editor and then you've got like edit layout, edit content and it's very user friendly. It's got this drag and drop thing and some people just love it. Like you're gonna add panels and they're gonna be like done. I'm like super impressed with your Drupal skills. So sometimes this is really, really the best option for clients. They really need that flexibility of layout and they want something that feels really, really like they're in control. But sometimes we don't want the marketing team to be in control, right? Like we're the site builders, we wanna be in control and we don't want the thing to look different every day. We want it to be a little bit more streamlined and we don't wanna add panels because to be honest, we're scared of panels. Like we get these nightmares, like what's panels gonna do? It's this big module and so we'd rather have like another alternative. Like we're always looking for more ways to do things. So if you have this requirement, flexible layout, flexible content, one thing to consider is maybe using nested paragraphs. So we talked about paragraphs earlier where you have this paragraph type for your calls to action. Maybe you have a bunch of different types. But you can actually put paragraphs inside of paragraphs. Who here's done it? Yeah, it feels cool, right? It's like, I'm gonna try it and see if it breaks and then it doesn't break and you're so impressed. So this is an example of putting a paragraph inside of paragraphs. So we have a paragraph type, well we have a paragraph field for layout and there's two types that we can reference. One column layout or a two column layout. And of course you might have a ton of other options but simple examples. So one column layout, two column layout and then you wanna be able to add different calls to action maybe to the different parts of the layout. So within these paragraph types, if it's a one column layout, maybe you just have one calls to action field where you can reference calls to action. If you have a two column layout, maybe you wanna have the separate fields for column one and column two. And so the editor can move the calls to action around and add them to the different parts of the layout. So just with paragraphs, which is a module maybe we're using anyway, we can create this flexible layout. And as long as we are pretty confident themers, we can take all these nested paragraphs and display them in a way that's going to make sense. So like a very simple example, we have a two column layout, the calls to action are incredibly lame, test column one and test column two. And so these are our fields. So we have the layout field and then within that we have the two columns, which are separate fields. So pretty easy to build out and pretty flexible. This interface might seem a little foreign. It might be a little like something that you have to explain, but to be honest, when you're using panels, you also have some training, some explanation you normally have to do. So I don't think it's too bad in terms of UI. You have the one click edit. So that's like the main thing that you're often going for. It's easy to switch the layout. You can really control the layout types and you can control which types of calls to action can go where. So you can actually say, well, in this field I'm only gonna put these types of calls to action in this other column. You can put this other stuff. So you can have more control, which I guess I'm kind of like a site builder who likes to control everything. Every field is required, always. Okay, so you build all these great nested paragraphs, custom blocks, you have your views maybe to put something calls to action in this nice little grid. And you've done all your configuration and you think it looks great, but there's no like layout actually going on. So we talked kind of about the landing page stuff, but to actually get all of this themed into a layout, like this is a bunch of work. Like this is maybe why you wanna use panels because then maybe you can just call it done and say, okay, panels took care of the layout. But no, that would be too simple. So theming, where we actually get to theming. So the overall layout. So you're theming your Drupal site and you're doing the fun part. And the fun part is what? Like you get your new, you get your design, you're implementing this landing page. And what do we all start with? Do you all start with like the header and the footer when you're theming? You're like, yeah, I'm gonna do the easy parts first. Those are always the same header, footer. So Drupal 8 is great because everything's a block, right? So your layout should really be defined by the regions in your theme. And that seems kind of obvious, but that wasn't the case in Drupal 7, right? Like Drupal 7, you had your regions, but then you had these breadcrumbs going on and the logo and the site title. So like your theme has to take care of positioning all these things. Drupal 8, no longer, right? We have, we can create regions where we know that everything is gonna be placed in the regions and that's it. So you wanna make sure that your regions really do allow for blocks to be placed in them and placed in the correct spot. So ideally, when you add a new block to your header or your footer, you don't have to like change anything in your theme to get the layout to work. Maybe if it's a menu, you've got a style in the menu, but it should be positioned at least in the right part of the page. So this is a nice way to start off with your theme. So everything's a block, everything's going in your regions and you don't have to write CSS for particular blocks to make the layout work. So that's kind of the goal, right? Is to make a theme that's like actually a theme that's gonna allow for you to place content wherever. So layout works all well and good when you have like standard things like headers and footers, but we've been just talking about creating all these different landing pages, all of which have different layouts that you have to implement. Some of them have views that have to have a certain layout. Sometimes we have panels, sometimes we're using paragraphs. So it's not just enough to have like regions that go into a layout because we've written the right CSS. Like that's kind of like day one of building your theme. And then from there, you have to figure out like, well, how's everything else gonna fit into this layout? Like how is everything else gonna go in the right place? And we might end up with a site that has lots of different components that are making up the layout. It's not just the regions. We have things within our regions that need to have a layout as well. So there's kind of two approaches to theming, right? I mean, I don't think I made this up. I think this is like a thing, right? We have either the type of theming where you start off with some kind of framework. Maybe you wrote it, like maybe it's a grid system that you use for all your projects. Or maybe you're using something like Bootstrap. Who here uses Bootstrap? Or something, who here uses something like Bootstrap? Like one of those other frameworks. Yeah, so that's what lots of people use. So you start off day one, you've already got all this CSS. So your job is a themeer, like in terms of layout. A lot of it is just to update the markup of your site to make sure that the layout actually gets applied. The other approach, which I think tons of people use but maybe they're like, oh, I didn't know this was an approach. It's when you have to update the CSS. So every time you add a new component, like you add a new kind of panel layout or you add a new view that's supposed to be in a grid or you add these paragraphs and then you've got to get them displaying maybe side by side. Every time you do that, you've got to update the CSS. And maybe you're using a framework that works that way. That kind of comes with the CSS, but you have to update the CSS to select the components that you're styling. Or maybe you've created a theme from scratch and you're just using the default Drupal classes and putting those into your CSS file and writing the CSS that way. So if you're using this first approach, updating the markup, then how are you gonna theme this? So let's say you've got a two-column landing page, easiest thing. Your CSS already exists, right? There's already CSS for sure. I'm guaranteed in your grid system or your whatever framework you're using to theme a two-column grid. So either you're using some kind of framework or you've got the custom CSS that you've written and the class that you wanna add to those columns, it already exists. And so your job is a themeer at this point in terms of applying the layout, it's gonna be to go in and update the markup. So you're gonna figure out, you're gonna inspect this page and you're gonna use your twig debug, right? Cause you've got twig debug turned on and you're gonna figure out, well, what's the markup around here that I need to edit? Which template do I need to edit to add the right class? Keynote just loves this slide. Everything is a block, yeah. We've got that. Okay, so your job is to add classes. This is your, you tell everyone you're a themeer, but really secretly just, you just sit around adding classes to things. It's a good job if you can get it. Three-column view. Three-column view. So maybe you have a view, this is from, hey, this is from the Drupal.r.com page. Have you guys all read these case studies? Should go read them. Three-column view. So maybe you have a view and in the design it's supposed to look like this. So the CSS, of course, it already exists. And so what do we have to do? Well, sometimes to edit the markup right, we've gotta go into the configuration. We've gotta update our view settings. This is nice grid. There's a grid in Drupal 8, did you know? It doesn't use tables. It actually uses divs, semantic markup, nice. So if you have this approach, you're gonna spend a lot of time updating templates, adding classes through configuration, so you might be using something like the block class module, or maybe even in your content, if you're really desperate, you're gonna add some classes in there to apply your layout. Updating the CSS, so this would be the other approach. You've got something like a two-column layout. So you're actually going to go and figure out what classes you can use to select these elements to write your CSS. For a three-column view, same kind of thing. You're going to go, I think this is actually the CSS from Drupal.org, so you go in and you figure out, okay, this is this kind of view, it's the views row, we just add the CSS and we're done. So you could end up with a lot of little snippets of CSS, if you take this approach. So some of you might be thinking, oh, this approach of adding CSS, every time you wanna implement a new layout, this is not the way, definitely the way is to use a framework, but I think it all comes down to how you organize your CSS, and how you organize your theme. So your real goal as a themeer is you know that these layouts are gonna come along, you know that you have landing pages and you're gonna have three column components and two column components and someone's gonna come along next week and ask you to add something else. So you just need to be organized. So ideally, and this seems like a dream, right? Ideally you'd plan in advance at the beginning of your project, you're starting out with your theme, you wanna plan what layouts you're gonna actually support. So ideally the marketing team wouldn't be coming to you every week and asking you for a new layout, you'd actually have some kind of grid system, some kind of plan for your layouts where everything has to fit into one of a number of options. It's also really important to limit the variability of what you're seeming, so whether it's in terms of the layout or just in terms of the branding or styling for these components, even though you are all capable of seeming anything like anything, it's better to have patterns. So I mean I'm sure some of you have gone to presentations this week on stuff like Pattern Lab or there've been presentations about that, right? Yeah, you're like the themeers, you've been going to these presentations all week. So even if you're not using some new thing like organizing your theme using components, you can still say no if somebody comes to you and says I wanna create 20 different stylings for calls to action or 30 different stylings or an unlimited number. You wanna limit the variability in your site because it's gonna make your site more maintainable both in terms of a content editing point of view and in terms of a theming point of view. So if you only have five different types of calls to action, then the editor on your site can create one of those calls to action and it'll be themed correctly. Whereas if there's too many variations, they're not gonna be able to control it through the configuration of the site, they'll probably have to go into the theme to apply new styling. So it's actually a benefit to everyone to limit the variability of your theme. You wanna have layout CSS that's generic enough to be used for different components. So when I was saying, oh, if you're writing a CSS every time a new layout comes along, you can just put the CSS in your theme. But if you have many layouts that follow the same pattern, you don't wanna have to rewrite the CSS every time. So you wanna make sure that whatever CSS you have is generic enough to allow for theming of views, theming of paragraphs, theming of panels so that you don't have to modify all of those if your layout changes. Let's say in a few years we kind of change how we do theming. You don't wanna have to rewrite all of your CSS. You wanna have one place to go to modify how your site handles a two-column layout. You wanna keep your layout CSS files separate. So of course if you're using a framework, this is already gonna be the case because it's gonna come with those layout CSS files. But if you're writing your own grid system, make sure you keep the layout separate from things like branding or styling. And you wanna document your layout. So if some new site builder comes along and they add some blocks to a region and all of those blocks now have a layout, they should have already known that. So you should have some documentation if your theme's applying layout to new elements automatically. If there's classes that people need to add to apply your layout, you should have that documented too. And even if you're using something like Bootstrap and you're like, oh, Bootstrap already has documentation, it's not quite enough, right? You need to kind of define like these are the layouts that this theme supports and you can't just do any old thing. So that's all I have. For you, I think that's about 45 minutes. So if you have questions, there'll be time for questions, but make sure if you're around tomorrow, there are all the contribution sprints. So you should stick around, come back here, it's gonna be fun. And you should also take like 30 seconds to review all the sessions you've been to this week, not just this one. So you can do that on the Drupal.com Dublin website. Thank you. Questions, comments, opinions, things I miss. There must be other things that, other ways to do things. Yeah, if you could come up to the mic. Yeah, have you heard of a classy paragraphs, the module, Contrib module? Yeah, I have, I haven't used it yet. So what does that do? So it allows you to create like a select list of classes that you can then add to paragraphs, which is how I do layouts. So you can kind of then define whether it's like a left-hand media class or a right-hand media class, and then define the theming like that. So it's just like another way. It's just like I didn't know people had heard of that, but it's really cool. Right, yeah. So you don't have to do this. Uh... Can you know when? You can style up the classes really generically. You know, so you get that, yeah. You can do things really generically and then just allow the whoever's putting the content in to kind of have the control over where stuff sits. Great, yeah. But keep control. So kind of like block classes, but for paragraphs. Yeah, cool. We should all try it. Hi, so full disclosure. I'm a maintainer of panels. How can we get a release? So two quick things. As a maintainer of panels, I can't imagine something scarier than nested paragraphs. And B, have you attempted to migrate that yet? No, oh. Because it's atrocious and I keep hearing how no one's succeeding. So like while it might be nice from like a UI perspective, nesting paragraphs like that actually kind of introduces a really difficult like data model into your system. And while it might be really nice for Drupal 8, you know, I'd encourage you to think about Drupal 9 because migrating that stuff, like. Right. If you wanna do that, then you should also be saying, well, we need to invest some time in figuring out how to do the migration for this as well. Okay, yeah. So that's like my, I'm encouraging people not to use it for that reason at the moment. But if we fix the migration issue, it might become much less of a problem. Right, so maybe if you have like 10 landing pages on your site, it's fine. But if you're gonna build out 200 of these things, you should think twice. Or one really long one. Thank you. How do you deal with the variation, small variations? For example, the client gets, that comes with just a change on the wording, a small wording on a title. Do you clone the note and create a different page just for a single word or do we have a strategy for that? If you have two landing pages and there's only a change in the title, sorry, I didn't, I guess so. Although I don't, I think I would like try and push back on that to two landing pages that are almost identical. It seems like maybe your search engine optimization would be a bit off with that. Yeah. I'm Jacob. I'm also a panel's maintainer. Oh wait, we have to clap. And I just wanted to say thank you for this. Also wanted to mention a panelizer. Which I'm not a maintainer of, but one of the things that's coming up in Drupal 8.3 is the new blocks and layouts initiative. A lot of the concepts from panels and panelizer are going into that as well as display suite. We sort of all, like there's a bunch of different modules that do a lot of different things and may seem scary, but a lot of the concepts are actually very similar. And our hope is to make that look a lot less scary as we get into 8.3. As well as panels now is a very small module. Unfortunately, there's all these other modules that you need in order for it to work, like page manager or panelizer. Right. So the last thing I would offer up to anyone here, we are doing a sprint tomorrow for panels and C-tools suite. So if people are interested, we are doing, we definitely need people to test stuff. And there is a release out. So if you're using Lightning or if you're using any of the Drupal 8 stuff right now and having issues and you're like, hey, why do I need to do six patches to do this? Please come and we will help you work on that. Awesome. Thanks. Thank you. I wanted to address the guy who asked about just changing. Oh yeah. Well, yeah, panels can do it. But to that point, like panelizer, which is kind of like, it can do bundle level overrides so that you have defaults of layouts for that. It can also do like entity specific overrides like OG on groups.drupal.org. But in Drupal 8, it also has really great revisioning tie-ins so that you can actually revise a node and the layout associated with it over time with a client. And we have a couple patches that are kind of in the wings right now that also tie content blocks revisions to the node revision so that you can make revision level changes and actually like pick a specific revision to pin at display. So if you needed to change text over time on just a specific content block, you could do that. It's not really where you could play with it today, but the patches are out there. So if you're interested, ping me and I'll show you. Nice. Hi. I am not a panel maintainer. But I had a... Just a quick question you were talking about. When using a framework, it's pretty easy to just add classes to your markup and then you're pretty much done with the layout. But I was wondering how is that much different from just changing the CSS, which I assume you just use different mix-ins or other includes or extends from your CSS classes. So how is it different from having to change the markup to changing the CSS? Yeah. So it's just a different approach, right? If you have pre-existing CSS that handles all sorts of layouts, you're starting off with a big chunk of CSS. And so your work, like I mentioned, it's more in terms of changing the markup. And that might seem easy. I guess it's easier now than it used to be, but I think for a lot of people, changing the CSS makes more sense. And some frameworks do work by providing a set of mix-ins that you can apply to your CSS just by adding selectors and then including the mix-in. So actually, I kind of prefer the second approach myself, but I think there's good reasons to do it both ways. Yeah. Anything else? Well, thanks so much for coming and enjoy the rest of your DrupalCon. Thank you.