 All right, I think we can go ahead and get started. Thanks everybody for coming. This is a layout building in Drupal. My name is James Netic. I'm a front-end developer about 11 years now. Six of those I've spent with Atten Design Group. Atten is a full-service digital agency. We provide award-winning user engagement strategies. We build responsive websites and accessible websites. We work with the open-source community primarily in Drupal but also in WordPress React and Gatsby. We are founded to serve mission-driven organizations. And for the last 20 years, we've worked with some of the most amazing mission-driven organizations in the world. What we like to say is that we seek to do work that matters. So I do have the chat visible. So if you have any questions, feel free to drop them in there. I'll try to kind of keep an eye on things and address them as things come up. But there'll be a QA section at the end as well. So what to expect for this talk? One of the things that we'll go ahead and look at is an overview of the modules that are available, the APIs that exist in Drupal behind building layouts. And then we'll take a look at some of the design best practices and some lessons learned when working with some of these tools for a little bit of time now. So the tools. What are the options that we have now for controlling layout in Drupal? Now this talk's going to mainly focus on Core's layout builder, but I did want to kind of give a broad stroke of other options that are available. And the nice thing is, because there's a lot of overlap, a lot of the concepts that we're gonna talk about will be pretty transferable from core solutions to contrib solutions. And that's all in thanks to the Layout Discovery API. The Layout Discovery API is a Drupal Core API. And it's basically the foundation for all of this. It provides, as the name implies, the central API for all of this. And because of this, like I said, anything that I'm saying in this talk, whether you're using Layout Builder or decide to build your own solution or layer on multiple solutions within the same project, concepts will be transferable across all of these different modules. Next we'll look at Layout Builder. We'll look at some of its pros. It's the Drupal Core solution. It lives at the view mode level in Drupal. So this is basically where you go to the managed display screen inside of your Drupal site. And you can, through a drag and drop interface, place blocks and place fields into whatever layout readings that you want. And we'll kind of see some of this here coming up. The nice thing about this is because it exists at the view mode level, we're able to provide sort of default layouts for, say, all of the pages of one content type. But then it also allows us to, depending on the permissions of your user and what you wanna grant them, allow for per node overrides. So you have, say, blog posts that are gonna look all the same, but maybe a marketing manager wants to come into a specific blog post and switch some columns around or add in some more promotional content to a sidebar or things like that. Those things are really easy to do in a drag and drop interface per page. And the nice thing about that is because it's all sort of wrapped inside of core. It allows us for doing something that I think used to be kind of challenging in Drupal. And that's for intermixing of all different sort of data structures within Drupal. So you could have a sidebar that contains other fields from your content type, blocks from your global block repository. You can drop a view in there or you can embed other embeddable content all within the same interface, which before was challenging. We could use extra fields or display suite maybe some twig templating hacks. This just kind of exposes everything kind of as a first class citizen within your template. And it's kind of worth noting that it follows a very Drupal blocks system. So you can think of your layouts as having regions. We'll see that here in a bit. Every piece of content that you place within them gets sort of passed through Drupal's block templating system. So it's treated as if it's sort of a Drupal block in that sense. Some of the cons. My experience, I think the delay, the authoring experience can be a little tricky to navigate and could be improved some. I do think that's kind of a tricky thing as well because it is looking to replicate custom designs and custom front-end themes. And a lot of the times we as steamers might accidentally do something that breaks some of the authoring experience. So I think with any of these solutions there's gonna be only so much that they're gonna be able to do kind of out of the box. But I do think there's some improvements that could be made. And I've definitely accidentally broken the authoring experience before. So it's definitely a challenge to get right for sure. I do think that it needs to be reined in some. And we'll kind of take a look at how to do that with the helpful module section coming up. But another issue I've seen is that the global blocks. So if you have a block that you've created that's available site-wide and you place that within a layout builder page, the Drupal contextual links to edit everything is they're missing currently. And there's an open-issue QB where that's being discussed on how to best do that and why that's currently the way it is. And then this is a very developer-centric tool. I think if you really wanna start getting involved into how to customize layouts and provide a really honed-in authoring experience for your clients, it can require some fairly custom PHP code which if you're solely in the front end can be kind of a daunting bit of overhead. Again, looking at some helpful modules. One of them that I think is just a must is layout builder restrictions. When I said initially that layout builder kind of exposes everything as something that can be placed within a layout to anything that Drupal is aware of. It literally mean anything. Any field on your content type, any views that's been created, any block that's been created. And so what that means is you can end up with a sidebar of options that look something like this. And just the fields on the content type alone are a bit daunting. I mean, we're talking about fields that a normal content author isn't gonna need to know or care about, like the ID of the page or the promoted to front page checkbox. Like those are things that are only gonna serve. There might be an edge case where those are relevant but I think for the most part that's just gonna be confusing for content authors. So layout builder restrictions allow you to per view mode determine which layouts are available to content authors and which pieces of content are allowed. Taking an interface like we just saw and turning it into something like this where we've distinct entity browsers or distinct blocks that we've allowed users access to. Entity browser block with an additional patch that I'm hoping to get committed here shortly is another really handy one. This is really good for if you want to embed other pieces of content, media is a great example but really any content entity within Drupal. This allows you to use the entity browser module and give a really streamlined interface for browsing sort of the existing repositories of content that exists within Drupal and then embedding those and then allowing for the user pick which view mode it's viewed as. And then the last one is moderation sidebar. One thing I've been doing on a lot of projects recently whether it uses layout builder or not is just eliminating the Drupal tabs in favor of moderation sidebar. I think tabs have always been just kind of a challenging thing to fit into custom designs and have it kind of look sort of cohesive. So kind of taking all of that out of Drupal is nice and by enabling moderation sidebar you get in the Drupal admin task bar just this little task and published option. And if you click that you get a little slide out window that all of your edit, delete, revisions, layout tabs all of those things become available in there. So it's just kind of a nice way to get the front end looking a little bit closer to what people will see when they click save. The next module that I want to look at is layout paragraphs. And this is a module full disclaimer that's being developed by Atten Design Group. The pro of it is that it's a Drupal contrib solution that's built on top of the paragraphs module which for anybody who's been working with sort of drag and drop kind of authoring experiences or layout building type experiences I think all of us at some point have used paragraphs and nested paragraphs to create a three column layout and then we place content paragraphs inside of these layout paragraphs. And so the nice thing is this is a solution that we can just drop right onto an existing paragraphs interface. We're not gonna have to rework anything and it's designed to be pretty plug and play with anything you have already set up. One of the things that I really like about it as well is it's beyond just the layout building component of it it has a really slick interface for just authoring paragraphs. So even if you weren't going to be using the layout piece of paragraphs I think it provides a really good authoring experience that I would use whether or not that's an option either way for users, the layout piece. And then because layouts are paragraphs entities any configuration that we might want to attach to them say background color, background image, spacing, control, things like that we can then add those easily using the field API which I think makes it a little bit of a lower barrier to entry for somebody who's not super back-end focused. There's still a lot of times some light pre-processing that might be needed but I think the PHP code that's required at that point is a lot less significant. The one thing to mention is that this does live at the field level since it does use paragraphs. So you're kind of confined to the space of that one paragraphs field and that's actually a pro and something I also do have listed as a con as well. So some of the cons for this approach it doesn't support the default layout page. So every page that you create it's sort of you're starting from a blank template you don't get sort of the Drupal default form that you fill out fields and you click save and you already have a fully laid out page. This is by design meant to be an authoring tool that you get a blank slate and every page you creates probably gonna be one off and you want that level of flexibility. Adding in additional structures, views, blocks, things like that, those require additional paragraph types in order to add. It's kind of the mindset that layout builder uses sort of the block model that Drupal comes with and then layout paragraphs uses paragraphs as the same sort of wrapper. And then like I said, the downside is it does live at the field level. So let's say you have a header photo or you have a manual list of like related posts. It's an end reference field. You can't easily get the content from that field into your layouts whereas that's something that you could do with layout builder. And the nice thing I actually like about these two modules in tandem is because they kind of operate at different layers they're not actually mutually exclusive you don't have to pick one or the other. And there's been a few cases where we were actually using both modules sort of on the same project to control layout and the authoring experience within layout for different editor types. So, and then because they show the same underlying system a lot of the conventions, a lot of layouts that we create are reusable. So let's take a look at the code. The first thing that you wanna do is to define a layout you'll use the layouts.yaml file that'll exist in the root of your modular theme. Kind of taking this line by line label is the machine, the human readable label of this layout. Path is the folder with relative to your modular theme root that the template file is going to live in. So in this case, it's gonna be a folder inside of layouts and a folder inside of two column. And then template is gonna be the name of the template minus the extension. So it'd be to call section.html.twig would be the name of the file that's in the layout to call folder. Library, this uses Drupal's library system. So if you wanna make sure there's any CSS or JavaScript that needs to get attached you can make sure that gets on there. We're gonna skip over class for a second and talk about that more in depth here later and go right on to regions. Again, like I mentioned, this kind of follows Drupal's core block model. So we can define regions like you would say in a Drupal theme. In this case, we have a header, a sidebar and a main region. And then you just give them labels that will show up. And then below that is the icon map. And I actually think this is kind of a slick feature of layout discovery where we can create a dynamically generated SVG that represents what this layout should look like. And it's pretty flexible and you can kind of hack it in ways to get some interesting icons. So if we look at a more complicated layout we have a mosaic that I've been working on for client. And this is just a typical three column grid where the first featured item takes up the first two columns and the first two rows of that. So we can do things with icon map where it'll group any similarly named regions together as one item. And then I actually don't think this necessarily validates to any of the regions we've defined. So I think you could put any text value in there. So the one, two, three, four naming convention is sort of my own. But the nice thing is with the two layouts that we just saw, the icon maps for them will look something like this. And then going back to the class, this is for if you want to add on additional configurations for users to be able to manipulate or control the layout in various ways. So this is a PHP class. We can extend an option that comes out by default, the layout default. And with that you get five different methods that are really get leverage. We'll talk about four of them and one I'm not gonna go too heavily into is the validate one just because I've never had a practically use case myself for it, but we'll talk about the other four real quick. The validation is just when you submit the layout do you wanna enforce any sort of validation rules around things? The first one we'll look at is default configuration. This sets up as the class name, excuse me, as the method name implies any of the defaults that every layout should have, whether things exist or not. So in this case, we're going to look at a content flow setting and this basically just determines does our sidebar exist above or below our main content? One thing I like to do with all of my configuration options is break them out into an external class. And that's because we usually want access to those in a few places. So it makes it easy to get a hold of them. But in this case, we're just setting the before configuration option as the default. And then we go on to the build configuration form method. And this is just your standard Drupal core form API. So we defined a form that people are gonna be able to use to create these regions. You can see for the slick list, I'm using my get flow options method again. And then one thing that's actually really important is you can kind of see the first line of this method. I'm actually calling out to the parent. So in this case, it's the layout default. And this is a nice way to sort of stack a lot of these classes in a way to inherit from one another. One of the things layout default does is give you an administrative title field that looks like this. And if you fill that in, that populates the value of the configure link that users will see when editing this. So if we didn't actually have that call to the parent method, then we'd lose access to that field or we'd have to recreate it ourselves. And the nice thing this is, this also gives us the ability to create sort of bases. So let's say you have a background configuration, background color that you want available to all of your layouts, it doesn't matter. You can create that as a base and then just extend that constantly and make sure that if you make a change to the background color options, it's gonna cascade into all of your layouts in the site. The next one we'll look at is the submit. This one's pretty straightforward. This saves any configuration to the layout. So in this case, we're saving the content flow setting from our form state and we're saving that to the layouts configuration object. And then the last one we'll talk about is build. And this is sort of, really this is optional if you don't need to do any sort of rendering, you don't need to return anything if you're not going to do any advanced processing. So in this example, I always find it helpful to have just utility classes on all of the items and components inside of a region. So I'm just looping over all of those to add a class but this might be a useful example. Let's say you have a background image configuration that you want to do some processing on to write the CSS for. This is the method you'd probably do something like that in. And then lastly, all of those settings, all those configurations are available in a settings variable inside your twig template. And so we can do things like creating a class name with our content flow setting or controlling where in the markup a region might get rendered because of what's in that setting. So next we'll kind of look at the approach and sort of what you want to think about when looking at evaluating or designing something that's going to be built using any of these tools. The first thing we'll do is say, we'll take a look at the design. And I think one of the biggest things is to establish some ground rules. And the one thing I'll say is you don't always have to follow these rules. What I'm going to talk about is kind of my own sort of process for following things. But the nice thing about having some rules is then you can be very deliberate about when you break them in why. Rather than just kind of winging everything as you go into it. And that's going to save you a lot of time. It's going to save your clients a lot of budget when working with tools like this. One of those rules is that layouts should be almost exclusively responsible for handling the spacing between their components, their regions and with between other sections. The components themselves should always fill up and adapt to whichever region they're placed in. So if you place a block inside of a three column grid versus a quarter column like sidebar region or anything like that, you should assume that the width of that should fill up that entire region. Components essentially just shouldn't come with their own width as that can kind of make things tricky sometimes. They also shouldn't really try to set like top or bottom margins on themselves. And any of those spacing to be handled at the layout level. One thing I'll also say is, even if the design necessarily doesn't call for it, I've always found it helpful to always offer up header and footer regions for layouts. And the reason for that is, say we're looking at a component like this. This is a client that I'm currently working with. We have this now streaming label. We can kind of see that it's placed inside this light blue region. And there is significant amounts of padding that exist at the top between here and the section above that. And so this goes back to that controlling spacing concept where we wanna make sure that we can make sure that the header is grouped logically with the content that it's supposed to go within. If we didn't provide that inherently as part of the layout, a user might be tempted to be to, well, see this as like maybe a one column layout and we'll add a new section, but it's gonna be a lot of spacing between that streaming and the content it goes with. So just making sure that that's a deliberate feature in most of your layouts. In my experience, it's something that's usually asked for. So just something to kind of think about. And then, and this one is definitely probably a rule that I like, but I would not enforce on other people. But I try to stick to using Layout Builder for the full view mode alone. And then lower view modes, teasers, cards, any of those other things. I personally like to have a lot more control in terms of the templating and the markup that I can just handle and twig. However, the full view mode is I think where users and myself want a lot of that easily drag and drop experience and to easily swap out components at will. So those are some of the ground rules that I kind of go into this with. And the next thing is when I'm looking at designs, the question becomes what should be configurable? Because you can take any design, dissect it a million ways, down to its super minute pieces and create an interface around that that is very cumbersome and confused for the users. So more layout options, it's gonna require more configurations. All of these configurations, they start creating more variations, they start creating more things that you need to think through and just it starts creating a lot more overhead. So as much of that as you can limit, I think is going to be ultimately great for the client because they'll be able to make sure that everything they're creating looks great. And it's a lot less overhead for you to manage as well. One rule that I kind of talked to clients about it with is there's always gonna be an instance where not every component might work under every layout under every possible configuration. You might have a fairly wide teaser component that's gonna look really bad if you put it inside of a three column grid, for example. So one of the first questions I have is, are these rules that it's worth the time to hard code and validate and prevent from happening or can we kind of operate under the light? You hit save and this looks really bad. It's kind of an indicator. Maybe this wasn't designed to kind of go here and adjust your configurations accordingly and just getting a feel for sort of what the content authors will be able to manage themselves. And so I think that's a good early conversation to have. And then what I'll say is by far the thing that creates the most complication and has the most conversation is background colors and options. When looking at background colors and options, the first thing is will the component or will the text of components still be accessible if the background color is changed? And to that point, I'll say as much as we can restrict the background color to a set list of options gives us that control rather than opening up just like a color wheel or a color picker setting. So if we look at a component like this, this looks really great, but if we were to change this to like a light blue or a white background that text becomes really difficult to read or near impossible in some cases. And so one of the conventions that I've been doing and working with our designers to kind of stick to is making components if you essentially just a light or dark mode. So in this case, you'd get white or you'd get black text and kind of nothing in between and then making sure that our background colors are basically defined to exist in one of those. And in the configuration, this might look something like this where you can see down at the last method there, all of my colors are prefixed with light or dark. And then that actually gets broken out and saved as a separate configuration option for the color mode for the layout in general. So if I go in and change the background color of this layout to light blue, it's going to switch the, it's going to add a class to the layout for the color mode. And then that's something that at least all of my components can then hook into and sort of adapt themselves accordingly. They can kind of look outside of themselves to the layout and change colors, change border colors, things like that as needed. One of the other things that we also kind of look at is for solid colors. Do the spacing rules need to change depending on like their position to one another. So again, looking at another design example, we can kind of see the, we have three sections here. We have sort of the light blue section. And then we have two sections with a white background, the ad and the three column layout. And those are just kind of sitting next to one another. And we can see that like the light blue section and the top of the ad have pretty significant amounts of padding in between them. And that works because they are two different colors. But if you look at the ad and the three column section below that, there is, the padding between them has been significantly reduced. So we don't have just a sea of white or a sea of blue if those were both blue and things start looking really weird. So those are things to kind of notice and have conversations early on about like, what are the rules? How should these be adjusted? And how, how do you factor this in? Especially if we're also adding in background images as well. And speaking of background images, background images, gradients, a lot of those can have options that you can ask for that we hadn't initially thought about. And those can also add on to additional configuration options. So looking at our component before, it's not unreasonable to think that the user might ask, could we flip the image so that it's off to the left or maybe that it fills up the top half or the lower half and just getting a sense of what all that they're going to need to do. And usually people won't necessarily know those options until they start seeing the design and then you kind of see the wheels turning and they're starting to get creative within the design that they're getting presented as well. So just having that ongoing conversation before defining any of your layouts, I think really saves a lot of time and a lot of headache down the line. I think that one of the last things that we'll talk about is kind of understanding columns versus grids. And this kind of seems like maybe a straightforward distinction but I think it's important to know that by default in a layout building system like this, it always assumes that you want sort of a very strict structure of just straight up columns. And so when looking at a design, you can see a grid layout and assume like it looks like columns and this might look like a three column layout but you quickly realize that the content flow, especially when you start looking at cross break points, gets tricky to actually do. So a traditional setup might be something like this. This is a normal two column layout. We have our left column with the content. Our right column has an aside with some press releases and maybe on mobile we want the press releases to break below or above the content but things are pretty straightforward there. This would, the columns behind this essentially look like this but a grid gets trickier. We might look at this and say, we just need to create a three column layout within Layout Builder and that should be easy peasy. But that's gonna create something that looks like this and we know that whenever we start looking at the way that these grids will break on mobile, we have to consider the source control. So we're expecting something like this. The chaperone screening item is the first item. The pulled art quiz is the second item and that's how they'll stack once you go down into mobile. When you start breaking things into that three column structure that we were just looking at, we actually end up with a source order that looks like this. So in this case, our entire second column will break below our first column and the third column will break below the second. And again, kind of what I was talking about with the inclusion of a header and footer regions, this prompts users to start getting really creative in ways to try and accomplish things that they wanna do. And depending on the rules of your layout, it might just either not look well or it means you sort of have to start creating a lot more complicated layouts to account for all of these scenarios. So in this case, you could maybe create like two, three column regions, but if your layout by default have a lot of spacing like my intent to do, you'll actually end up with a lot of spacing in between each row. So one thing that I do is I'll usually create some sort of a grid layout. And as far as the regions go, this is just a one column region that has some CSS, usually CSS grid, to then lay out all of the blocks within it as a grid item. And then this was kind of, I think we're seeing in the render class where I like to have at least one class on all of those blocks that I can do things with. And then the nice thing is, is it becomes really easy at that point to add in new configuration options. So if we wanna go from a two, to a three, to a four column grid, you can add those settings and it's a matter of seconds to give the users that level of control. And then yeah, just some sort of general overarching ideas, naming view modes consistently across all of your different content types. So block types, media types, content types. If we're creating a common vocabulary of we have a teaser or we have a card and it doesn't matter which content structure I'm embedding, things will look relatively the same, gives users kind of a pretty consistent feel for how the system works. View modes should be configurable so that way we can pick between a card or say a teaser. And the one thing I've been doing a lot on a lot of projects is having a, I'm calling a static teaser block type. And this is always when like, we want a list of news articles but then we want the last one to be just like an ad that links off. And it should look like things, it should have an image, it should have a title and maybe description but it shouldn't actually be a news article. So this just gives them some content editing flexibility in essence. So I think that's all I have as far as that. Are there any questions? I guess I should also mention that Atten as a sponsor of the camp we have brought a bunch of our sketchbooks. So if you want to get those, go by the Atten booth and we can make sure that you can get your sketchbook. And then I believe this is the final section of talks for the day. There is a question, have access. So the question is when using layout paragraphs to content editors still have access to layout config forms provided by layout plugins. Yes, they do. So that's actually a good question. It does both pull in the configuration forms from the plugin as well as then add on a section for all of the fields that you'd add to the paragraph type. And it's actually, it'll exist in two different field sets on the authoring experience on the authoring screen. So you're not locked into like using one or the other. Anyway, what I was saying is I guess I'm the last one for the day. So after this is the bad camp happy hour and the board game night. Any information about those is available on the bad camp website. And thanks everybody for coming. If there's no other questions.