 So I'm going to be talking a little bit about creating a robust content architecture for Drupal 8. I'll be talking about blocks and paragraphs and fields and nodes and entities and it's going to be awesome, yeah. So I'm not going to repeat this. I'm Suzanne. I work at Evolving Web. I do training. This is a question that we all come across when we're building any Drupal site. How do I structure my content? The whole reason to use Drupal is because you have a bunch of content that you want to publish, right? Rarely do you build a Drupal site where that's not one of the most important things. And so today I want to talk about when you're making that decision, how do you pick between the different options? Because in Drupal 8, there's not just one way to build out your content structure. You could probably, for any site, find like 10 different methods of organizing things. And usually the question comes about when you're looking in Drupal and you're hovering over the structure tab and the admin toolbar and there's all these different things that you can do about the structure. You can create content types. You can set up your taxonomy terms. You can create, go in and create custom blocks in your custom block library. And if you've added the paragraphs module because you're trying to use like the cool new thing, then you've got all these paragraph types as well. And then if you're a developer, you might also think, oh, I could go develop something custom. So often this is something that's very confusing and I'm going to walk through all these kind of options and explain them in more detail. But before I start with that, I just want to cover some terminology. I know a lot of you probably already know what all these terms mean, but I think it's a good refresher for us anyway. And for those of you who are newer to Drupal or maybe haven't used Drupal 8 or just haven't encountered these bits of terminology before in Drupal, I just want to do a quick refresher. So first off, entity. Entity is this really vague word. I actually went to a Drupal con a few years ago and there was a presentation where there was a fashion show as part of the presentation and I dressed up as a Drupal entity. Like some weird thing. Anyway, it was a very creative presentation. I decided not to do that today. But an entity in Drupal is a piece of content. Basically that's what you need to know. That's a content entity. In Drupal 8 we also have configuration entities, which are pieces of configuration. And of course you do a lot of configuration in Drupal. You go around, you set up content types, you add fields, you check check boxes all over the place. And so you're actually creating configuration entities all the time. But what we're focusing today is on the content. So content entities are when you're creating actual bits of content. So this could be nodes, this could be custom blocks, terms, users, comments, et cetera, et cetera. So when you're creating content, you're actually creating content entities. When you're checking check boxes and setting up new views and things, that's configuration entities. And it's really important to know the difference. So today everything I'm talking about is about content. Fieldable. The word fieldable I don't think is a real word. I'm not sure if it's in the dictionary, but it's a Drupal word that you should know. Fieldable means that you can configure fields on something. So if you go in the Drupal UI all over the place, you're going to see the manage fields tab. That means that it's fieldable. That means that you as an administrator can go in and define what field something has. So of course nodes are fieldable. We all probably know we're sitting here in the room. We can define content types of different fields. Those are obviously fieldable. But other things are fieldable too, like taxonomy terms, custom blocks, users. And I'm missing some things here. For example, menu items are content, but they're not fieldable. If you go to a menu and you're editing the menu, there's no manage fields tab there. So out of the box, menu items not fieldable. Bundle. Bundle is a great word. You see it inconsistently used though. It's not always the word bundle that you'll see. You will probably more familiar with the word content type. A content type is technically a bundle. So a bundle is just a more generic word for content type. That means the difference between different nodes or different terms or different blocks or different paragraphs. So within each content entity type, you'll have different bundles. And the bundles can have different fields. So the most obvious example is like with nodes. If you're creating, if you go into your site and you create an article, it has an image and it has tags. If you create a page by default in Drupal, it doesn't. It just has the title and body. So they have different fields. So these are different bundles. But this applies to all different kinds of things in Drupal. So you can have different bundles on your taxonomy terms. Those are called vocabularies. You can have different bundles on your blocks. Those are called block types. But word bundle is just more generic. That's another good one. And then the last one, base fields, you might not have heard or thought about this, but you'll know what it is when I describe it. So when you create any node in Drupal, there's always a title, right? Like you can't delete that title field. Sometimes it's annoying. You're like, I don't want this thing to have a title. Well, too bad. Every node has a title. So a title is a base field. You also have a bunch of other ones like the author, the posted date, the fact that something is sticky at top of lists or promoted to front page. All of those are base fields. So they're fields that just always come with the content entity type. So that's the terminology you need to know to understand what's coming next. Well, that's just a bit of background information for you. So when we're looking at different, these are different content. Well, the first four are different content entity types in Drupal. When you're thinking about how to define your content, you kind of need to know the different role that each of these would play. So why would you use a node versus a block versus a paragraph? This is kind of an essential question. So first off, just at a high level, nodes we think of as like basic building blocks of Drupal. If you were building a site in Drupal 6, pretty much you'd build everything as nodes. You'd use nodes for your main page as a content, but then you'd also use nodes if you had some kind of subcontent that you wanted to list on a page. You'd just use nodes for everything because there weren't as many options because nodes were the things that we could attach fields to. The thing that still is important to know about nodes is that each node has its own URL. So if you want to create something that lives on the site somewhere and you can click on a link and go to the thing, that is essentially what a node is. So we still use nodes for all of our really standard pages of content. Terms, the defining feature of terms I think is that they're hierarchical and they're used to associate pieces of content with each other. So you use terms to categorize content, right? But terms and nodes, they both have URLs. So sometimes you get into this thing like do I use a taxonomy term? Do I use a node? Because each one of them you're going to have a page to work with. Each one of them has fields. So sometimes you're in this quandary, should I use this, should I use that? Basically nodes are more like traditional content. So you get more of the standard features for workflows and being able to have content that people are making revisions on. So if you're expecting content to go through that standard workflow, then you probably want to use nodes. And terms are more something you're going to use if you want to categorize other pieces of content. Custom blocks. So custom blocks in Drupal 8. You can have fields on them, which is amazing. They work much more similarly to nodes. You can translate them like you've translated nodes and terms. This is all very exciting. And so you can have different kinds of custom blocks. So then the feature of custom blocks is that they don't have a URL. There are things that you just place on the page. And you could just place them using the blocks layout page like you would every other block. Or you can reference them from your content. So these are more like chunks of content. And then paragraphs don't come out of the box with Drupal, but you probably heard about them five times already in the conference. I think Crispin was talking about them earlier when he was describing the prototyping. So paragraphs are similarly to blocks. They're chunks of content that you can embed in a node. And the important thing to know about paragraphs is that they live within another piece of content. So you can't just take a paragraph on its own and say, oh, I'm going to create this paragraph over here. Paragraphs are really designed to live within other content. And the word paragraph is not a very descriptive term. Paragraph, I think, should be called field collection. This is what was the name of another module that was similar to paragraphs. And it was kind of a better descriptive word. So when you hear the word paragraph, kind of ignore the connotations of that word. Paragraph in Drupal is just a set of fields, like a mini content type. And then custom entities and fields require custom development. So custom entities and fields are things you're going to use if you have some kind of extra functionality that you need. Something that doesn't fit into one of these other four slots. So when you're looking at the content architecture of your site, maybe you're looking at the wireframes, maybe you're looking at a site map, maybe you're talking about the content of an existing site and how that's going to map to the new site. At some point you're going to have this conversation about how is our content going to be structured, right? So you might be looking at some information like this. You might be saying, oh, here's, in our footer we have some standard pages. We have landing pages that have some kind of abstract landing page content that's not very well defined. And then maybe we have some views, like the things up at the top here, holidays, deals, articles, whatever. You're going to end up having some types of content on your site that are more like well-defined bits of content that you want to make lists of. So things tend to, you know, by looking at wireframes, by looking at a site map, by looking at existing content, you'll be able to start figuring out what your requirements are for the content. So that's a really important step. And when I'm analyzing the requirements, I kind of fit content types into some different categories. So I'm going to walk through those categories now and the kinds of structures that I would use for the different types. So first type is my favorite, traditional well-defined content types. So content types, the old-fashioned way with like you going, you create your fields, it's really clear. And you use a node. So why would you use this? When is having well-defined content useful? This is useful for things like events, articles, job postings, courses, things where you have, you want to have a form that's well-defined where you're controlling the content really well. You just have a set of fields that people have to put in, they have to, the content gets stored a certain way, gets printed out a certain way, things are really predictable. And with clear well-defined content types, there's no ambiguity. You know, a content page is not, could not be five different things. It always has these kind of standard set of fields. And this is important if you want your content to be consistent. You want it to always look the same. You want it to be searchable by a standard set of filters. You want it to be predictable. You want to be able to migrate it in really well. You want to put it in a map or a calendar. It has to have a date or it has to have a location. Well-defined content might be easier to create because a user is just going to have a standard set of fields that they're fitting in. There's not like, oh, you can build a page with this, with an image, or you could put a button, or you could put a map, or you could just make up your own HTML or add a form. Like, you know, it's not like a page builder type. It's like, here are the requirements you have to put in content like this. So you're probably going to define some content types in your site that are going to look like this. So you can think of blog posts, you can think of events. Most sites have some content like that. Sometimes, well-defined content is more complicated than just a simple set of fields. So you can probably think of a use case, maybe on your site, maybe on a site that you're familiar with, where a standard set of fields that you want the user to fit in, it's not just like one field after the other. Some of the fields are, we can think of them as like compound fields. So I think of an example like an event that happens a whole bunch of times. Maybe the event happens five times during the year in five different locations, and so you want to have kind of a sub-content type within your event content type that's to store the date and location together. So here we're really thinking of like, it's still really structured content. You're still creating events. They all have to have a standard set of fields. But some of the fields are compound and then can be duplicated like this. So for this, I would use paragraphs. So paragraphs, like I said before, you haven't used it. It's kind of like a tool for building a sub-content type. So in this case, a sub-content type could be something like an event instance. And within each sub-content type, you can have fields. So that would be a good solution if you need it. And I would still consider this a really well-defined content type because it's still predictable. You could still say, oh yeah, the first, like get me the field, the date field from the first sub-content type, the first event instance, and you would still get a predictable result. So it's still predictable. You could still make it searchable and you'd still kind of have a standard template to use for it. Another type of content that we might have is content that has a lot of relationships. So content where you have references all over the place between content. Now every piece of content in Drupal has relationships. You always have content related to other content, whether you want to or not. So remember, I mentioned that content entities have base fields. So some of those base fields set up relationships without you even knowing about it. So one example is a node. You create a node and every node has a reference to a user, the author of the node. So whether you want to or not, your node is related to a user. And you also have relationships between nodes and revisions. If you have revisions enabled for your content, every time you create a revision, you're actually creating another thing in Drupal and then you have this relationship between nodes and revisions. So these are implicit relationships. And you can use those when you're building your site, displaying your content. That's just something you're going to get out of the box. You can also, of course, set up explicit relationships. So sometimes in your content you're going to have references from one piece of content to the other that an author is going to explicitly set up. So maybe you have a node reference. Like maybe you have the example I always use is courses and programs on a school website or a university website. So maybe you have a whole set of programs that you're creating and each program has references to a bunch of courses. Or maybe you have a bunch of courses on your site and each course references an instructor. So those would be node references that you set up from one node to another. And then you can also use term references. So a term reference is going to be useful if you don't want to have that relationship be direct. So sometimes you want to have specifically one node that references another. But sometimes you just want to have these relationships between nodes that are based on the taxonomy terms that are assigned to each node. So sometimes you just want to say, oh, well, these two things are related because they have the same taxonomy term. Or these two things should show up in the search results together because the person filtered by a taxonomy term. So a taxonomy term is a way of setting up related content that's a little bit indirect because you have this categorization that's being applied. So that's another really common way of setting up your content. And of course you can add relationships to well-structured content. Another huge category of content in Drupal when you're thinking about what content types you need are going to be these multi-purpose kind of pieces of content. So this is what we're talking about when we're talking about landing pages or talking about like the home page of the site. And no one really knows what the home page of the site should look like in six months. Maybe we have a design for it now, but we know for sure that things are going to change. So multi-purpose content is like content where you have some ideas like, okay, these pages should have these kinds of things. It should have images. They should look like this. There should be buttons. They should look like that. But you don't know what content you're going to need in the future. You don't know what order things should go in. You don't necessarily know if you're going to need five images or two. And you want to make it really flexible. So if the goal is like a really flexible kind of page builder solution, then the way that this is being done now in Drupal is with paragraphs. So paragraphs, this is the strength. It's this flexibility. And the really nice thing about paragraphs, if you haven't used them before, is you can set up a paragraph. You can set up many paragraph types. And then you can have a field that references multiple types. So you can allow the content editor who's creating the content to pick what type they want to use and to combine them together. So they could put a web form, an image, a call to action, and then maybe move them around later on. So the idea is to build types. So we still have well-defined paragraph types. So call to action, image, view, web form. These can all have fields on them. They can all be well-defined, how they're going to be displayed can be defined, how they're going to be input. They can have required fields on them. So you still have a nice content structure. You're not just giving somebody a blank slate, like put whatever HTML you want. But you are allowing them to mix and match the different component types. So it's a very nice predictable, somewhat predictable approach, but while still giving a nice set of control to the editors and marketing people working on these landing pages. So the multi-purpose content is great. But one thing that it's missing is that you might be building these bits of content, like these paragraphs, and building them up to create these pages. But you'll find that maybe you want to reuse some of your content from page to page around your site. So if you're building the site and you have some kind of promotional content that you're creating, then you have to add that to 10 different landing pages. You're going to think, oh, maybe I'm not doing this right. Maybe I'm missing something here. So one approach that you can, another approach that you can take is to use blocks to manage all those components, all those page components that you're using to build up your flexible landing pages. So paragraphs is one option. Blocks, with blocks you can do pretty much the same thing. You can create block types, like you can create paragraph types. And you can reference those blocks from a node. So you can set up a field, your blocks field, that references all these different types of blocks, and then allow users to combine them the way that they want. The thing that you're going to find that's missing is that with paragraphs out of the box, you can just have all your paragraph types that you edit using one form. With the blocks situation, you have to add an extra module, the inline entity form module. Then you're able to add the blocks also through the form. So this is another approach. The drawback here is you're going to end up with maybe a lot of blocks on your site. So if you have 20 landing pages and each landing page has five blocks, and you're not reusing the blocks that much, you're just reusing them now and then, you know, you'll end up with like a hundred blocks on your site, just for these bits of content. So that's one reason that people are hesitant to do this. Your blocks page is going to get really, you know, you go click place block and you see a hundred options. Maybe that's not ideal. I know that this is a problem that's being worked on to create some kinds of blocks that aren't meant to show up on that blocks page. The thing that I like about this approach and also applies to the paragraphs approach is that if you reference your blocks from a node, then all of this becomes content. So normally, you know, when you go to the blocks page and you click place block and you stick a block somewhere, that goes into configuration. And configuration is something in Drupal 8 that you usually manage with a configuration management workflow, so you have to actually make that change, do an export, add it to your version control, push it to the live site, like there's this whole process for changing configuration, whereas if you're just going into a node and editing a blocks field, then that is part of the content. So having this kind of setup with a reference field to reference blocks, you're just making content changes when you're moving blocks around on the home page and you avoid all kinds of extra steps to deploy your changes to the site. So you can just do this on the live site. Now some of you are going to say, well, if I wanted to have reusable content, why wouldn't I just use nodes for all these things? So this is a way that you would have probably done this if you were to do it in Drupal 6 and maybe even Drupal 7. I've seen lots of Drupal 7 sites where this approach was taken. So maybe you have a home, a landing page node, and then you have a field that references a bunch of nodes, and each node is like a piece of the home page. You can have a node for a banner. Well, that's not really what nodes are meant to be. Nodes are not meant to be chunks of content on a page because each node has its own URL. So if you think back to the original purpose of nodes and blocks and terms, this picture probably looks wrong to you. But there is a use case where I think this makes sense. You might have some content on your site. You might have, for example, a website for a bunch of school districts, and each school district references schools. And maybe right now each school is just a chunk of content on your school district page. But in the future, you're planning to build out schools as their own distinct pages. So maybe thinking forward to the future, you realize that the content that you're placing on a page is actually meant to live on its own at some point. You're going to develop that further. So you might decide to take this node's approach if you have that kind of requirement. Okay, so these are all approaches that you can take where you're just using configuration out of the box with Fruple, or using paragraphs. I haven't introduced anything else that requires custom coding just your theme handling how the content is going to look. But you might have some use cases where you decide to build custom fields and custom content entity types. And the question is, why would you ever want to do that? When you're planning out your content types, here are the things to look for. So custom content entity types are useful when you want to pre-define a chunk of content and you want to have special rules about how it's used, whether there's a URL for each entity, what the base fields are, the whole workflow for maybe approving it or assigning it to people. And if you have a lot of this kind of content and you want to make sure that the performance of your site works really well. So one example might be you have some content on your site and you want to have some tasks associated with the content. So maybe you have some kind of an intranet that you're running and there's a bunch of tasks associated with the content. And each task has a user reference and a description of the task, maybe a timestamp, something like this. And you think, okay, I guess I could use paragraphs. So this is what starts to happen when you use paragraphs. This has happened on our team. We're like, oh yeah, we can use paragraphs for everything. And paragraphs is a great module, but if you start to use it for everything, you will reach the limitations. So the limitations of paragraphs are, you know, the content that you create with paragraphs, the paragraphs themselves, they're really meant to live within the content that it's created within. So if you have this kind of whatever kind of content this is, like a project content type, let's say, then are the tasks just meant to live within that or do they have a life of their own? And should they really be like full-fledged nodes? Maybe not. But maybe they need to have kind of their own workflow. Maybe they need to have somewhere else that they live in the database so that we can use them a bit more flexibly. So if you're thinking of creating a lot of one kind of content and it doesn't really require a node, but it needs to have a life of its own, then maybe a node is not right, maybe a paragraph is not right. Maybe this is the time to create a custom entity, a custom content entity type. So this is sort of where you have to plan ahead and you have to do some prototyping. So before you go to all the trouble of making a custom content entity type, go and think through your use cases. How are you going to use this content? What views does it need to be displayed in? What's the workflow going to be? And if you reach the limitations of what Drupal can do, then you can consider starting to write a custom code for this. Another limitation you might reach is with a set of fields that you can use with Drupal. So far, I talked about having these different kinds of content entities and each one, of course, is fieldable. So you define, okay, I have these fields for this one, these fields for that one. And in Drupal Core, for Drupal 8, you have lots of field types. You have more field types than in Drupal 7. You have field types for link, date, email, like works really well, seems to work pretty well, like all these different field types. Then you have extra contributed modules if you run out. So maybe you need to have a location. So there's different contrib modules you can use for setting up locations or addresses. So you can start to work with these contributed modules. But you might reach the limitations of those as well and realize, actually, this kind of field, it has to be validated in this specific way. Or this kind of field, like it really needs to be stored in the database like this. And in those cases, or maybe you have a compound field that's not just one thing, like maybe it's a text field, but it's not just one text box. There's two parts of it. But you want to keep this as one field. And you want to reuse it maybe for some different content types. So that's when a custom field might come in handy. So it allows for custom validation. You can create custom ways to add it and display custom fields, which is nice. And then for compound fields, you're going to avoid, again, creating a whole paragraph type for this little field that you want to use all over the place. Maybe you're going to have a multi-value field. So there'll be like 50 of them on a content type. And using paragraphs for that, you might, again, reach the limitations of paragraphs. So creating a custom field is not a hard programming thing. If you're learning Drupal module development, it could be like one of the first things you learn how to do. So if you're planning on building a site with a lot of content, rather than going out and creating like a thousand paragraphs for this one little field, maybe consider using a custom field instead. Or rather than having some kind of field where you really want to make the field content consistent, like it's some kind of a code that has to be a certain, formatted a certain way to integrate with other things, rather than trying to have a help text that says please format your field like this. Having a custom field just allows you to do the validation, allows you to store the data that way that you want. So it creates much more flexibility. Again, you should prototype it before you make a decision. Okay, so we have all these different options for how we're setting up our content. And in the real world, you might not have content that just falls nicely into these different categories. So you might not be able to say, oh, here's my well-defined content. Here's my very flexible landing page content. Here's the content that's going to be reusable. No, like in the real world, you start working on a project and you end up with some content types where all of the above seem to apply. Like you have content that is both supposed to have these flexible landing page parts, but also have some defined fields. So you might end up with quite complex content because of this. You have different ways of editing the same content that's part of the same node. So you might have, like for example, I worked on a learning management system recently. So there's content as part of each course that you take that's structured with paragraphs that have subcontent types for setting up the different learning modules. But then there's also individual fields and then there also might be some paragraphs that are more for displaying nice visual components. And that might all be part of the same content type. So if that's true, if you have these really big content types that have a lot of these different kinds of fields on them, then you would just want to make sure that you take care to look at the user experience for your content editors and make sure that the fields are well explained and well organized on the Node edit page. Okay, so I explained a bunch of options. Like you could do this, you could do that. And people sometimes complain about my presentations because I don't tell them what to do. I just say, here's what you could do. Look at all these options. So I'm trying to improve. So this is the slide where I'm trying to tell you what not to do. This is what you shouldn't do. So what not to do? Don't create too much rigidity in your content. If you create content types that are really well defined because like me, you like to have control over how everything's displayed and how everything's input. You have a lot of control, like everything's required fields, everything's like only this many characters for your text fields. Your content editors might just not use your content types and might just say, actually we just want to use basic pages for everything and have HTML and they might just go and do that. So if you put too much rigidity in place and it doesn't actually match the content that people need to publish on your site, then that's not good. Like rigidity seems good because you're defining things, you're having control, consistency. These all seem like good things. But too much rigidity is going to really annoy content editors, marketing folks, and it's not going to respond to their needs. On the other hand, too much flexibility. If you just say, oh, every page, and I know Chris said he did this for his site earlier, so I don't want to say this is always a bad thing, but too much flexibility like, oh, you can just put anything on the page. You can have a color selector, so you can select in each paragraph the color of the text and the color of the background and you can have any image you want and it will be displayed and then you can mix and match all these different paragraph types. Like sometimes too much flexibility leads to a lot of inconsistency and then that's not going to be good for the end users who are actually consuming the content. So you want enough structure that content can be discovered if it needs to be. So if you want to think about how is the content that's being created on the site going to be discovered by users? How is it going to be interpreted by users? Are they going to be able to recognize the branding of the site in the content that's produced in the different components? So you want to make sure that it's not so flexible that it's just like, you know, Photoshop for your content editors. So somewhere in between lies the right level of flexibility the right balance and it's going to be different for each content type. So you want to always be asking when you're creating your content types what is the purpose of this content type? What need does it respond to on the site? Is this something that is going to be a marketing tool? Is this something that's going to be used to respond to certain questions that the user has? Is this a reference? Are people going to be comparing things? You want to be thinking about the purpose of the content as you're designing the content architecture. And maybe that's not your job. A lot of times it's us site builders or developers and maybe we think our role is not user experience so that's somebody else's job. But on a lot of projects there is nobody taking care of the user experience. You are creating a user experience when you're building the site so you are actually the only one to think about this question of should it be flexible? Should it be well-defined? What's the answer for each type of content? So when you look at this question when you're looking at how to take your content and map it into Drupal you're taking on this responsibility of figuring out how well-defined the content needs to be and so that's what you should be thinking about when you're hovering over that structure tab and trying to define the structure of your site. So I hope this was helpful. I hope it gave you something to think about. I didn't give a lot of really specific examples but I hope you are able to think about this and apply it to the content that you're working on for your projects. Thank you. Anyone have questions? Yeah? Field collections? That's right. Is there a content type on its own? The whole page content type that brings on all those pieces? Yeah, so the question is about paragraphs and how it's used a bit more concretely. So some sites I've seen have a content type just for the home page. Paragraphs are added as a field to content types usually. So if you have a home page content type but you can pick so you could call it a landing page make it a little more general and have it apply to other pages on your site as well. And then often how it's used is there is one field which maybe has a name like content. Sometimes we use that really generic word because that field ends up referencing different paragraph types and those types could be, you define them. So here the word paragraphs, like that's a field, paragraphs is a field and then in the configuration of that field, it's like a node reference field if you're familiar with that and then it can reference different types. And the nice thing when you actually configure that field there's checkboxes for which types you want it to be able to reference. So you can pick multiple types and then it's up to the user to pick, oh I wanted to add first of all a call to action and then a web form. Yes, Jigar has a question at the back. Yeah, I don't have a question but I would just like to add a sentence to like when to choose custom entities over nodes. So like back in the days I was working on a project where I had to choose whether to use nodes or use a custom entity and I found that firstly, if we use nodes for everything then the nodes table gets really heavy so my SQL queries get like a secondly, like nodes are the generative like content entity that comes out with lots of approval so they have a lot of like events, like there's a node presale event and node create event and node post create event that we work on. So all those events tend to add the application so if you want something in the type which will be free from all that work Alright, thanks Jigar, you're great. So just to reiterate so the one other thing that I should have mentioned is for choosing custom content entity type versus node nodes have a lot of overhead and so often well usually a custom content entity type is going to be better for performance and like just the size of the nodes table is not going to be so huge. Andrew? I noticed you didn't talk very much about panels but I looked it all and there are some developments with the layout and layout builder I was wondering if you could mention a few Yeah, awesome, I think I had like a note in my slide and then somehow I deleted it so I was like I don't know if I should open that whole conversation but that's a really good point to bring up so one thing that I didn't talk about at all is when you're doing this like what I have in the slide up here when you're creating this kind of multi-purpose content page a lot of times for you know in the past people have used panels and even now people use panels to build pages like this right to build like panels is really like a page builder tool that allows you to combine different components on the page whether they're blocks or other bits of content and you're able to pick the layout as well as the content the thing that's missing here is that there's nothing here that's going to define the layout of these different paragraphs on the page or in this case the layout of these different blocks on the page so if you're just using blocks blocks reference field or you're using a paragraphs reference field and just putting that content in that's only defining the content and not what the content is going to really look like on the page so there is a panel's module for Drupal 8 you can use it to fill this need you can also start to experiment and I would say that the panel's module I found in the past the reason that I'm hesitant to use it is it provides too much flexibility a lot of the time and it's hard for content editors to use it even if you're using the in-place editor which is a better experience but it's still a lot of options a lot of flexibility and sometimes you end up with inconsistent pages that are built and it's sometimes hard to create enough control around the different options available the layout builder module is a new experimental module that you can start to try and what it does is for your content types you can well for content types and for individual nodes you can choose a layout and then you can choose how the content will fit into that layout so like panels it provides the ability to select a layout for content or for content type content within that so it's a really ambitious module and it's already something you can experiment with although you will probably find errors in things when you use it because it's still experimental and there's lots of work being done on it so I think this is the future is having the layout builder for defining more like what the page is going to appear like in the meantime because the layout builder is experimental people have had workarounds for this for example using paragraphs to define a layout and then having sub paragraphs to define the content within that layout which is sometimes like seems like a bit of overkill other things that you can do around just the visual look of your content for your block types if you're following this kind of structure paragraph types you can have fields that you define within the types within the paragraph types for example that define the styling of each component so you could have like a call to action field called color palette and one of the color palettes could be like black on white and another could be like red on yellow or something and you can have different styles for the different types so that's going to take care of some of the visual stuff you could also use that for things like alignment like I know we've done that for things like call to actions, maybe you want to have it the text on the left and an image on the right or maybe you want it flipped so you could have a field for that so this approach means that you have more control over how things look instead of it just being like up to the content editor to pick the layout and put everything in place but layout builder is something that's really exciting so even if it's still experimental you should go try it out and there's like lots of exciting work being done on integrating it with blocks so eventually you might not need paragraphs as much, this is the idea other questions, comments yes I was just wondering if you had the thing to say about using the paragraphs can you interpolate with multi-lingual sites? oh yeah I do, I was talking about it earlier so if you have a multi-lingual site and you're using paragraphs one thing to note is that it's a bit restrictive on the workflow of the translation so usually in Drupal if you have a multi-lingual site you can go and edit your content in any language and you can update let's say you have an English French site because I know most of us are working with here in Canada so you have your English content maybe you created it in English you translate it all into French then next week you decide to go and add some more to the French version and then someone comes back and edits the English version and they translate that new part so you can have a very flexible workflow for your translation and you create a bunch of paragraphs in let's say in English then you can then go translate the content into French then you can translate all those paragraphs but you couldn't go and create another paragraph you have to go back to the original and create it in English first so it's kind of restricting how you do the translation it's not just flexible you can't just have like oh this paragraph type added in English another one in French so if you have really symmetric content like if you're a government and everything has to be translated and it's translated in a certain way it works really well for that but if you want something more flexible then it's going to be limiting you're going to run into some at least annoyances anything else? I've got probably a new question but right at the start you had the cheat sheet oh yeah and I was just having some trouble in my own head mapping that to the how do I structure things like that I had a note to create like a table where I compared everything so nodes are for example nodes are fieldable nodes have bundles terms are fieldable, terms have bundles custom blocks are fieldable and have bundles so paragraphs are fieldable and have bundles all these things are fieldable and have bundles and they're all content entities so I went through and picked out the ones that are like really similar there's some other content entities that I didn't talk about users oh I'm running out of time like users and for example users are fieldable but they don't have bundles so you just end up sometimes with limitations oh and menu items aren't fieldable and don't have bundles I believe thanks thanks everyone and stick around for the next talk just starting right now