 Okay, so this is the right tool for the job content layout in Drupal 8, and I'm Katherine McClintock. I have been with Amazeelabs for six years. I'm a front-end developer, but I also site-build, and I know some PHP, but really front-end is my area of expertise. I'm also the tech team lead for the Austin Company, and I'm KCC MCCK. That's a difficult handle, but I thought it was really clever because it's my initials just really long. I don't really have that many names, but it's yeah. So I'm KCC MCCK, NoVals on Drupal at Oregon on Twitter, and that's my Doug Jackson, who's 10, and I've been doing Drupal about as long as I've had him. So yeah, this is the same thing. So as I have been working in Drupal and working with agencies, a challenge, a challenging part of the job is being able to start a project and look at a project with confidence and with some clarity as to how you'll approach different tasks that you're assigned. So this is a wireframe that is particularly along when typically our pages are not really this long, but this was a really, really big landing page. The client wanted it this long, and there are a lot of different requirements that come along with just the complexity of the link. There are things that need to change. Layouts need to be dynamic. Things need to move around, change orders, change from left and right. And the client needed a lot of control over this. Things needed to be really easy to edit, everything on the page, text, photos and layout. So when you're handed things like this, you feel very overwhelmed when you first look at it. Ha, there's my lady again. She's screaming. And you're thinking how am I going to build this? And this is a feeling that is normal. So when you experience it, you're not alone. So if you look for layout modules specific to Drupal 8, there are 120 results, 127 results, which is up about 40 modules in the last six months and still growing. Dries talked about the field layout module today. So that's a new thing to keep an eye out for. So this is something that a lot of people are trying to solve and everyone has opinions on what the best approach is. But my opinion is really the best approach is what works for you, what makes sense in your head, what works with the team that you're working with, and what makes sense for the length of your project. Try to think about things, not just from like this is a page that I'm developing to launch in the next three months, but this is something that needs to live and be maintained over a long period of time. So don't feel overwhelmed like this man who has too many choices in the grocery store. Try to keep things simple. Confucius said that life is actually really simple, but we insist on making it complicated. And hopefully you know a little bit about the modules that I talked about last time, but I'll go through, I would say, the most common layout modules that are available and talk through the pros and cons of those different modules. And that will hopefully help you make some clear decisions that you can really stand behind and have reasons for why you've chosen to do things the way that you do in your upcoming projects. So there are things that are available by default out of core, and there are things that have been contributed, and mostly we'll look at the contributed modules, but there are a couple of things that are worth mentioning in core. So I'll start with the very basics, and that's the Drupal layout system. With Drupal, you have really two main things that you can add into your site, and those are modules and themes. And themes control the layout of your site, and they also control the look and feel. That's the main thing that they're here to do. So inside a theme, there's an info YAML file, and there are regions defined within that. There are default regions that come with Bartik and other of the themes that ship with Drupal, and you can also add custom themes or sub themes where you can define your own regions. And then you essentially just place blocks into those regions. That's really like the very core of what Drupal does in terms of how it handles content layout. So here, you've probably seen these yellow regions being demonstrated when you go to the block layout page and you say, show me, demonstrate the block regions. So you've got some header regions, some content regions, and there can be more of these down the page and in different orientations. So with blocks in Drupal 8, they are much improved to the blocks in Drupal 7. So that is a good thing to take advantage of. Every Drupal 8 project that I've worked on to date, we have created custom block types and used the new things that are available in Drupal 8 in this way. So there are, like I mentioned, that you can now create custom block types, and this is just like a content type. You can say, I want this specific content or this specific block type, and I want to add these fields to it, and you can manage the display of it the same way that you would other entities in Drupal. You can also reuse blocks. I'm going to give the same example as I did last hour, but that's the menu block, which is really nice to be able to only have one menu block that you would place in both the header and the footer. Instead of making a block twice in Drupal 7, that's the same thing and printing it out twice or doing that through code. You can just reuse blocks wherever you want on a Drupal site. And I think it's also really useful that the system blocks have been moved from the page template file in Drupal 7 to the user interface in Drupal 8. System blocks are page titles, system messages, tabs, breadcrumbs, things like that. Those are the four that I'm going to memorize, but there may be more. And the reason that that's really nice is you can then control their visibility a lot easier than having to create a custom page template file that you really just would rather not have too many template files laying around your theme. So this is nice because this is a reason, a use case that comes up quite frequently. And blocks still support the conditions API, which I can talk about more. So here, this is an example of a pattern that we identified for a project that we wanted to appear in various places in various pages on our site. So we wanted to have a background image, a title, and some descriptive text to appear at the top of a lot of pages. So we said, okay, we're going to call this a directory header. We called it a directory header because this is a solar search page. So you can see there are some facets at the bottom. And there were a lot of directory pages on this particular site. So we created a custom block type. It looks a lot like creating a content type, where those three elements have been added as individual fields. So there's a background image, a page title and some supplemental text. So that looks pretty normal. From there, you populate data. And you can create as many of these as you need. So here, you can begin to define, now that you have a block created, you can define where you would like it to appear within your site. So here I am saying, please show me this block on the our work page. And that's it. If there's ever a case where you want to combine some of these visibility settings. So perhaps you want to show a block on a specific URL, the pages tab that is active, and on a specific content type, you would not be able to do that with blocks alone. So I'm recommending this module that's new for Drupal Aid that's called block visibility groups. And it allows you to create these more complex visibility settings that can have different combinations that you couldn't have with just the Drupal block layout interface. And there are additionally more modules that can extend this even further. So if the type of visibility setting that you need isn't available with the default module, there are extensions like menu conditions, term conditions, token conditions. So these are some of the supplementing modules that you could install in addition to this to get even more granular control. And here's a screenshot demoing this module. I've added a block visibility group here called work. And I first have to select if all of the conditions that I'm going to add should pass, or if only one of the conditions that I add must pass in order to show the block. You can think about this as an either it's an and statement or it's an or statement, meaning that if I if I say only one condition must pass, which is currently active, then the block is either going to show if the request path is our work, or if the vocabulary is projects. If I had selected all conditions must pass, then it would mean that the request path must be our work and the vocabulary is projects. So that's pretty cool. With blocks, the great thing about blocks and your blade is that they're fieldable. When you can field something, you can also control the markup that is output through the theme. And that gives you a lot more control and precision and confidence that the layout will render to your liking. You can reuse blocks. And this is the same as in Drupal seven, but there are contextual links, which I think is worth mentioning because clients or editors of a site can really benefit from being able to see that little gear that appears and when they see that it's a very clear sign that they can just click it and edit their content and it'll take them directly to whatever data they're trying to change on the fly and not have to look through a long list of content and filter. Blocks are also configurable. And by configurable, I mean that they are exportable and importable through configuration management. So if you're familiar with using ECMI, you can export anything, any site building, any configuration that you do on your Drupal eight side, if you're working locally, or in any environment actually, whatever site building you do, you can export it and then import it into a different environment, like a development site or a production site. So there are problems with blocks being configurable, but they're minor. And that has to do with the universally unique identifiers. Those tend to get unsinked, that's the correct word, I'm not sure, but they don't sync up typically if your databases aren't exactly the same. So there's an ID assigned to a block type, and it's a very long string of characters. And on a different environment, it's going to make it some other very long string of characters, and they won't be the same. And so when you import a block type, and then add the content to that block, it might say that the block is broken or missing. And this is something that has happened to me a lot. I can't more than 10 times. So it's easy to fix you would just go in and delete the block, and then re add the block, because the type will still exist. And the other thing that is risky about blocks, in terms of using those for your entire layout is that it will become really unwieldy to, to manage if you have even a small site, if you have a lot of blocks placed in different regions on that block layout page, it'll become really long, really fast, and you won't really know what's going on with weights, like which blocks should be above another. What are the visibility settings for these blocks? So it's just not a very good long term solution for managing complex layouts. You can definitely use blocks, but I wouldn't recommend laying out the entire layout for your site exclusively with blocks. So the, the next module that I'll discuss is context. And context is based on conditions and reactions. And people call this module the block layout on steroids. And conditions are things that are looked for when a page loads. And if those conditions are met, then a reaction is fired. So that's really how the context module works. So here you can see the default options for conditions that come with CleanDrupal 8 install. And you have quite a few things that you can select from. For this example, I've chosen the request path because this is something that I think is a pretty common need. So you want to do something if the condition is slash user. So it could be, this is a wild card, right? So any user on the site, we want to do something and you can continue to add conditions here. So you're not limited to just one. So once you're happy with the conditions that you've defined, you can then go on to add reactions. And for this example, since we're talking about blocks, mostly, I've added, I've selected to place a block. It's not shown here, it's further down the page. But I want to make you aware of something that through a colleague of mine for a loop, the first time she uses module in Drupal 8, I think this is actually a difference between the Drupal 7 version of context and the Drupal 8 version of context, but I'm not 100% sure. But because my colleague was really familiar with context in Drupal 7, she was surprised that when she created a new context and placed a block in Drupal 8, that other elements on her page or on her site went missing. She was surprised that they had disappeared. And you'll see here that the header region is empty. It says no blocks in this region. And if you can imagine the block layout page, they actually would have elements or blocks assigned to the header region. So I have a logo and I have a menu. And suddenly when I install this module and start placing blocks in other regions, those two things are gone. This is a feature, it's not a bug. There's an issue on Drupal.org explaining the problem, right, asking about why is this stuff gone. And someone goes on to explain that when you install context, it completely overrides your block configurations through the default block layout interface. So I think if you're using this module, plan ahead, and if not, just be aware that there's going to be some additional work to look at what you have been using through the block layout interface and moving it and refactoring it to work through context. And a really nice solution to not have to repeat adding elements or blocks that occur globally on your site is to create a global context where you would say, okay, I know on all of the pages I need to have the menu and the logo. So I'm going to create a global header context. And then you would not have to then repeat placing the header blocks every time you create a new context. So the good things about context is that they do improve that block organization page. And because it's very streamlined and it's very block based, it does output cleaner HTML than alternative contributed modules like panels specifically. It also supports the block visibility groups module that I just mentioned. And for the negatives, you will overwrite the default block configuration. So plan ahead, and just know that that's going to happen. When you use this, had I gotten to panels by the time the session? I hadn't. So this is all new. Now, I didn't know where it ended. Okay, so that's good. Okay, so with panels, panels is a really big module. And panels is a module that people have strong feelings about. People tend to either love panels or hate panels, pretty neutral towards panels. I'm one of those rare people, I think where I don't know, it might just be my personnel and like however you want to do it, whatever makes you happy. But there, there are benefits and disadvantages to panels. And I'll go through that. It works similarly to these other modules, but it just has a bigger container of features that that ships along with this model. Okay, so panels is in beta in Drupal 8. And it is pretty stable. We have used it. So that's that and Drup in Drupal 8 panels is an API. And that's a little bit different. It just essentially, it means that you need to have an implementing module to use make use of panels and the two modules that do that currently are panelizer and page manager. So we'll take a look at a design again, where we might consider using panels. So here, we would look at the main area, the main content area of this of this design and and think about how we might want to define the regions. So here, there's that directory header block. So we'll call that a region. And then because this is a panels or a solar search page, there are a few more regions. And we'll just identify both of those as the two rows will have two more, one's the yellow bar with the facets and then one's that bright blue bar with the search results. And then finally, there's an area to display the search, the actual content, the results of the search. I kind of I don't know if that's very clear, because I use the same naming conventions, but but yeah. So those are the regions that I might say, okay, these are the things I want to turn into regions through this YAML file. So this is really similar to the info file in a theme. You would create this layout YAML file and give it a label, give it a category, tell it where the templates is this buzzing, get tell it where the template files are coming from what directory and then define those regions. And once you rebuild the cache for that, then you can then use use those regions to add different pieces of content that are not limited to blocks in those different regions. Oh, is it on? Oh, thank you. Is it on? Yeah, it is. Okay, maybe that's the reason. I'll try to buzz. I'll try to buzz less. Okay, I don't know what to do. Okay, so the bigger features that I mentioned that come with panels, as opposed to just that kind of placing components within different areas, or these things. So this is this is actually not different. It's not unique to Drupal 8. But these are the things that are a little bit more robust with with panels. And that is that panels can react to pass it. In fact, page manager page manager can. Nice. I think that worked. So you can just create a new path on the fly. You can go to pages and say, I want to create a new page slash events. And that will be there. You can also enable or disable permissions based on different criteria. So we just had or we actually haven't we have a use case for this where we have a campaign launching this week. And it's the primary landing page for this campaign was used using page manager. So we created a permission that says currently while the campaign has not launched, we're going to restrict access to this page to everyone except for administrators. And then when we're ready to go, we'll just this will turn that permission off, we'll remove it. And that'll be live and accessible. You can also create different versions of the same page. I'm using different layouts showing different content. So this is a powerful thing to do if you have maybe specific things that you would like to display or not display based on some of these more complex settings. And then panels is also supports context, which is not the same thing as the context module. This just means that different things that you place within the panel can be aware of other things that you place within the panel, if that makes sense. So you can have some smart, intuitive things happening that you can configure directly through this module. So to summarize, panels is good because it's quite powerful and it's complex. And it makes use of contexts. And it integrates really well with other systems like views, you can add those and many others that aren't coming directly to the top of my head. But it does integrate pretty well with a lot of other common Drupal things. And on the flip side, there is a learning curve for Drupal or for panels. It's a little bit better in Drupal 8. It's a developer's tool, meaning that I don't particularly tend to want to, some weird sentence, but I don't want to give clients access to these panels. And that's not necessarily a very good solution for clients that need more control over the layout of their page and for what's being displayed. It's a heavy module. There's a lot of code that comes with it and a lot of complexity and it can have some performance implications. And it is an all or nothing approach in the sense that if you decide to panelize a page, that page will not respond to other layout modules like a simple thing like placing a block. So you're going to have to do all of your content layout through that panel page should you choose to use it. Okay, so the things I just discussed have a lot of relevance to creating large landing pages. And now I want to take a little bit of a closer look at smaller elements like nodes. And I don't want to talk, I don't want to spend a lot of time on the WYSIWYG, because you're all familiar with it, I'm sure. But it's in core now. It's CK editor is in core. So that's nice that you don't have to install it anytime you want to have a WYSIWYG. And this is an example of a page created through a WYSIWYG. There's a little bit of layout going on. It's nothing to write home about. But you can see that there's some left and right alignment. And it's really it's this is a very typical use where you have some headings and some links and some text. And you just maybe want to get it in really fast. The client needs a way to have, you know, control to just get something in quickly without having you build out a new content type or something. So yeah, that's the way that it displays to the end user and then through the the WYSIWYG it's not as nice. And really the point that I want to make about the WYSIWYG is that it's problematic because markup is very likely to become messy. Even even from having people on your own team, you know, do these things, there's empty P tags or there's an image inside a heading tag because someone dragged it around and it didn't it wasn't smart enough to know. And my favorite is this is real. This actually happened. We had a client who insisted to have every type of tag allowed in the WYSIWYG. She was she was Drupal Savvy. She knew enough to be dangerous. And she found a view on another page and copied the markup for it and pasted it in the WYSIWYG. So this is I refactored the words in it to make it discrete. But that happened. And we were thinking like how did we let this happen? And then we thought well, she's a really smart lady. And this is something else that you can do just just so that you know you can add templates to CK editor. And if you do that, you then can add a button to the WYSIWYG where you can add custom templates and your client can choose from those. And that's not something that we use often, but we do have maybe one or two sites that have this from a while ago. So that's something that you can do. The WYSIWYG is mostly a danger zone, I think unless it's used with extreme caution. But there are benefits. And I'll go through those. The client likes a WYSIWYG, I find you know they feel like, oh, you know, they're comfortable with WordPress or something, which is probably a much better WYSIWYG, I don't know. But they're familiar with it and enjoy working within it. They feel free. You can conserve some design and development budget using it. And it's efficient. And you can create custom HTML elements where you can, you know, have different styles on a button or a quote, you know, there are there are things that you can do to make this custom and more robust. And you can add those templates like I mentioned. And negatively, your design quality will most likely suffer. If the markup is is, you know, weird, or something is inserted into it that you hadn't planned for you really can't anticipate what's going to happen. There are additionally performance risks. You might imagine someone taking a really huge image and putting that in there without it having an image cache preset or something on it. So that could be dangerous. I think I've said these are there are inevitably markup issues almost always. And the things that you do customize, even those things that you've put good hard work into adding custom elements, those things are not bulletproof. So this has been a problem for Drupal for a long time. And the answer to the WYSIWYG problems is paragraphs. This is a great module to use. Instead of a WYSIWYG but also any time that you want to give your editor control over the content and the layout. So you can create sections of structured content where you where you know for sure, no matter what order of paragraphs they they add and no matter what data they put into them, you can plan for all of the different variables and feel confident knowing that you're going to still have a beautiful website that you're proud of at the end of the day. So yes, it's very flexible. As a site builder, it's a pretty simple process. You install the module and then you would identify all the different paragraph types that you might like to have on your site. And I can I'll show you a few examples of some different paragraph types that we've had on sites in the past. Once you've made a list of the paragraph types that you want, then it's time to start adding those paragraph types and adding fields to those and building them out. And you do that exactly like you would like a content type or like a custom block type is the exact same experience. So it's familiar and easy. And then you enable the paragraph types that you have created on other Drupal entities. So a basic page, for example, you might say, anytime a client creates a basic page, I don't want them to use the WYSIWYG. I want them to build basic pages using paragraphs. So you would add you might delete the body field altogether, and then add a paragraph field where you tell that content type which paragraph types you would like to allow the editor to use on that that content type. So here are a few examples of content or paragraph types that we've created in the past. This is an accordion. You know, there was a reason that there might need to be accordions in a lot of places on this site, and it doesn't make sense to work on this just once just build this whole thing as a paragraph. It was the ninth type. So you can see the site had a ton of paragraphs. This is the 10th paragraph type. It's a photo banner. It's really similar to that heading block that we looked at. So there are four elements here, the background image, the title, the text, the button. You can also add entity references as a paragraph field. So this is a paragraph type that allows you to add an unlimited number of entity references to another content type on the site, which we called site. So it's a little confusing because it's an entity reference, but the naming convention for the client was site reference. That was the name of her content type. And then, yeah, so like I was saying, it's really similar to adding content types. Those are the three that have been added as paragraph types. And here is what I was also mentioning that there's a body field on the basic page. Yeah, this is a basic page content type. And then I've added a paragraph field. So it's really that simple. And then for the editor, it really couldn't be any easier. They add paragraphs to you can also add paragraphs to blocks. I'm always mentioning content types, but you can use it on other entities. So you can add paragraphs and then add data to it. So here I've added a new node called paragraphs demo. And I've added, I've already added two site references. And then that button at the bottom, it says add accordion. So I could then add an accordion or if I click that tiny arrow to the right of add accordion, it would show me all the paragraph types that are allowed on that entity. So there would also be the option to add the site reference there. And then I would just fill out the fields and I can drag and drop them, reorder them. It's really easy. This is a this is an interesting, I think an interesting use case for paragraphs, because I don't think that the normal or the initial idea of how to build this would be paragraphs. And I want to talk about want to talk through a little bit about why we decided to use paragraphs for this. So just as some some background information, this is a wholesale table. We have a client who has a boutique sawmill. And he needed a way to displace wholesale items in a table or something really simple for his his users to use. So looking at this, I think the obvious thing that everyone sees is a table. And it is a table. But the reason that we chose to use paragraphs and not the WYSIWYG where you can put a table in is because we also were thinking about how is this going to work on a small screen? How is this going to work responsibly? And there are ways that you can turn tables into responsive elements, but it requires some JavaScript to do that. And if the markup in the table doesn't match exactly what that JavaScript needs to, to, you know, restructure the markup and toggle things, then that whole piece will break down. It won't, it won't work. So we knew we needed to really have total control over the markup being output. And we didn't want to risk it being broken in a WYSIWYG. The other idea that we had was to use views, because we're displaying the same type of content over and over. And we ultimately went against that decision, because we didn't want each of these wholesale items to need to have their own node. We just wanted them to live on this one page. There wasn't really a reason that he would need to go in and edit, I don't know, 10, I mean, it was a long page, but he wouldn't need to edit 10 separate nodes to get this on a page. We wanted it to just live on the entity. So paragraphs fixed both of those problems for us. So here we use nested paragraphs. And I'll tell you a little bit about nesting paragraphs. So there are two types that we defined here. One is a wholesale table. And that has two fields. It has the name of the table. So it was like Red Elm and another species of wood. And then there was a second field, which is a reference to a second paragraph type. So that's really cool that you can nest them and reference other paragraphs. And the second paragraph, well, the second field referenced the second paragraph type, which is the wholesale table row. And the fields within that were the columns. So things like grade, images, notes, tally, those woodworking terms. And then for the editor, this is how this content is managed for him. So he added a new table called Red Elm. And then he can add as many wholesale table rows, which are also paragraphs and manage the content within that. I think it's worth mentioning here that the only downside here is the edit form. You can configure whether you would like the paragraphs to be expanded by default, collapsed by default. And there's some weird preview thing that's kind of a hybrid. I haven't played with that very much. But I feel like it's kind of picked the, you know, the least bad. Because if you have everything expanded by default, again, this page is really long. And if you have everything collapsed, it's difficult to know if he wants to change the fourth table row and this that he needs to remember that and then come in here and expand it to edit. So just just know about that. But if you don't mind long forms, then you can expand everything and you should be able to have things be pretty clear. So on the positives, you can nest paragraphs, reference other paragraphs, reference other entities. You can change the order of these really easily either with weights or dragging and dropping. It's very intuitive and familiar. And the client controls the layout and the content. And I didn't tell you, I mean, you can get really creative with paragraphs, you can use it in even more complex ways, where you could give the editor options as to whether they should align something a specific way, like to the left or to the right. Or maybe you have something where you know there's an image behind some text and you can give the editor the option to display the text that's over it in a dark font, dark color text or in a light color text. And people are doing really innovative things with paragraphs that exceed my expertise in this area. There are paragraph talks at this conference happening. So I think it's really exciting. And I think that the options and the boundaries for this is pretty limitless. I mean, you can be very creative. And I like that. The bad thing about paragraphs that has thrown people for a loop is that they expect when they add content to a paragraph that then they can put that same content on another page. But the content that you enter into a paragraph lives on the entity. And that's it. So you can certainly reuse the paragraph type on different entities, but you can't reuse the content. So just be aware of that. If that's something that you need, this would not be the correct solution in that case. Paragraphs, I know this is a Drupal 8 talk, but also consider multi-lingual in your project. I know that in Drupal 7 it's quite problematic. In Drupal 8, I'm not as up to date as to how multi-lingual and what the support is it is like. But it's better. It's better in Drupal 8, for sure, because I work with a team of really smart multi-lingual people in the Zurich office. And we don't do hardly any of it in the States, but they are using paragraphs in Drupal 8 sites. So I know if they're using it and the multi-lingual thing shouldn't be too much of a hurdle. And also, like I showed you those edit forms, just kind of that, that not knowing if things should be expanded or collapsed, just be aware that that could just be something to keep in mind. Next, let's take a look at Panelizer. So Panels is great for layout for large pages. And Panelizer I think is better for content pages. So it's in beta in Drupal 8, and currently it requires that you configure it through the in-place editor. I'll show you how that looks in just a few slides ahead. It's very different in Drupal 8, and it was in Drupal 7. A lot of the modules, when they're ported, they are very similar, but this one is different. And it also supports panelizing all of Drupal's core entities the same way that many of these other modules have. Also, there are two beta versions for this module, and one's for the 8.2 release of core and one's for the 8.3, and I've only played with the 8.2, so this is what that is. As soon as you install and enable this module, there's a check mark at the bottom of the display that you're managing that gives you the option to say Panelize this View Mode. So as soon as you click that, the fields disappear. And you're like, where am I going to, you know, how am I going to do this? So another option becomes Visible, which says, allow custom overrides of each entity. So that's a nice feature that Panelizer has. I think that's one of the nicer things about it. But now, in terms of using it, you currently have to go to an actual piece of content of that entity that you've chosen to Panelize. So here I've gone to a node, and right now it's not Panelized. It's just got all of the content that I've added to it, printing out and rows. So there is a widget that will appear on the bottom of any of these content that you've Panelized, and there are some options here. So you can change the layout. There are default layouts that come. You can also add your own. You can add other types of content to this node that you would not normally be able to. So that would be worth looking through and seeing if any of those things might meet a specific use case that you might have. You literally just drag and drop things after you've selected a layout. So if I want to move the Drupal Texas camp image from the left to the right, I can do that. And that's a shameless plug to fly to Texas in June. If you are so inclined for having a Texas camp, which is going to be awesome, it's in June because it's hot. We love the heat. And then when you are happy with it, you can save it as the default, or you can save it as a custom override. So if you have content that you know you want to have some variations between different nodes, you can use this to create custom layouts. And I think that's a great thing. The custom overrides. The in-place editor is also nice for clients. I hear a lot that people, that clients, want to have that level of control. I think it's a little frightening for site builders and for front-end developers to hand it over. But if you can limit the amount of templates that are available to them and really try to plan so that there aren't too many options, you know, you could feel comfortable handing this to someone. There's the ability to add the other types of data that aren't normal to other modules and other ways to control content. And it's really actively developed. Every time I check on it there are new commits and things that are happening. So there's a lot of momentum there. And I think it's good. At first, you know, I have new intuitive interface. It's a good thing, but also is a bad thing. It's unfamiliar. At first I thought it was just strictly bad because I thought it was, you know, unlike anything I had seen in Drupal and I thought this is really clunky. But after having given it, you know, some thought is good. I think it's good that we're seeing some new UX designs in Drupal and, you know, I applaud them for taking whoever's maintaining this to take that risk and think outside the box, the Drupal box. The last thing I'll say negatively is that there are some layout risks that are assumed with this. I don't know how it works responsibly exactly and I worry that if a client put in something that really was better suited for a wide column into a small column, you know, I just, I like the control and this makes me a little fearful. But if you trust your client and they have good judgment then this should be negated. The final module that I want to talk about is display suite. Display suite is a drag and drop interface for how content is displayed and you can enhance the displays of all of Drupal's core entities. You can use this module in many instances and you can forego template files essentially if that's what you're looking to do as a site builder. If you just want to control things with this module, this is a good solution and the layouts are exposed through the layout plugin module. Remember when I was talking about panels and page manager or panelizer and page manager implementing panels. So it's similar in that regard. Here is an example of a task that we or an exercise that we went through in order to use display suite in a very global way for a project. We had the requirement of building a very data heavy site that had a lot of different fields, many of which were shared between content types. So there was a lot of information and text being output to the page. It's not like the most glamorous website but it was very scientific and research heavy. And because of the budget that we had we didn't want to make custom templates for each of these content types. We wanted to reuse things and streamline the front-end process. So here are I guess seven images. I don't know. There are some images here of a layout on a white board and you can see the sticky notes represent different fields. So we were trying to come up with a layout that would make sense for all of these different types of data. And once we were happy with how those things kind of shook out on the board, again this layout sample file you define the regions. We got a little creative with the naming conventions and you register that to your theme. You rebuild the caches and as soon as you do that when you're managing the display for a content type you can select which layout you would like to use for display suite. So here I've selected full node and that matches the label for that YAML file that was on the previous screen. Once you do that then you can manage the display of your content the same way that you always would. There are just additional regions and it's essentially the exact same experience. I think there's only, I don't know what it's called, but just one main region by default. So this gives you some more some more areas to work within. So we had a good experience using display suite on this project in conjunction with Pattern Lab. This was the first site that we used Pattern Lab on and everything that we experienced was pretty seamless. I know people are also using paragraphs in conjunction with paragraphs and also having some some success there and it's also positive that it's efficient and familiar and you can define your custom layouts like in many of these other modules and the other really cool thing that you can do with display suite is create block fields. So once you install and enable this you can then place blocks actually within those different regions. So a block is actually being rendered in the main content of that entity which is different than what a lot of these other modules how they handle blocks. It also on the on the negative it doesn't support custom overrides per entity and that's something that panelizer does better. So if that's a if that's a need that you would like to have some nodes look differently than others then I would probably lean more towards panelizer. The structure is stored in the database as opposed to templates and this is actually true I should have listed this on more of these modules but it's site building and that's kind of what happens so it's not unexpected you know what's you know what's being done but just something to consider again. I'm not going to talk about twig because this is site building and I really want to focus on the tools that we have but twig is excellent you can override and restructure markup with total control and you can be very generic with your templates are very specific so really it's hard to imagine a solution where you don't utilize both layout module and twig templates at the same time all of our drip late sites we're using twig templates so it's really just finding a balance and figuring out like you know there's so many ways to do this it's amazing you know because there's not really a right or wrong but yeah so so think about it and I hope that having heard all of this that you might have a little more clarity starting your next project in confidence and and understanding of what tools are at your disposal so with that I'll take questions if you do want to ask questions they're in that backpack the microphone for the recording and that's it you can add entity reference fields to paragraphs and you can also reference paragraphs does that make sense so and I'm not positive if you if you can reference paragraphs from anything other than other paragraphs that's something you should check on but you certainly can within paragraphs you can reference other paragraphs from another paragraph and I think it would probably be the case that's interesting I don't know I've never actually tried that and I have heard that you can't reuse the content so I that would be a good experiment definitely the second question is I haven't used it I've never I don't have knowledge on bricks but you're the second person who has said that so I'll yeah and thank you for doing the first thanks features right yeah features for me I haven't used in jubilee because we're using configuration management yeah I don't I'm sorry I really haven't used it no it's okay it's okay sorry very simple you show us a sign at the very beginning what are you at that using to build that site which one the mockup that you showed at the beginning of the presentation of the mockup one month or well I don't I'm not sure exactly which screenshot I think most of them come from the same site but typically what we do is we will use I think about you know that it's nice to have functionality from all of these modules but you want to try to limit it to not having every layout module under the sun installed on your site so I think in the case of that screenshot we use blocks we use page manager with the layout plugin it's a little different than panels and trying to maybe I'm trying to think what else I would recommend really trying to keep it limited so pick two or three and then commit to that right you can do almost anything but we probably just use those two those two things and tweak templates the landing pages exactly yeah yes I don't think so because I gave it a trial run and recently and I did not notice that happening so I think the answer is that no it does not did that happen to you oh wow and it took away all those blocks okay so maybe it does then but but hey I hope that was the problem because then you know what happened the other thing I wanted to mention was that you mentioned how to insert into the WYSIWYT well just taking the WYSIWYT techniques and I wanted to share I don't know if you guys are aware but there's a WYSIWYT module so you don't have to actually create the JavaScript on the big file or it's just actually configuration very nice that's great to know do you have a client that wants to add blocks on a page by page basis by a what page by page basis they created a new node and they wanted to add a block onto the page to reach them what do you think is the best solution well maybe with paragraphs if you can have something that references a block because they're an entity so you should be able to do that I think I would personally probably have that region through a template file a twig file but you might be able I mean you would also probably be able to do maybe something well I wouldn't want to say panels actually I would I would think about paragraphs and then I'm not sure how you would want to register that region but that could be that could be something you know so yeah good luck yeah yeah that's fine