 Great, so thanks for coming today. I'm going to be talking about creating landing pages and layouts for Drupal 8. So hopefully you're all in the right spot. This seems like a very popular topic. I guess everyone here has to create landing pages and layouts in Drupal 8. Am I right? Oh, I don't have any music. There's music next to us. I should compete. OK, so my name's Suzanne Degacheva. I work as a Drupal trainer and wearer of many hats at Evolving Web. I co-founded the company in Montreal back in 2007, and we do Drupal projects. And my handle on Twitter is Suzanne underscore Kennedy. If you want to follow me, at Evolving Web we do lots of kinds of Drupal projects and work with lots of different types of clients. And I also run a training program. So if you're interested in learning more about Drupal 8 and how to do theming and how to build those modules, I have some info up here so you can come and ask me after. So in terms of what we're going to do today, I'm going to talk a little bit about planning landing pages for Drupal 8. And I'm going to start off with some site building techniques. So I'm going to run through a few use cases. I'm going to talk about different modules. You can use different approaches you can take, benefits, and some drawbacks. And then I'll lead into some theming approaches. So it's going to be a bit of site building, a bit of theming. And I'll also throw in some best practices at the end so no matter which approach you decide to take, you kind of have a checklist for how to make sure your layouts are going to work into the future. So before I start, there's so many of you here. I think we should go around the room and I should ask you all to say your name. So just a quick raise of hands. So how many of you are Drupal site builders? Wow, OK. So how many of you aren't Drupal site builders? I think you're all site builders, right? Everyone here has created a content type, made a block. Everyone's a site builder. How many of you are Themers? How many of you write CSS? How many of you love writing CSS? Oh, awesome. Great. OK. You're going to like this. So to start off with planning your landing pages. So what is a landing page? A landing page can be many, many different things. In Drupal, we like to use content types, right? So we have standard types of content that we define. We do a content strategy process. We come up with the five top content types on our site and we build them out with our fields and it's all great. And then the designer starts working with us and they start throwing in these pages like the home page and a campaign page and some other section landing page. And they don't fall into these nice little content type designs. It's sometimes a little more tricky to figure out how to build these pages in Drupal. And there tends to be lots of different options for how to do it. So landing pages tend to be pages that target a particular audience. They tend to have a lot of marketing content. We have calls to action. Everyone love the call to action. Yeah, you're planning your website and the marketing teams like we have three calls to action or more likely we have 10 calls to action. And we want them all on the home page in five different ways. So this is what you get with your landing pages. They usually have more of a distinct layout or set of content from your other pages. And they tend to be trying to get users to do specific things, funnel them towards registration, login, search, some other action they're going to take on your website. So you're the site builder or you're the themeer and you're getting introduced to the project and you see that there's going to be pages like this. And maybe you see a wireframe first off the bat or maybe it's a mockup that's already all built out. It's the first time you're hearing about a project and it's already a mockup. Or maybe you're already prototyping something in HTML at this point. And there's some questions that you need to ask. So as soon as you know there's going to be landing pages there's a whole bunch of questions to ask. Probably at minimum you need to ask these questions. So what are you going to be actually building? Are you going to be creating lots of landing pages like this? So this is something I think that often gets kind of brushed over in the planning phase. Like you've got a couple of these section landing pages, maybe the home page. But then you don't really know are there going to be 10 more of these? Are there going to be two more? Are they going to be all different? Is content going to be curated by humans? Or is it going to be aggregated by Drupal? So if you look at a page, even like this Drupal.org front page, does someone actually come and select exactly which showcases to display? Or if there's a new Drupal con coming up does somebody have to go in and edit this content? Pretty sure they do. But these are questions to ask. Do the calls to action need to be reusable? So all these components you're throwing on this page, all these calls to action, or these images that are being displayed, are they going to be used on other pages throughout the site? Or is it just this one landing page? Is the content going to be moved around? So sometimes people just assume, oh yeah, that's like there's a bunch of things on the page. Surely the marketing director can just come and move them around at will. Well, that's a good question to ask. And then do you need to be able to change the layout really easily? So sometimes you'll have one of these landing pages, and there'll be three columns or two columns. And maybe you need to be able to change that on the fly, depending on what kind of content you have. So all good things to ask right off the bat. So depending on the answers that you get, you might end up with three kind of use cases for your landing pages. So write these down. No, there might be more use cases than this. This is just all I have time to talk about today, I think. So to start off with, reusable landing pages that have kind of a consistent layout. So things that you can, if you're thinking in general terms, things that you could build one template for, and it would just work. So this could be the case if your site has to create a lot of landing pages for different audiences, or if you just are able to really well define what the pages need to look like in advance. One-time use landing pages. So this would be more like for the home page, or for one-off campaign pages that are really specific. Landing pages with a flexible layout. So who here has had to do this? You see this in a, who here has seen this in an RFP, or in some kind of brief for a project. Flexible landing pages. Who here has actually successfully descoped this? Landing pages with a flexible layout. We need to be able to move things around at will. Could be any layout we want. So we'll talk about that use case at the end. Reusable landing pages. So this is my favorite, because I like control. I'm kind of a, I don't know, control freak in all parts of life. But in Drupal, you know I want to have control over the content going into the system, and I wanna have control over how it comes out. So when I see things that look kind of like a pattern, I get excited. So here's an example of some pages on a website I built. And when I first got the mock-ups for these pages, there were way more variations in the kinds of content that were displayed. So when I look at these pages, I see two kind of landing pages, and they have these blocks of marketing content. And when I, like I said, when I first got them, each one was a unique creature. Each one was like a special unicorn, and it had different, you know, a different background image, different text styling, right aligned, left aligned, every variability under the sun. And I said, you know, no, this isn't gonna work. Like we could obviously build this, but the minute you wanna add a new bit of marketing text or update or change one of the images or add a new page, like you're gonna have to start from scratch. So let's build this out so we have these reusable chunks. So in the design phase, you wanna identify patterns in landing pages. So if you're gonna have to build out 10 landing pages on the site and who knows how more in the future, you wanna make sure that there's patterns to follow. So the requirements for this, for these pages, we had to create multiple landing pages. They had to have consistent styling because marketing people had to be able to add new ones. The content had to be easy to edit and the calls to action had to be able to link anywhere. So internal links, external links, it wasn't like consistent places that were being linked to. And there were many different types of calls to action. So these blocks of marketing text, some of them had links off to another website. Some of them were download links. Sometimes there were videos. So there were many different types of fields that we wanted to be able to display. And the calls to action had different styles as well. So for each marketing block that we were adding, there had to be some variability, although we limited it in the scoping. So you had to be able to have, for example, light text on a dark background or dark text on a light background, centered text, left aligned, right aligned. So there were a few variables there that we wanted to track for each block of marketing text. So how did we build this? So to me, when I look at several pages that have some kind of pattern to them, I'm looking at building a content type. So even though it's kind of a landing page and it's got this unique marketing text, I still wanna build this as a content type. So there were some things that were very consistent, like the banner image. Each one has a banner image. Each one has a title, a prefix. So those things, we can easily build those fields. And then there are these more variable things below, these components that could change. So how can you build these? There's lots of options in Drupal. You might be thinking blocks. You might be thinking fields. You might be thinking, I don't know how to do this. Or you might be thinking panels or something like that. So there's many, many options. Another example of a use case like this. So many landing pages on a website. We have a banner image. We have the title and then we have components underneath that obviously can look quite different. Kind of images or text can be interchangeable. So my go-to way to do this right now, if I was to get these mockups today, I would go with paragraphs. Who here has used paragraphs before? Oh, a lot of you, awesome. Okay, so paragraphs, we can build out unique chunks of content, right? So a paragraph for those of you who didn't raise your hand, a paragraph is a type of entity. It's not a node. It's not a block. It's kind of somewhere in between. It has fields on it. So you can see here I have these paragraph calls to action and each of them has a title, an image, text, and a link. So we can build these as fields in Drupal and it looks pretty much like building out a content type. So you've all built a content type, it seems. So you're probably familiar with this kind of interface and you can build the same thing with a paragraph. But a paragraph we can attach as a field to another node in Drupal or to a block or any kind of entity. So if I have my paragraph, sorry, if I have my landing page content type, I can add this paragraphs field that links to all these calls to action. So each component in my landing page, I'm gonna build out as a paragraph and each one I can edit in the page and add my fields to. And the really nice thing about doing this with paragraphs is that you get one edit link. So I said in my requirements that the editing experience had to be straightforward and that there were marketing people who were gonna be updating this text on a regular basis. So the nice thing about doing this with paragraphs is you get one link to edit the page and within that node edit page, you get these separate forms for editing each component, each call to action. So that's all well and good. We've got calls to action here. We've got some fields we can attach. But if I look a little bit more carefully at the, the mockups I got, sometimes my calls to action have links, sometimes they have download links and sometimes they have videos. So there's some different types of calls to action that I actually see in these kinds of landing pages. And so another really nice thing about paragraphs is that you can set up different paragraph types. So you don't just have one thing on the site called a call to action. You have your field for that and that's it. You can build many different types of paragraphs and they can serve many different purposes. So if you've got a bunch of landing pages and you have different components that can be printed out like your video or your set of links or maybe even a slide show of images, you can create each one of those. You can define it in Drupal as a paragraph type. You can have control over what fields are required. You can have control over how they're displayed and you can move them around on the page. So you can build a lot of flexibility into your landing pages. So when you're setting up a paragraph field in Drupal, like any kind of entity reference field, you can pick what you're referencing. So you're gonna pick that you're referencing paragraphs and then you can also choose the types. So with paragraphs, one of the reasons people so enthusiastically put up their hands, yeah, I'm using paragraphs, is because with paragraphs you can reference multiple types. So it's a little bit like what you might have used with field collection, but super flexible. So you can reference calls to action, video calls to action and as many other things as you can dream up. So one downside with this approach is that like I said, you've got the edit link, the one edit link on your landing page where you're editing all these components. That page is gonna look, well it's gonna look like a regular node edit page, but it's gonna have this section in here for editing your calls to actions and adding new ones, which is all great. But the problem, or the downside with paragraphs is that the content is meant to be used within your node. So you're editing your landing page node, you're adding these calls to action, but then the calls to action aren't available to be used in other parts of your site. So one alternative approach, if you need reusable components, so if you need that video to be used on lots of other pages, an alternate approach is to use blocks. So how many of you have used blocks on your Drupal site? Oh yeah, yeah and blocks are in core, so that's great. One downside that you're all gonna be thinking of is with blocks you don't get that one edit link to edit the page and edit all your content in place. And so one thing you can add to just regular old custom blocks is using the inline entity form. So inline entity form is a module, it was around for Drupal 7, it's around in Drupal 8. How many of you have used that inline entity form? It's a good one, so write it down on your list of modules to try after Drupal Con. It allows you to edit those blocks or any other content that you're referencing right in place. So you're editing your landing page, you can add entity reference field to blocks, and then you can edit the blocks inside that page. Okay, so those are reusable landing pages. So use case number two, one-time use landing pages. How many of you have had to build some kind of a homepage that is completely different from any other page on the website? Not all of you? It's not as many hands as I expected. You're like, ah, the homepage, whatever. Leave that to someone else to take care of. Who needs a homepage? So the one-time use landing page, sometimes this is a little more tricky than the example I had before. And that's because often your homepage is going to display components that aggregate content from throughout the site. So you don't necessarily wanna build everything as paragraphs in your homepage because maybe you wanna have components that are reused, or you want it to be set up so that when you add news items, they automatically show up on the homepage. And so your homepage will probably end up being, well, depends on the homepage, of course, but it's likely to be a mixture of things that are curated, so things that content authors are explicitly putting on the homepage, and things that are aggregated automatically, so things like a view where as soon as you add an event, it shows up, it shows up here. So the requirements for my one-time use landing page, so I need to create a single distinct landing page, it's not gonna be copied a million times. Some of the content needs to be reused, so I can't use paragraphs for everything because any particular call to action, I might wanna use on another part of the site. Some of the content needs to actually be aggregated from throughout the site, so it's not gonna be placed there explicitly, and some of it needs to be reorderable, so maybe we'll wanna move the Drupalcon banner down to the bottom of the page at some point. For example, so how would we build this? So there's many, many ways to build this page, there is no one right answer, so here's just one suggestion. So for example, up at the top, we've got some kind of marketing banner, and this could be a custom block. So pretty sure you've all created custom blocks, but in Drupal 8, we've got this new lovely thing we can use called a block type. How many of you've created block types? Yeah, how many of you used beans in Drupal 7? Yeah, some people were really eager to get block types in Drupal 7, so there was this module that made it work, and it was kinda cool. But now we have it in core in Drupal 8. So custom block types, kinda like paragraphs, kinda like nodes, we can attach fields to blocks. So if you're sure that the banner image at the top of your homepage is gonna change in two weeks, rather than hard coding it in some HTML, you can add it as a field to a block type so someone can easily come in and edit that image. So that's pretty useful. We've got some things that are probably views because they're lists of content. Those need to be displayed automatically as content throughout the site changes, and then we've got some things that look more like standard call-to-action type blocks. So these are gonna be, again, custom blocks, but I can put fields on them to turn them into reusable blocks that are gonna be styled nicely depending on the content I add to the fields. So the views example. So this is a up-close snippet of my homepage design. And the three items here are featured pages. So as soon as a featured page gets added or as soon as it gets updated, this view is gonna be dynamically updated on the homepage, which is great. The downside of using a view like this is that the marketing team, or whoever is responsible for the homepage, they have to actually go to one of these pages, edit the page, and edit the fields that generate these calls to action. So if I have a set of call-to-action fields on a piece of content, and I can figure my view so that when one of those items is displayed, those fields are gonna be printed on the page. The downside is that you have to explain that to your marketing team and tell them, oh, if you wanna edit something on the homepage, you have to go over to this completely other part of the site to change it. Unless you've got really nice contextual links in place that are working. So that's one approach. So having views for your calls to action, if they need to be more like aggregation-like. Calls to action blocks, so like I said, block types with special fields that we can use, and the advantage of setting these up as custom blocks is that then we can reuse them on other pages. And the really nice thing about using block types is that block blocks and block types are in-core, so we don't have any modules to add. We don't have to download paragraphs. We don't have to worry about using contributed modules. We just use what's in-core. And blocks are reusable, they're fieldable, so like I said, you can add custom fields to them, and then they're movable, so you can move them around on the page. So the part where the marketing director might wanna move something to the bottom of the page next week, that's possible if you're using blocks. But the downside of blocks is that you have another part of the site, you don't just have one edit link on your landing page, you have this other part of the site, the blocks configuration page, that then you have to point your site admins to to go and edit the order of the blocks or go and place new blocks. Who here has had to explain blocks to like a marketing person? Yeah, super fun. Best part of my job. There are modules that can help us with this. So there's a couple modules that are in Drupal Core, they're experimental, so I'm not saying you should use them, but they exist, which is cool. So if you wanna try enabling on your site, settings tray and place block, so these are in-core, so you know, they're there, you can just turn them on. And they improve the usability of blocks. So the idea is that you can go to your homepage, you can go and place a block directly on the page, or you can go and edit a block right in place. So try these out, they do make blocks more user-friendly. Another module to consider, some of you have probably used Context before, if you were using Drupal 7, yeah, context users. Yeah, and then there's Context in Drupal 8, which I know there's a new-ish release for that I haven't tried yet, but Context does a lot of different things and has not quite been ready for Drupal 8 yet for sites I've built. So what I've been using instead is block visibility groups. So block visibility groups is a way of creating a set of blocks that appear on a certain type of page. So kinda like using Context, but just for the blocks part. So you have a type of page like your homepage, or like a certain content type, and you can control the block placement just for that kinda page. So great module, you can check it out, and that's gonna help you with your block management issues. Okay, so we've come to use case number three, landing pages with a flexible layout. So I love, like every time I bring this up in any kinda presentation, I always look for good examples of this, and I always come back to groups.drupal.org. Who here uses groups.drupal.org? Some of you probably organize events and stuff on this. No one's raising their hand. Oh my goodness. Everyone's like, it's all about meetup.com, Suzanne, like you are so out of date. Groups.drupal.org, if you check it out, it's like the community website for Drupal groups, like local groups, user groups of different types, and each group gets their own landing page because each group is unique. And so if you look, there's a lot of different types of group landing pages. You go to any given one, events are gonna be in a different place, some of them have two columns, some of them have three columns, and they're all beautiful, beautiful pages. I think I built the one on the left. My finest work. So requirements, so you're probably gonna get, at some point in your career, this is gonna show up in an RFP or you're gonna end up with this on your plate. Requirements for a site where you have to have flexible landing pages. So you have a whole series of landing pages and all of them could have different layouts, and the layout could change at any given time. So somebody might just come along on Monday and say, oh, we need to change from a two-column layout to a three-column layout and add some new content on the landing page. And you wanna be able to adjust the content in that selected layout really easily, so maybe move the content around. So you're probably all thinking panels, right? How many of you are panels fans? Yeah, I've been using panels since Drupal 6. I think my first Drupal Camp presentation was on panels, so definitely a big fan. And if you've tried panels for Drupal 8, it's changed a bit the interface, but the idea is the same. So the idea behind panels is that any page in Drupal and new pages that you create can have a custom layout and custom content that you place in that layout. And there's a whole bunch of other things that panels does that are really cool that let you use contextual data and all kinds of things, but at the core, if you're using panels for landing pages like this, you're probably doing it because you wanna have control of the layout of a certain page, or you wanna be able to take over control of the layout of a certain page. And along with panelizer, sorry, with panels, we have the panelizer module who's used panelizer. Awesome name for a module. Yeah, so panelizer lets you take nodes on your site, like specific nodes, and then override the layout of those nodes. So rather than just having to create a brand new custom page with a custom URL, you're actually just taking over an existing node and modifying the layout, modifying what content is displayed. And with panels, you have access to add fields and blocks that can combine different things together, which is one of the things that makes it so powerful. So why use panels? So panels also, just like with the paragraphs, landing page content type example I was showing earlier, with panels, you get this one-click editing experience. So you go to your landing page, you click edit, and you can move things around. You can change the layout all in one place. There's also an in-place editor for panels. The panel's in-place editor module, so it's an extra module you can enable, and it makes the user interface much more friendly. So from the front end, you can get this nice edit link and start moving things around. User-friendly drag and drop, so I think a lot of people love panels, like they see Drupal and they say, oh, this is so complicated, we've got blocks over here and content over here, and then you see panels, and you just get this nice interface where everything's in one spot. So panels is a great new, or sorry, not new, a great option for these flexible landing pages. The downside of panels, and one thing that kind of scares me because I'm a control freak, is that you can add a lot of things with panels, you can change a lot of things, and sometimes that makes me nervous. I'm worried that the person editing the homepage is gonna add something that doesn't work, or they're gonna change the layout and the layout hasn't been tested, and so I feel like with using panels, you probably need to do more planning and education to make it a success. And this comes to option two, so I'm gonna show three options for creating flexible landing pages, and this one is kind of a newer one that you might not have seen before, so how many of you have heard of this approach? Nested paragraphs, not too too many, okay, cool. So nested paragraphs, the idea, I mean, there's lots of ways you can use nested paragraphs, but to build a flexible layout, the idea is that you start off with one paragraph type that you're adding to your piece of content, and this determines the layout. So you're adding a paragraph and it's gonna be maybe a one column layout that you're adding, or a two column layout, or a three column layout, so this is gonna be one paragraph that you define, and there'll be a different type for each layout, so when you're going in and creating your paragraph types, you're actually gonna create a type for the one column layout, a type for the two column layout, and a type for the three column layout, and each of those can have different fields, because they're different bundles on the paragraph, so you can have, for example, for the two column layout, two fields, one that contains the content for column one, and one that contains the content for column two, and then for your three column layout, you do the same thing with three fields, and then inside those fields, you can define sub-paragraphs that actually contain your calls to action, so when you're looking at the UI, when you've actually set up all the site-building part of this, you'll go in and you'll see a link to add a one column layout or a two column layout paragraph, and then once you've done that, you'll see the form that lets you add your calls to action or your other content to each column, so the end result is gonna look, well, I hope it looks a little nicer than this, this is what it's gonna look like maybe before you do much theming to it, so it'll have your layout, and then it'll have your columns, which you can theme to actually be in your layout using CSS, so the advantage of nested paragraphs is that you get a one edit link for the page to edit your whole layout, it's easy to switch the layout, I mean, you'll have to go and pick to add a one column layout or a two column layout, and you could make any of these things multi-value, so you could have a one column layout, a two column layout, and then a one column layout again, so if you wanted to have multiple values for the layout paragraphs, that's gonna let you actually build a more interesting layout. You can control which kind of calls to action can go where, so rather than just letting the site builder or the site editor put any content into this landing page, they can actually, you can actually control that it's only maybe calls to action and videos that can go on this kind of page, and if you have a lot of nested layouts, you might notice that maybe the performance of your website doesn't do so well, or maybe the UI is really complicated, so with paragraphs, you do have some options in your managed form display settings to change how the paragraphs are rendered. So for example, here you can imagine if you had a nested paragraphs and you have a three column layout and then a one column layout and a three column layout and a two column layout, the note edit form is going to be massive and very confusing, so it's possible to display these things instead of forms, you can show just like a link to edit each one. So once you've set this up, you can try going into those managed form display settings and customizing that. Okay, so that's option two, nested paragraphs. So that's your homework. If you didn't raise your hand when you heard about nested paragraphs, if this is the first time you're hearing about it, you can go home and try that out. Option three is something that doesn't exist yet. So this is like the dream segment part of the presentation where we're going into the future. Who here has heard about the layouts initiative for Drupal? Yeah, awesome layouts initiative. So the idea of the layouts initiative is that there should be a system in Drupal for defining and using layouts for things. So things like if you've used display speed, if you've used panels, there's, these all provide configurable kind of ways of displaying layouts and then actually building the layouts in code. So the layouts API in core provides a way for defining and using layouts and allowing modules to discover these layouts. So there's actually a new experimental module in Drupal 8.3, which I just found out about, which provides field, it's called the field layouts module and it provides an interface for defining a layout for your fields when you go to the manage display tab. So if you've used display suite, this probably looks really familiar. Probably thinking this is just display suite. Well, actually this is in Drupal core, which is kind of awesome. So this is a new thing in Drupal core experimental and you can check out more information about how to actually create layouts that you can use here on Drupal.org. I put the note ID up there, so you can check this out later. But what's coming soon, so the dream part of this is that this nice way of managing what layouts or what layout is gonna be used for a certain kind of content. The idea is that maybe this should be available for specific nodes. So basically what we're saying is panelizer in core. How many of you think this is a good idea? How many of you have an opinion about this? Panelizer in core. Yeah, so this is something that maybe is gonna happen. So you can watch Tim Plunkett's presentation. He talked about this on Tuesday and come to the sprints tomorrow because he's gonna be working on it and you can make your voice heard of what you think or help out with it. So that's option number three for the future. Okay, so we've got all these landing pages we've been talking about and now I wanna talk about actually the theming part. So you've kind of built out your paragraph types, you've built out your panel or you've put in place some blocks, some custom blocks and now you actually want to put all this into a nice layout, like you wanna add your CSS. So how does this all work? So taking a step back, in Drupal 8, everything is displayed through a block. So in Drupal 8, unlike in Drupal 7 where some things were placed as blocks, some were just printed out in a template file, now everything is block-based. So mostly when you're planning the overall layout of your page, you're gonna be placing blocks in regions. So it's important to have the right regions in your theme and it's important to use those regions to create your overall layout. So typically that's where you'll wanna start rather than starting with the landing page kind of content, you'll wanna start with the overall layout of your entire site. So if you're looking at Drupal 8 blocks, you'll notice there's a lot of new blocks and like I said, everything is displayed as a block, so even things like the logo, breadcrumbs, it's all in blocks. And that means when you're planning the regions for your theme, you're going to be planning for everything to be taken into account using these regions. So if something's gonna be in the overall layout, it's gonna be placed into one of your regions. So your regions should reflect the overall layout of your page. So typically you'll start there and you'll make sure your regions are laid out appropriately. So in this screenshot, we've got this one big region called content and in content there's actually a layout, right? So here in my content, I've got some content on the left and some content on the right. So this is maybe the more interesting part. So we've got a nice layout for the overall header, footer, but then content could have a landing page in it. It could have paragraphs that are displayed or it could have custom blocks that need to go into columns. Or maybe there's a grid of like a view that's supposed to be displayed as a grid. So the question is, how do you create the layouts within your content? So that's what I'll be talking about next. So there are two theming approaches overall. I hope you can sort of figure out which one fits with your theming approach. So two theming approaches that I see. The theming approach, A, where you're updating the markup as you add new components to the site. So you start off with a whole bunch of CSS that you're gonna use for your site. And then as you add new components, you make sure that the classes that are defined in your CSS are applied to the new components you're adding. So for example, if you're using Bootstrap or Foundation or some kind of CSS framework, how many of you are using a CSS framework? Okay, so this applies to lots of you. If you're using a CSS framework, that means you're starting off with this great big set of CSS, maybe some JavaScript. And then as you're creating your theme, or sorry, as you're creating your Drupal site, you're applying the classes from that to the Drupal components. This might also apply to you if you create a theme from scratch, but you're defining all your CSS kind of in advance. So maybe it's sort of like you're building your own framework. You decide in advance, okay, we're gonna have something called a two-column layout, and this is the CSS for it. Here are the classes, and then you can go ahead and add those classes to the Drupal components. So typically, if this is your approach, you're gonna be updating the markup a lot as you're building your site, but you won't have to go in as much to the CSS and update the CSS. So the second approach is where you're working more with the CSS as you build your site. So you start off with maybe no CSS and you apply the CSS to your components. So you add a new, let's say you add a new panel's landing page and there's a two-column layout, and you just wanna add the CSS for those two columns. So you take the classes that panel sticks in there and you put them in your CSS file and you write the CSS. So that's kind of the second kind of approach. There are some frameworks that use this approach where you write CSS, or sorry, where you write typically SAS and you apply predefined mixins to the classes that come from Drupal. So for example, if you're using Zen grids, does anyone use Zen grids? Does Zen theme with Zen grids? Is that popular? Oh, wow, almost no one. Okay, it's kind of a cool approach. It's like provides mixins that you can use but you have to put in the classes that you want to apply them to. Okay, so I'm gonna start with approach number one, updating the markup. So if you're trying to build, let's say a two-column landing page, you already have the CSS in this approach. The CSS already exists for a two-column layout. If you're using something like Bootstrap or another framework, you're gonna look in the documentation maybe and you're gonna find, oh, there's something called callMD6 and that's what I'm going to apply to my layout. That's what I'm gonna apply to those columns. Or maybe it's some custom CSS that you've already written that creates this layout. And so your task, because the CSS already exists, it's easy, all you have to do is go in and add these classes to the markup. So for example, if you're using paragraphs, you can find the template files that are wrapped around these paragraph fields and you can put in those classes there. So either your custom class or the class that's coming from the framework. Okay, another example. So you're creating something like a three-column view and you're trying to get the three-column layout to apply to this view. So the CSS, again, already exists. So if you're using Bootstrap, you're gonna look up the documentation. You're gonna see, you're gonna use something like callMD4 to create this kind of layout. You want to apply that class or you can look it up in your own custom CSS and see what class you should use. And this is something you can put right into views configuration. You can decide what class should be used for each component in the grid. So Drupal 8 has views, has a grid display. How many of you have used the grid display in Drupal 7? Yeah, the grid display in Drupal 7 was a table which was not the best, not so semantic, not so good for responsive design. So now in Drupal 8, it actually creates nice divs and we can add classes to them. So it works really well. And there might be lots of other things that you want to create a layout for in Drupal, not for the overall site but within your content. So for example, for blocks, if you wanna put a bunch of blocks into columns in a layout, you can use the block class module to add a class to them to do that or you can add, you can use a hook to add custom block templates to your theme and you'll be able to go into each of those template files and put in the classes that you wanna use there. There's also, if you're using paragraphs and you happen to be using the Bootstrap framework, there is a module called paragraphs bootstrap. There was a talk about it earlier this week. So you can check that out and that's gonna help you get the right classes in place for Bootstrap using different kinds of example paragraphs, paragraph types. And finally, in your content. So it could be that in the footer of your page, you wanna have three columns so you need to stick your existing classes into those columns. So you can do that right in the WYSIWYG editor. And in Drupal 8, because we can configure our WYSIWYG editor, we can control what styles can be added through the editor. So you can actually put things in there that are then gonna get picked up when they're rendered. So approach number two, updating the CSS. So this is maybe more straightforward, but basically if you're starting out without CSS and you're writing it kind of as you go, you're going to be updating the CSS as you add new components. So when you go in and you're adding these calls to action in various columns, you'll actually write the CSS for this in your CSS file. Old school. For a three column view, could be the same thing. You add the CSS that uses classes that views is already providing and you put this into your CSS file. So the important thing if you take the second approach and you're updating the CSS is that you actually wanna be making sure that the CSS you're adding is still reusable. So just because you're adding the CSS as you go, it doesn't mean that every new component you add, you're gonna have to write more CSS. So if you put something into a three column layout and then you do it again, you can just go back and update the styles that you already created to select those new elements. So I think the reason people really love using frameworks that it kind of forces you to use the same CSS every time you're doing a layout, but there's no reason you can't do the same thing with this other approach of updating the CSS. So some overall best practices, just when you're working with creating these layouts in your theme in Drupal. First of all, you wanna plan out which layouts your theme will allow. So even if you're creating a site where you can have flexible layouts for each landing page, you still need some definition. You can't just allow anything. So you wanna plan out maybe with your designer or with your UX person or whoever it is you work with, plan out what layouts should be possible and limit the options that are available. So this is kind of the reason that the layouts API is cool because if you're using different modules that use layouts, they should all be using the same layouts. So you can put layouts into your theme and display suite will use them, panels will use them and the core field layouts module will use them too. You wanna make sure that your layout CSS, if you're writing your own layout CSS, you wanna make sure that it's separate and that it's reusable. So like I mentioned, make sure that your layout CSS isn't intermingled with branding CSS because that way you won't be able to reuse it. You wanna make sure it's really, it's in its own place in the theme. Nothing in your theme should be content specific. Who here has added node IDs to CSS files? I've done it. How many of you have done it? I don't believe you. No. Node IDs, this applies to block, you know, block IDs, any kind of IDs, anything that relies on your content that's in your theme is very fragile. So you wanna avoid that, find other ways of injecting reusable classes instead and you wanna add documentation. So documentation is something that gets pushed to the end of the project and never done and that's why things like using a style guide is important. There's a style guide module for Drupal that you can extend. So if you're theming new components, you can add those to the style guide so you have one page to go to. Style guide module, how many of you are using it? Whoa, style guide module is awesome, you should use it. So it allows you to see all the things on your site and how they're themed in one place. So it's very valuable and you can add new components to that. So you can see, for example, how call to action is themed. And then there's other things, other trends you'll see in front end development like pattern lab, KSS and all these things are kind of pushing you towards documentation, planning in advance, planning out how things are gonna look. Okay, so I've got a slide with all the modules that I talked about. So when you download the slides, you only have to look at this page, if that's all you want. Try them all out. These are the experimental modules. Experimental is in bold for a reason, experimental. I have some upcoming Drupal trainings that I wanted to mention. So I'll put this up if you wanna come out. And again, sprints are tomorrow in this room. So if you have opinions on layouts or usability, or if it's your first time at DrupalCon and you wanna come to a sprint, there will be stuff for you and you should be here. So I'll take questions now if anyone has questions. And I should say questions, opinions, comments, all welcome. That's good, man, good, good. Hi, jeez. You kind of mentioned display suite and passing and the layouts and core. Do you have any opinions on display suite, good, bad, or is it the layouts and core kind of gonna replace display suite? So display suite does a lot of other things. Layouts and core is much simpler. So if you're using all those other things, then I'm sure it's still a place for display suite in your workflow. Yeah. All right, thanks. So for the second approach you mentioned with the nested paragraphs approach, you mentioned creating a paragraph type for column-based layouts. But since you can't reuse those paragraphs, do you have to then create a left column or a one column paragraph type for each node? That's right, yeah. Yeah. Okay, thank you. That is a drawback, thank you for pointing that out. So I'm wondering is with the different layout approaches you listed, is there one or the other that creates more or maybe less theming overhead when it comes to writing CSS for them? Yeah, so for sure, if you're using a framework or you're just writing a bunch of CSS in advance, you might end up with CSS that's not used anywhere in your project. So this is always, that's just a reality of using a framework or using a bunch of CSS that's pre-written and so that's I guess a downside. On the positive side, if people are already familiar with the framework, they'll be familiar with the classes, it's easier to onboard people like that, make things consistent and could be much faster for your development workflow. So it really depends on your approach, both options are totally valid though. So like if you used a bunch of nested paragraphs, for example, versus just putting blocks and is one approach easier to theme than any of the others? It just maybe depends on what you're more comfortable with, like if you don't like the idea of editing a bunch of twig files, if you're writing the CSS yourself, you can just write CSS and use the classes that exist. But adding classes to twig files isn't that complicated, so if you don't mind adding a few template files to your theme and customizing the classes in there, it's not that much more work. It's just more files you have to deal with. Thank you. Hello, thanks for the excellent presentation. I have a quick question regarding having HTML in a template file, like a twig file. In Drupal 7, you were able to use the hook menu system to create a path to a page. And if, for example, you had to create a landing page that looks nothing like the rest of the pages, let's just say for a Halloween event or like a Christmas theme page. So what you used to be able to do in Drupal 7 is create the path to a new landing page and then you could use some hooks to display either the content of the page or to have the content on the page be written all in HTML in a file or if you wanted to, the whole HTML written on a file. So is that discourage in Drupal 8? Is that even possible? Oh, it's still possible. I mean, you can still create a path using the routing system and create a controller to print out some things there. You can put a custom template file in your module, but there's other approaches that don't require a custom code. So it, I mean, it depends on how, you know, what that output of that page needs to be. I'd say if it doesn't have to be programmatic, then I would use another approach. I would try and do that with just, you know, displaying entities on a page instead. Okay, so you usually found a way to avoid like having to manually code the route. Okay, got it. Thank you so much for- Thank you. You're welcome. Thank you for that great overview and setup. I like that you've displayed all the different options. And I think sometimes they're kind of unrepresented at some talks. I specifically like that you mentioned inline entity form. And on a related note, I just wanted to mention to everybody that we have a bof that's happening at noon today. And essentially we're gonna take paragraphs and inline entity form, build the exact same thing. And we're gonna do the pros and cons and have a discussion. Oh, that's so cool. Yeah. Okay, we should all go. Thanks. Hi, so basically if I have a region that I only wanna output if it has content in it, I was looking at ways of how to do this and there's like this really, really long Drupal issue about how to accomplish this. And all of the ways are kind of hacky. And so I was just wondering if I wanted to have like a basic page content type and allow users to decide if you want like a right sidebar or not, like they can make that decision about the page that they're creating, what would be the best way to handle that from one of the approaches that you've spoke about? So you're creating a new page and you wanna let them swap out one of the sidebars. Basically just. Depending on the setting, like they check a checkbox and decide what it's gonna be. That's how I have it working right now is basically there's just a field on the basic page content type that says add right sidebar and they can choose to either output that sidebar or not but I don't feel as if that's probably the best way of doing it. That seems like a good way to me. Okay. I'm sure there's five other ways to do it. Okay, I mean if that's an okay way then that's fine with me. Thank you. Great, thanks for that great talk. So I'm coming from Drupal 7 to Drupal 8 and my question has to do with say multiple pages like you have I think of content type of article and there are hundreds if not thousands of articles and allowing editors to come in and write content for that article. Maybe you have a sidebar but it's based on path like slash article. How would you approach that in Drupal 8? I don't, maybe I didn't understand the question. Can you? Oh sure, so you have just multiple types of the same page over and over like article and so this was about landing pages and possibly creating one off or but what if you have the base would you just do this as a content type? With the same fields all the time. So for that you can use the manage display settings for the content type to start with. If you have different ways you wanna format the fields you can add formatters and sometimes you might need to add a custom formatter if you wanna do something really special and then otherwise like you do have a template file you can add in your theme for each content type like node template file that you can customize and in there you can add extra markup. So if it's just customized markup that you need you can go in there and you can break up how the fields are displayed. So that would be a combination of those things. Okay cool thanks. Hey. Hey. I wanted to answer the guy's question from two ago. Okay. Which was that panelizer can do that cause you can set multiple defaults for a given content type and you can even expose that to the user so that as they're creating whatever the node type is they can select which of the defaults they wanna use. If you'd like to see how to set that up hit me up and I'll show you. But I also wanted to just cause it's new and you probably haven't seen it yet. The panels and Ctools folks we've been working on a new type of block that is essentially like the custom block. It mirrors everything the custom block does except it doesn't create new blocks in the user interface for placement. It just like one offs them and never shows up for placement again so it's like non-reusable content blocks. Very cool. Yeah which functionally is really really similar to like a paragraphs or something like that world but has a totally different storage mechanism which brings me to my next point. If you're gonna do nested paragraphs like buyer beware the content storage mechanism on that is like you can shoot yourself in the foot really quickly so use it sparingly. Great thank you. Last question I think. Okay thank you. One thing that has been a challenge in layouts since I was learning Drupal is the field system outputs all the fields in one content block and there are many times where I wanna I would like to just be able to like have three content blocks and put them in different regions just kind of for layout purposes and so there's a lot of different workarounds. What do you run into that or how do you handle that? So different fields that you wanna display in different blocks or? Yeah so the new field layout system kind of has almost like a sub region concept so the content area you can divide into regions but what if I wanna put some fields into just kind of like the title is a block and you can place it in a different region what if I would wanna like take three fields on my content type stick it in a I'll put them in a separate block and stick them in a different region in my block placement screen. If you want them in a totally different region you'd be looking more at using a view or something so you could use a view to create the to list the fields for the current block in a views block and then stick that in the sidebar. That's been my work around but it feels like a heavy thing to do just to basically output this field somewhere. Yeah I think you're right. I didn't know if you had any go to math. I'll think about it not off the top of my head but come ask me later. Thanks so much and if you're still in the room you must be really into this so I have stickers which I meant to mention earlier so come get some stickers. Thanks everyone.